LinkMeter v9 Release


 
Bryan, I'm on an older non-sysupgrade compatible image, do you happen to know if there's an easy way to use dd to upgrade my flash image that will keep my backup partition? My windows PC died, and trying to use win32diskimager virtualized is proving to be a pain (it'll read fine but it doesn't like direct hw access writing).

Edit: Might have gotten it, running as administrator and closing all Windows Explorer windows seem to have it doing.. something.

Edit part deux: Worked! Thanks for the hard work!
 
Last edited:
I got the AVR firmware update installed today and the servo is working perfect again now....
Last night I had tried to use the Online Repository and got the same error that is being reported here, today when I tried the Online Repository is working and showing a bunch of firmware there. I wasn't exactly sure which one to choose (there were 4 dated Aug 1st), so I picked the one from the top of the list and it seems to be working....
 
Bryan Mayland said:
Well now that just doesn't make sense at all. Can you check your config for me..... ohhh crap I think I know why this is happening. The install sets the default for the autobackup intervals then the configuration restore wipes it out.

That's a serious conundrum, I don't have a solution for that. You can work around for now by:
Code: 
uci set lucid.linkmeter.autoback_active=5
uci commit lucid
/etc/init.d/lucid restart
Click to expand...

Doesn't look like that fixed it.

Code: 
root@shmickHM1:~# uci set lucid.linkmeter.autoback_active=5
root@shmickHM1:~# uci commit lucid
root@shmickHM1:~# /etc/init.d/lucid restart
Stopping LuCId superserver: lucid.
Starting LuCId superserver: lucid.
root@shmickHM1:~# ls -al /root
drwxr-xr-x    2 root     root          1024 Aug  1 09:42 .
drwxr-xr-x   18 root     root          1024 Sep  8  2011 ..
 
Steve_M said:
Of course I didn't wait 5 minutes!
Sure enough, it's there now!
Thanks again.
Click to expand...
Thanks for noticing this so early after release. I'm not sure how I'm going to get around this, mostly because every time a setting is added the default will be blown away when the configuration is restored.
 
There's no way to have the upgrade invoke a utility that will diff the current config and update it with new settings at their default values prior to restoring it?
 
Nah their configuration backup / restore just replaces the files which makes sense because if you did something like delete a network adapter you don't want it coming back when you restore. It doesn't have any notion of what's a default setting after the first boot when the default-installing script runs. Looks like you can't insert hooks into that either.

The only thing I can think of is splitting the install script into two parts and having the one that sets defaults run on every boot before the services start. That seems really messy, so I'm going to try and think of a cleaner way.
 
I hope this is not ridiculously stupid. I don't even have my heatermeter running yet. So, my understanding of the problem might be way off. Now that I have fully disclosed my ignorance, here's my thoughts. Is there anyway to keep the config on a separate partition? Then, when upgrading, only overwrite the first partition.

Bryan Mayland said:
Nah their configuration backup / restore just replaces the files which makes sense because if you did something like delete a network adapter you don't want it coming back when you restore. It doesn't have any notion of what's a default setting after the first boot when the default-installing script runs. Looks like you can't insert hooks into that either.

The only thing I can think of is splitting the install script into two parts and having the one that sets defaults run on every boot before the services start. That seems really messy, so I'm going to try and think of a cleaner way.
Click to expand...
 
No man, all ideas welcome. That's actually what the code currently does, the issue is that as new settings are added they don't get the new defaults. The defaults go into place but then the configuration restore wipes them out because there's no way to tell what's default and what's just been modified or removed. The best plan I have so far is to store the defaults in one place and the rest of the "setup" in another place then try to overlay the defaults on top of the restore after the restore completes. It isn't as clean and lovely as the current system is though, so I'm holding off on implementing that hoping that I come up with something better before I go for it over the weekend.
 
Bryan, I just wanted to thank you for making the change allow both the servo and fan to work at the same time. I used it tonight for the first time and this setup is outstanding! The best of both worlds, the fan stokes up your fire for you, once the pit starts approaching the target temp the fan turns off and the servo takes over using the natural convection of the fire to gracefully land on the target temp. The ping pong valve works nice, but the servo damper is a much simpler and more natural way to manage a pit that is sealed up tight and insulated. I think the eagle landed on this one, I am extremely happy with how this system works!

I also like that you allow the opposite configuration as welll, use the fan to control the fire and the damper basically as a choke valve (smart ping pong ball! LOL) This mode should come in handy for high heat pizza cooks to keep runaway temps in check.

This setup seems to have all my requirements covered and I think the fan/servo combo makes it the most unique and versatile controller available... Is there any other controller out currently that has this? If not I would bet one will crop up sooner than later...

Here is a pic of my servo valve with the fan installed on my FauxMado grill...
ServoFan.jpg


