LinkMeter v2 Homebrew BBQ Controller - Part 1


 
Status
Not open for further replies.
Originally posted by Ed Pinnell:
EDIT: [snip] And yeah, this is the one with the 32MB chip, but again the router seems to be working great...
Click to expand...
Oh whew. Man I was really worried that I had an unchecked memory leak again. I've put a compiled version of what I think was the release 1 heatermeter code (git tree 7ab9e9de3a67a38f7154345fed0e485db6ef4e4b). It is hard to nail down exactly when R1 was so I'm not sure if this is the right git revision.
http://capnbry.net/linkmeter/r.../heatermeter.cpp.hex

Also you can get the CSV of the currently running RRD file by using the hist URL (put your own linkmeter hostname obviously):

Auto-scale
http://lm54/luci/lm/hist

60 minute scale
http://lm54/luci/lm/hist?nancnt=999
 
Oh yeah I forgot to answer your question about the fuses. Short answer: Keep them the default Arduino fuses.

Hey where did that post go? Anyway, the crystal requires the most startup time to stabilize so the default settings work for both a crystal and a resonator. The web flashing process only modifies the firmware and doesn't mess with with the fuses or bootloader section.

You're right about the version number in the firmware. It would be nice to have that done automatically but looks like git makes that somewhat complicated...
 
Originally posted by Ed Pinnell:
So if I'm using the latest version or Arduino code from Github...dated Aug. 21, 2011...commit f885a3dae...which I am...it shouldn't be working with the R1 build found here that I am also using? They seem to be compatible, but did I miss the memo prior to this that said not to mix and match?

Alternatively, would it bend the rules too much to add the appropriate pre-built image to the corresponding HeaterMeter package down the road so that some other lazy hapless idiot who doesn't want to compile his own firmware doesn't make the same mistake?
Click to expand...
It may or may not work of you mix the firmwares between revisions, I think the only difference in the serial protocol involved how the "RF last update time" was conveyed. So in this case it may look like it works perfectly because the R1 router image didn't tell you the last update time. I could be wrong about the difference though, I don't want to have to dig through git to figure out what's actually different. The point is though that the HM and LM revisions are meant to be the same.

Great idea about putting the HM firmware into the LM package so there's always a default version.
 
Originally posted by Ed Pinnell:
A question I have for you: the deg/hr notes that seem to come and go in the probe boxes...what triggers those? Why do they appear and disappear, seemingly at random? Is that caused by my mismatch?
Click to expand...
The degrees per hour is calculated in the web browser and requires the graph data to have at least 1 hour of data for that probe, and have increased at least 1 degree from the start of that hour. It isn't very smart though because it bases the dph on the first point an hour ago versus the current point. So regardless of what happened in between, if it is at least one degree hotter than it was an hour ago, it considers that positive.

Really it should be doing a linear regression analysis on all the points in between to get a least squares best fit line that passes through all the points over the past hour, however I can't do that because two points with the same value in a row are merged so they wouldn't get the proper weight. Also, this is getting pretty scientific for something that really doesn't end up meaning that much!
 
Was looking into smoking sausage that requires the temperature to change during the smoke. Does this handle a temperature profile idea, where you can say 1 hour at 140 degrees, followed by 2 hours at 160 degrees, then 180 degrees until the internal temperature is 152?

If not, it does sound like the router portion of the software should be able to be enhanced to support this type of thing. Is the code open-sourced where others can add features like this?

thanks
 
No it doesn't do things like that. You could theoretically set cron to automatically adjust the temperature at the specific intervals to do the steps, but none of it is automatic. I've also got the "when temperature hits X, lower setpoint" on my todo list as part of the alarm system but it hasn't been done yet.

Of course it is open source, https://github.com/capnbry/heatermeter
 
So after takeing some time to design and build a UDS, I'm back to playing with Linkmeter...

I grabed a copy from github, and am currently trying to build from source. When I try to make Openwrt, i get the follwing error (with V=99)

make[2]: Entering directory `/home/brian/firmwarez/redo2/feeds/luci/luci'
. /home/brian/firmwarez/redo2/include/shell.sh; . /home/brian/firmwarez/redo2/include/shell.sh; gzip -dc /home/brian/firmwarez/redo2/dl/luci-trunk+svn7488.tar.gz | /bin/tar -C /home/brian/firmwarez/redo2/build_dir/target-mipsel_uClibc-0.9.32/luci-trunk+svn7488/.. -xf -

Applying ./patches/200-lucid-tpid-leak.patch using plaintext:
patching file libs/lucid/luasrc/lucid.lua
Hunk #1 succeeded at 129 with fuzz 2 (offset -21 lines).

Applying ./patches/205-luci-dispatcher-nopath.patch using plaintext:
patching file libs/web/luasrc/dispatcher.lua
Hunk #1 FAILED at 612.
1 out of 1 hunk FAILED -- saving rejects to file libs/web/luasrc/dispatcher.lua.rej
Patch failed! Please fix ./patches/205-luci-dispatcher-nopath.patch!
make[2]: *** [/home/brian/firmwarez/redo2/build_dir/target-mipsel_uClibc-0.9.32/luci-trunk+svn7488/.prepared_9fbb97a352e525d8c348c0f73cb81318] Error 1
make[2]: Leaving directory `/home/brian/firmwarez/redo2/feeds/luci/luci'
make[1]: *** [package/feeds/luci/luci/compile] Error 2
make[1]: Leaving directory `/home/brian/firmwarez/redo2'
make: *** [package/compile] Error 2


I verified that the patches are in ~firmwarez/redo2/feeds/luci/luci/patches, but it hangs there every time.

I'm trying to build from the trunk... i can get the revision number if you need it.
 
Originally posted by Brian Hilgert:
I'm trying to build from the trunk... i can get the revision number if you need it.
Click to expand...
Yeah the LuCI maintainer screwed me by taking /most/ of my patches which means that some of the patches don't apply to trunk, the apply to the version they were made for. I'm actually checking this forum as I wait for my build of the latest trunk to compile so this will be fixed later today.

I just got lazy because I knew it was going to be a pain in the kiester to re-do the patches. However, Ed managed to find a pretty big bug in the linkmeterd process so I've now resolved that it is time to get back to development.
 
Originally posted by Bryan Mayland:
Yeah the LuCI maintainer screwed me by taking /most/ of my patches which means that some of the patches don't apply to trunk, the apply to the version they were made for. I'm actually checking this forum as I wait for my build of the latest trunk to compile so this will be fixed later today.
Click to expand...

4 Minutes? Wow. I have paid support contracts that take longer to respond.

So basically I should try and grab a fresh copy of Heatmeter from GitHub later today or tommorrow?
 
Originally posted by Brian Hilgert:
So basically I should try and grab a fresh copy of Heatmeter from GitHub later today or tommorrow?
Click to expand...
Yeah try pulling it now. Re-run the (heatermeter)/openwrt/install.sh (it should be able to run against a directory where it has already been run) to update the patches in the OpenWrt build directory. Ignore the last error about the patch not applying (for it has already been applied)

I haven't had a chance to test the firmware build that actually comes out yet, but it compiles fine. Gosh the base firmware grew by 200KB. What the heck, OpenWrt developers, stop making everything bigger!
 
Originally posted by John Bostwick:
So, we should upgrade then, what was the bug
Click to expand...
The web server and linkmeterd can crash if there's a problem that delays the writing of the rrd file for 1 second. The fix isn't in github yet though, waiting to test it first when I get home tonight.
 
Originally posted by Bryan Mayland:
The web server and linkmeterd can crash if there's a problem that delays the writing of the rrd file for 1 second. The fix isn't in github yet though, waiting to test it first when I get home tonight.
Click to expand...
Fix is now in github. Also it appears there's something going wrong with the default configuration. The changes aren't being properly merged into the lucid configuration in the base image. If you fire up your web browser and get a blank page, check your /etc/config/lucid and make sure it contains:
<pre class="ip-ubbcode-code-pre">
config 'linkmeterd' 'linkmeter'
option 'serial_device' '/dev/ttyS1'
option 'serial_baud' '115200'
option 'rrd_file' '/tmp/hm.rrd'
option 'stashpath' '/root'

config 'daemon' 'lmserver'
option 'enabled' '1'
option 'slave' 'linkmeter'
</pre>
 
Bryan,

I was talking to a buddy (software guy) about taking on the temperature profile feature I mentioned above and he is willing. He and I are both looking to make one.

Do you do your development work in a separate environment or do you do it all on your linkmeter itself?

He was thinking of creating a VM image and doing the work there. Maybe modeling the heatermeter and plugging that into the VM. Something like that. I'll have him get an account for more details because I'm already out of my comfort zone
icon_smile.gif


thanks,
dave
 
Woohoo! Successfully compiled and installed Linkmeter 2.0 for my ADM5120 board. It's up and running, and seams pretty stable on my test unit.... I'll probably slap it on the actual Linkmeter by this weekend (it's still running 1.5)

I do have a question regarding one strange issue. It's probably either do to the fact that I have to install nearly ALL the packages after installing firmware (gotta love 2MEG flash!), or just an UTS (User Too Stupid) error...

Lucid isn't running once the unit finishes it's initial boot. I can login via serial/ssh and start it with "/etc/init.d/lucid start", and she runs solid (has for the last 14 hours anyway). when I do start it I get an error:

"Starting LuCId superserver: lucidlucid[1787]: Failed to initialize daemon https: Encryption requested, but no TLS context given"

but it runs fine just the same. I'm not sure where the log files are to check if it's starting and stopping, or not starting at all.

Just though I'de ask if any one had any ideas before I go banging around on the Linkmeter.
 
Originally posted by D Peart:
Do you do your development work in a separate environment or do you do it all on your linkmeter itself?

He was thinking of creating a VM image and doing the work there. Maybe modeling the heatermeter and plugging that into the VM. Something like that. I'll have him get an account for more details because I'm already out of my comfort zone
icon_smile.gif
Click to expand...
I do a lot of the HeaterMeter stuff on breadboard version (using a Boardino), sort of "unit testing" things out then uploading it to my LinkMeter's HeaterMeter. I also have a standalone HeaterMeter with an XBee serial connection on it for backup.

Some of the LuCI programming I do using their x86 mock environment on my development PC (running Linux), which isn't very helpful because there's no HeaterMeter data coming in.

The majority of the LUA programming I do right on the device and then SSH back any files I've modified to my development PC.

I started by using VMWare, but found it to be of limited use because you can't VM a MIPS SoC. I had done some things with feeding back a raw log file into the server process, but I haven't done that in a while because it was a bit of a pain to pipe it as a file (not terribly complicated but still easier to just use live data). To do this I just made a FIFO on the filesystem and did a bash `while read X ; do echo $X ; sleep 2; done < mylogfile` sort of thing as the input.
 
Originally posted by Brian Hilgert:
Lucid isn't running once the unit finishes it's initial boot. I can login via serial/ssh and start it with "/etc/init.d/lucid start", and she runs solid (has for the last 14 hours anyway). when I do start it I get an error:

"Starting LuCId superserver: lucidlucid[1787]: Failed to initialize daemon https: Encryption requested, but no TLS context given"
Click to expand...
Yeah the error message is actually just a warning. There's no TLS provider installed in the standard system because of the size requirements so LuCId can't do HTTPs.

I don't know why it doesn't start on startup. Are you using the latest git from yesterday? It may be the "double update in one second" problem crashing it on startup? You can turn on debug logging at the top of the /etc/config/lucid file and reboot. Use `logread` once you're booted to see if has an error message. You can see if it is running with `ps` and look for the lua process.
 
Originally posted by Bryan Mayland:

I don't know why it doesn't start on startup. Are you using the latest git from yesterday? It may be the "double update in one second" problem crashing it on startup? You can turn on debug logging at the top of the /etc/config/lucid file and reboot. Use `logread` once you're booted to see if has an error message. You can see if it is running with `ps` and look for the lua process.
Click to expand...

or i could just enable Lucid on startup by typing /etc/init.d/lucid enable
icon_redface.gif


I knew i should have looked a little more
 
Status
Not open for further replies.

 

Back
Top