I know I have asked before about the possibility of changing the rca header for the fan to something that could possibly work for the servo or the fan, now we have both and the wiring is getting a little more out of hand. As far as I can count we need 4 wires for this system, +5V, GND, Servo Control, Fan Control. (servo and fan sharing the same ground) I know you were looking for commonly available wiring when you choose the RCA cable, while using this setup for the first time tonight I thought perhaps a telephone jack would work well for the fan and servo connection? It's small, commonly available, has 4 wires.... My initial thought was Cat5 but 8 wires is overkill and makes the plug too bulky. But a phone jack is nice and small. I know you were thinking of moving to some sort of industry standard plug, but I kinda like the idea of all the wires for my servo and fan coming down one small phone cable...
 
Lookin good, Ralph!

I kinda wanted to switch to the barrel jack for the blower connection because that's what comes on the auber blowers, and use a standard 3-pin servo connector (JST?) for the servo. That way all off-the-shelf cabling could be used. I can also appreciate what you're saying about having one cable for everything though. We actually need 5 pins (the ground can not be shared as the fan's ground isn't always grounded) but that would still fit inside the same footprint as the RJ-14 4 conductor plug (RJ25 6P6C).

That said, I still like having the off-the-shelf connectors and will almost definitely be using them. If I can fit in a phone jack header to make it an either/or though, I think that would be great.
 
Haha well if it makes you feel any better, I'm not doing it now, it's just on the list for the next board design. May not even be this year (but it probably will be)!
 
If I recall the schematic correctly...
I think it's a combo of 3 wires?
Maybe a 3 contact connector, like a stereo connector soldered on as a pigtail?
 
That is what I'm looking to add to mine. a connector just like the probes.

The tip would be the signals, the inner ring power, the outer ring ground. That way you don't mess anything up as you insert it into the socket.

dave

John Case said:
If I recall the schematic correctly...
I think it's a combo of 3 wires?
Maybe a 3 contact connector, like a stereo connector soldered on as a pigtail?
Click to expand...
 
Still on v8 I believe but would like to ask a question before I upgrade ;-). I tried to install some packages via the openwrt interface to setup a Webcam to monitor my BBQ's smoking status while I'm at work (a mile from home). And here's the error that I get for the first required package, kmod-i2c-core (same as for the other 2 needed packages):

[Seems to be my current kernel]
Package kernel (3.3.8-1-20163e2963e49a0b3a20f1544f08b463) installed in root is up to date.

[Error during installing, seems it needs a different kernel, this is the package available in the OpenWRT default web interface]
Installing kmod-i2c-core (3.3.8-1) to root...
Downloading http://downloads.openwrt.org/attitu...c/packages/kmod-i2c-core_3.3.8-1_brcm2708.ipk.

Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-i2c-core:
* kernel (= 3.3.8-1-eec613807fe13b8b6e091b5fe004126b) *
* opkg_install_cmd: Cannot install package kmod-i2c-core.
​

Does v9 have a kernel upgrade that fixes this? If not, any clue how I'd solve this issue? I'm not really so into the nitty-gritty of Linux & code that I can easily crunch through it and solve myself ;-).

By the way I am totally impressed by how configurable and powerful the HeaterMeter 4.0 is. With a 3D printed case, SSR, and 2kw hotplate I have a pretty amazing electric smoker! :)

cheers,
dave
 
John and Dave, I don't think 3 wires is going to do it for connecting both the servo and the fan, the servo itself needs gnd, +5 and a signal lead, then you still have to accommodate the fan. I thought we needed 4 until Bryan pointed out that the gnd on the fan isn't actually gnd, so that makes 5 wires required. Remember that the servo and the fan are not controlled by the same signal...

Bryan, I don't see the attraction to using the stock servo wiring, the servo's come with a wire way to short to connect to the HM, not sure if they sell servo extension cables, but even if they do, how long? And why? If you use a standard servo cable that means you have to have male pins coming out of the HM that have voltage on them, which is not the best idea IMHO, cause they could short out pretty easily. Also, if you've already built the HM you are no stranger to solder, so it shouldn't be a big deal to either wire a telephone header up to your fan and/or servo and then you can just use a standard phone wire plugged in between them, or you could cut the phone jack off one end and solder the wires to the servo and/or fan. I kinda like the idea of putting a phone jack on the servo/fan end and being able to disconnect it from both the HM end and the grill end, that would make dealing with the wiring very clean and simple...
 
Dave D said:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-i2c-core:
* kernel (= 3.3.8-1-eec613807fe13b8b6e091b5fe004126b) *
* opkg_install_cmd: Cannot install package kmod-i2c-core.
Click to expand...
Kernel modules are tied the md5sum hash of the source or something, so any time you modify the kernel you get a different package name. Because the kernel we build is a lot more up to date, the md5sum will never match. You can try to install with --force-depends and see if it works. The base config of our kernel is the same as the stock OpenWrt so we should have the same featureset, which would be all that is required.
 
Bryan Mayland said:
Because the kernel we build is a lot more up to date, the md5sum will never match. You can try to install with --force-depends and see if it works.
Click to expand...

Aha - thanks Bryan!! Yep I bet that's it... just right now for some reason I can't connect to openwrt.org to get the packages. Will try it again later.

cheers,
dave
 
You must log in or register to reply here.

 

Back
Top