Linkmeter on an ADM5120.

[Brian Hilgert]

After getting fairly sick after a cold and rainy smoke, I decided I wanted a BBQ Pit controller, without the typical price tag. So a quick search brought me to the now surely famous Bob Hruska's Design.. Cool! Looks doable. Then I can't find a wishield :-( Endless searching found one place in the UK, but with shipping over the pond, it got to pricey.


So then while on Slashdot, I find a link to the Linkmeter Thread. Brilliant! Everthying I could want... on different hardware..ish. It was still Openwrt, and Bryan Mayland published the source on his GitHub Page. So after a few boneheaded typos, some very helpful advice from the active members on the Linkmeter thread, I was able to get it built and install on my little print server.

I would imagine this procedure could work for just about anything you can get Openwrt on, provided you either:

A Have enough flash space for the whole ball of wax on the flash.
B Run your off external storage. I went with usb, but I would think sd/mmc with jffs
would work just as well. Haven't tried it

Please keep in mind I'm no expert. Just wanted to share my roll your own 2MB Linkmeter from source.

This is basically a rework of USB-rootfs on boot on Edimax BR-6104KP (ADM5120) USB-rootfs on boot on Edimax BR-6104KP (ADM5120) [WORKS][/URL] on Openwrt forums. I documented the order in which I set linkmeter packages to make.

I'm going to assume you already have a suitable build environment such as on a real Linux box or a ]virtual. Open a terminal window and...

CODE:

cd ~
mkdir firmwarez
cd firmwarez
svn co svn://svn.openwrt.org/openwrt/trunk
git clone git://github.com/CapnBry/HeaterMeter.git
cd HeaterMeter/openwrt
./install.sh ~/firmwarez/trunk

cd ../../trunk
make menuconfig

Target System > Infineon/AdmTEK 5120 <<Make sure you pick your architecture
Target Profile > Edimax BR-6104KP << Make sure you pick your desired profile
Target Images > tar.gz (Install) <<For External USB Root for Micro Builds
Image Configuration >
>> DNS 8.8.8.8
>> Gateway
>> Lan IP
<<

If you have <= 4MB flash, you should be good there. Add extra packages if you must, but it's probably better to start simple, and add with opkg later. If however you have a 2meg flash like me, we have a little more work to do...


You need to change a few things from Install to Make, and I remove some all together. If I'm not mistaken, Bryan's linkmeter install takes care of removing all the firewall packages, so that saves a fair amount of effort. I removed wireless to start, figured I could add it later (I'm using homemade Power-over-Ethernet, so I don't need it out of the gate).

I tried to document the order in which to work through the dependancies. That's why I jump around in the menus.

Note: One of my USB packages is specific to ADM5120's (see below). Change for your architecture. These print servers do show up used on auction sites for ~$15us + shipping here and there. either the wifi ( HWPS12UG) or wired-only (HPS12U) work with the instructions below:

<pre class="ip-ubbcode-code-pre">
GETTING DOWN TO 2Mb


Base System > DNS MASQ (remove)
Network > Time Sync >Ntp Client (Make)
Network >
>> Hostapd-mini (remove)
>> WPA-supplicant (remove)
<<
Utilities
>> linkmeter (MAKE)
>> rrdtool (MAKE)
>> avrdude (MAKE)
<<
LuCi > Modules
>> luci-mod-admin-full... (MAKE)
>> luci-mod-admin-core (MAKE)
<
Luci > Themes
>> luci-theme-openwrt (MAKE)
>> luci-theme-base (MAKE)
<
Luci > Translations
>> luci-i18n-english (MAKE)
<
Luci > Libraries
>> libiwinfo (MAKE)
>> luci-lib-ipkg (MAKE)
>> luci-lib-web (MAKE)
>> luci-lib-sys (MAKE)
>> luci-lib-nixio (MAKE)
>> luci-lib-lmo (MAKE)
>> luci-lib-core (MAKE)
<
Luci > Server Interfaces
>> luci-sgi-cgi (MAKE)
<<
Libraries
> librrd (MAKE)
> libuci-lua (MAKE)
> librrd (MAKE)
<
Kernel Modules > Block Devices
>> kmod-broadcom-sdhc36 (remove) <<Unless you are using a broabcom...
<
> Filesystems
>> kmod-fs-ext4 (remove)
<
> Wireless Drivers
>> kmod-b43 (remove)
>> kmod-mac80211 (remove)
>> kmod-cfg80211 (remove)
<<
Base system
> wireless-tools (remove) <=Not a 100% that this has to be last, I just missed it and had to go back ;-)

Exit Saving Changes
</pre>

EDIT: Put the actual links in, sorry

 

[Brian Hilgert]

Most of the changes here are in order to boot from USB root

<pre class="ip-ubbcode-code-pre">
make kernel_menuconfig

Networking Support > Wireless (remove)
<
Device Drivers
> Misc Devices (remove)
> Scsi device support
>> Scsi device support (install)
>> legacy (remove)
>> Scsi Disk Support (install)
<
>Serial Ata support (remove)
>Network Device Support
>> Wireless Lan (remove)
<
> ISDN Support (remove)
> USB support
>> Support for Host side USB (install)
>> USB device filesystem (remove) << deprecated
>> ADM5120 HCD... (install) << specific to ADM5120's
>> EHCI Support (remove)
>> OHCI Support (install)
>> USB Mass Storage Support (install) ( remove all sub items that appear)
<<
File Systems
> EXT3 (install)
File Systems > Miscellaneous Filesystems
> Journaling Flash File System v2... (remove)
<<
Kernel Hacking
> Sample kernel code
console=ttys0,115200 mem=16M root=/dev/sda3 init=etc/preinit ro rootwait



Exit Saving Changes

make

ls -la ./bin/adm5120 =>look for openwrt-adm5120-router_le-br-6104kp-squashfs-xmodem.bin
</pre>

The kernel hack is only if you want root on USB. I made my root sda3
so I would have less to edit with uci to autmount my other partitions.

If over 2MB, probably got an extra package or two. Browse ~/firmwarez/trunk/bin/adm5120/packages/ for unwanted packages.

I sometimes find it helpful to look for the corresponding package in ~/firmwarez/trunk/packages or ~/firmwarez/trunk/feeds,
open the makfile in gedit, and check CATEGORY for hints where to find it in menuconfig.


As far as how to partition it, that's up to you. My thinking was 3 partitions; root, swap and data. I know that using swap can degrade performance, and could lead to excessive wear on a thumb drive, but...

<LI>I don't have to set it automount, so it's not always active.
<LI>I have run out of memory when fooling around. I can activate swap to avoid that.
<LI>I figure loosing less than half a gigabyte is cheap insurance for emergency swap.

If anyone wants my fdisk/mkfs commands, let me know.

extract ~/firmwarez/trunk /bin/openwrt-adm5120-rootfs.tgz to whichever drive you chose for root, then I copy all my ~/firmwarez/trunk /bin/packages to my data partition

I also like to copy my packages to my data partition.

Then follow Bryan's instructions for installing HeaterMeterinstalling on your arduino.

 

[Brian Hilgert]

So Once I've uploaded the firm ware, I'm able to login to linkmeter. It doesn't see my arduino, so I correct the port settings to /dev/ttyACM0, and nothing. I tried reading the various config pages and readme's, but didn't get very far. I connected the arduino back to my pc, and ran serial monitor and saw nothing.

I don't plan on an LCD, not as of yet. And I haven't added any buttons, but can if need be.


I did just read something about connecting pin 2, guess i'll read a little closer.

But before I saw that, I went back to my java program to verify i was able to monitor my for probes over serial on both the PC and linkmeter host.

Will HeaterMeter run on a Mega2560 out of the box? Should I see anything on serial monitor, or am I wasting my time there?

EDIT:

After going through the linkmeter post, I commented out HEATERMETER_RFM12 in hmcore.h, and
<pre class="ip-ubbcode-code-pre">
~line 207 in hmcore.app
if (oldProbeType == PROBETYPE_RF12)
storeRfMap(probeIndex, RFSOURCEID_NONE, 0); </pre>

With that commented out I do see data every two seconds on the serial monitor, and via cat /dev/ttyACM0

But I noticed I don't have /etc/init.d/linkmeterd I have etc/init.d/linkmeter

Did my breakdown of packages cause the dameon not to be installed correctly?

 

[Bryan Mayland]

If you don't have an RFM12 you need to comment out the
#define HEATERMETER_RFM12 RF12_915MHZ // enable RFM12B receiving (433MHZ|868MHZ|915MHZ)
at the top of hmcore.h. That can cause the whole thing to hang trying to talk to the device and if it isn't there the behavior is undefined.

The reason you don't have the linkmeter daemon on your system is because you removed the linkmeter daemon from your system. You need the linkmeter package and all its prerequisites. If you've got your root on USB you should be able to install them there just fine. Just build them as Modules in the make system.

After that you'll need to configure it in /etc/config/linkmeter to set the serial port. I think you'll also need to change it in /usr/bin/linkmeterd.lua because in trunk it is in both places. It is changed in my local repository but I haven't pushed that to github yet because there are some other issues I'm still working out.

 

[Brian Hilgert]

I commented out #define HEATERMETER_RFM12 RF12_915MHZ // enable RFM12B receiving (433MHZ|868MHZ|915MHZ) before compiling the code for the arduino, I also had to comment out a few lines in hmcore.app ( see previous post) in order to get it to compile.

I built linkmeter and all the dependencies, and installed them via opkg. I modified /etc/config/linkmeter, and /usr/sbin/linkmeter.lua to use /dev/ttyACM0, but the linkmeter daemon still stops after a few seconds, never creating any files in /tmp.

And I can recieve data via 'cat /dev/ttyACM0', as well as 'screen /dev/ttyACM0 115200'

I tried attaching my USB-TTL adapter (/dev/ttyUSB0), and connecting it to pins 0,1 to the same end. I was recieving data every 2 seconds with cat or screen. Tried configuring linkmeter to use /dev/ttyUSB0, and had the same results.

 

[Bryan Mayland]

Ah so it is probably getting an error. If the [soon to be old] daemon gets an error it will restart itself up to like 10 times in 30 seconds. To see the error you can probably use the `logread` command to see what error it is getting or just run `lua /usr/sbin/linkmeterd.lua` to run it without daemonizing and it should spit the error out to the console with a stack trace. It might just be a missing dependency I need to explicitly specify in the package.

 

[Brian Hilgert]

<pre class="ip-ubbcode-code-pre">
lua /usr/sbin/linkmeterd.lua
lua: /usr/sbin/linkmeterd.lua:5: module 'rrd' not found:
no field package.preload['rrd']
no file './rrd.lua'
no file '/usr/share/lua/rrd.lua'
no file '/usr/share/lua/rrd/init.lua'
no file '/usr/lib/lua/rrd.lua'
no file '/usr/lib/lua/rrd/init.lua'
no file './rrd.so'
no file '/usr/lib/lua/rrd.so'
no file '/usr/lib/lua/loadall.so'
stack traceback:
[C]: in function 'require'
/usr/sbin/linkmeterd.lua:5: in main chunk
[C]: ?
</pre>

Checked my RRD install and it's showing rrdtool-1.2.30-1, not the 1.4 that should be installed with linkmeter. I'll try to resolve that.

EDIT:After builing version 1.4.5 of librrb and rrdtool and upgradeing them, a quick reboot, and I now have probe data on the web!!!

Now I'm having trouble using the set commands. I keep trying to change the setpoint, but nothing happens.

I've tried justing adding set?sp=212 to the end of the url wehn logged in as root, as well as via the web config page.

 

[Bryan Mayland]

Woohoo, nicely done!

Originally posted by Brian Hilgert:
Now I'm having trouble using the set commands. I keep trying to change the setpoint, but nothing happens.

When you use the config page, do you get the success page that says like:
<pre class="ip-ubbcode-code-pre">
User root setting 1 values...
sp to 225
Done!
</pre>

If you do you could check that `uci get linkmeter.daemon.serial_device` has the right value.

 

[Brian Hilgert]

Originally posted by Bryan Mayland:
Woohoo, nicely done!

Thank you I'm very ecited to be up and running even if my dta is wrong... I''m making progress; with all your help

When you use the config page, do you get the success page that says like:
<pre class="ip-ubbcode-code-pre">
User root setting 1 values...
sp to 225
Done!
</pre>

If you do you could check that `uci get linkmeter.daemon.serial_device` has the right value.

Yup, I do get the confirmation page when setting via the web.

and linkmeter.daemon.serial_device=/dev/ttyACM0
is set.

Am i using the correct format? I just type sp=219 in the dialog box on the config page, then click set...

I tried typing /set?sp=219 in the dialog. I get the same success page, but nothing has changed.

 

[Bryan Mayland]

Yeah the first way is what I'd call the preferred method, just "sp=219", but the if you add the prefix "/set?" the handler just strips it off anyway.

Well it sounds like you're set up correctly. Try `echo -e \\n/set?sp=219 > /dev/ttyACM0`. If that doesn't work either, check the physical serial transmit line to make sure it is hooked to HeaterMeter properly.

If it *does* work, check the permissions on your serial device maybe? Or I wonder if something else is also writing to the serial device and getting the data mixed up? If it works from the command line, we'll take it from there.

 

[Brian Hilgert]

Strange...

So I tried echoing to the serial port, no change.

Stopped the daemon, ran lua /usr/sbin/linkmeter.lua, then tried echo to serial, again no change.

started the daemon via /etc/init.d/linkmeter start and was able to change vie echo on the command line repeatedly until i tried the web. restarted the daemon, and now I can set from either the web or command line.
as far as permissions on ttyACM0, they look ok. I did notice that /usr/sbin/linkmeterd is running as nobody? I assumed that was intentional for security purposes.

I'll try again after a 20min powerdown to see if it was a fluke or if I can reproduce the results...

On another note, once I realized I was able to set via serial, I sent the Steinhart coefficients and resistance for each of the probes. I'm using all the same probes (CDN- ) They are all sitting on my desk, yet pit reads ~75, while food1 and two are ~30.
...
CORRECTION: I remembered reading about offset in the HeaterMeter readme... I did echo -e \\n/set?po#=0 > /dev/ttyACM0 for each of the probes, and now they are within .2 degrees. Brilliant! Ok, now to powerdown to narrow down web set issues...


This is So Cool!!! It's like X-MAS in July! Thank You so very much Bryan!

 

[Brian Hilgert]

Ok... got some consistent, reproducible results (at least on my rig).

After a cold boot or a warm reboot, I'm unable to use the web to set any parameters, until I set ANY parameter from the command line... Once I set any thing from command line, the web gui set works fine...

 

[Bryan Mayland]

Ooh this is a tough one. Good debugging though! Yeah the idea was to run the linkmeterd as an unprivileged user for security but then I found that OpenWrt has messed up UIDs such that daemon and nobody have the same user ID. I tried to bring it up but haven't gotten a response yet. I'd like to have it fixed upstream rather than patch it.

Ok the one thing that `/etc/init.d/linkmeter start` does that just running the lua does is that it sets the baud rate before launching the daemon process. Maybe once you've booted and you can't set anything try `stty -F /dev/ttyACM0 115200` then try it from the web interface? That doesn't make much sense though, because the receives would be messed up too.

Or, maybe something else has the serial port open? Another command line!
find /proc -type l -exec ls -l {} \; 2>/dev/null | grep ttyACM0

Check the output and you should see something like this
lrwx------ 1 root root 64 Jul 25 20:43 /proc/320/fd/0 -> /dev/ttyS0
Do a `ps` and see what process has the same number as the part between /proc/ and /fd/... There should only be one process with it open, linkmeterd.

Next, maybe try adding an extra newline to clear any garbage in the buffer? Modify /usr/lib/lua/luci/controller/linkmeter/lm.lua and change a few lines from the end:
f:write("/set?%s=%s\n" % {k,v})
add an extra \n to the beginning so it should read
f:write("\n/set?%s=%s\n" % {k,v})

Errrr after that, I'm not sure.

 

[Brian Hilgert]

Running 'find /proc -type l -exec ls -l {} \; 2>/dev/null | grep ttyACM0' yielded

lrwx------ 1 root root 64 Jul 27 06:22 /proc/1793/task/1793/fd/4 -> /dev/ttyACM0
l-wx------ 1 root root 64 Jul 27 06:21 /proc/1793/fd/4 -> /dev/ttyACM0

'ps' showed only

1793 nobody 2052 S /usr/sbin/linkmeterd

The modification to /usr/lib/lua/luci/controller/linkmeter/lm.lua seemed to have no effect. I'm thinking maybe an issue from MY botched rrd install, or possible an issue with the ACM driver not loading in time? I added a printk.time=1 to my commandline hack to see if I can correlate the start of Linkmeter with logread and the ACM driver with dmesg... My wife need the computer so I didn't have a chance to rebuild openwrt with printk.

But I did run into a strange issue when adding the 4th probe (using probe3, analog pin2, 'ambient'). I hadn't yet wired it, so I disconnected everything, wired up the probe jack, reattached everything, and fired up the Linkmeter. Everything went haywire. First my setpoint started jumping around from default (225) to 65, to 450, and so on. Then I noticed all my probe readings were wrong. I disconnected the probe, no dice. I disconnected the vcc/resistor board from the arduino and the set point stabilized to 225, and all my probe settings were off; Steinhart's and offsets. I was able to reset them with little effort, and then left the unit running overnight. Perfect sine wave over 24 hours; bottomed out ~6am, peeked around 4pm. Three spikes that could be my cats crawling around where they don't belong ( 2-4 degrees for per data point). Oddly enough the 'ambient' reading, which had nothing attached to the arduino pin, followed a parallel sine wave

So I figure I've got a short, but for sanity I revert to my java/firmata code, and I get clear consistent temps from all four probes. Slap HeaterMeter back on, ( I found were to specify default Stienharts ;-)) and watched in serial monitor on windows. Sure enough everything is fine for 5 minutes, until I attach the analog pin2, and it goes crazy again. hmmm...

I'll try running just the analog probe tomorrow on the build unit, and the fresh install/print.k on the test unit.

 

[Bryan Mayland]

I hope you don't mind me being quiet. I'm not sure what else to tell you to try. You could try (right on bootup) ssh in and run `cat /dev/ttyACM0` with linkmeterd still running. You'd think this would fail because linkmeter has it open but it actually works and it is sort of a race to see which process can read from it first. You should get some valid data, although not at the usual frequency. Then open a second ssh session and restart linkmeterd and see if the data you're getting changes? I dunno, I'm really just grasping at straws here.

Also my HeaterMeter exhibits the same thing, where a probe that isn't pulled up or connected tracks another probe's value. They're all linked to the same "port" in the Arduino so I suppose they affect each other if one is left floating. Still kinda neat.

 

[Brian Hilgert]

Not at all, Bryan. You've been very generous with your support and patient with my ignorance. After some tweaking, and testing, I think the issue was related to my installation of librrd and rrdtools. I reloaded the firmware, made sure to install the correct rrd packages, and all the other packages for Linkmeter. At which point it has run without issue, at least on the first 3 probes. Successfully ran a boil test, and an ice water test with +- .2 degree variance at boiling. adjusting parameters via web console is working very nicely.

I'm still puzzled about why everything goes haywire when I attach the circuit for the ambient probe to analog pin 2. It appears ok when I revert to my Firmata code, but heater meter seams to have the issue even via serial monitor in windows. I was thinking I would just check voltages/resistance and compare each thermisistor circuit....

I started looking over the heater meter code, but it's not lite reading for me. I can follow loosely, but it takes some work ;-) As far as I can tell, I didn't see anything in the code that causes it to treat the Ambient probe any differently than the rest. So I should be able to use /set?pc3=A,B,C,Known R, Type and po3=0 just like the rest of the probes, correct? Or did I not read far enough into it?

 

[Bryan Mayland]

Originally posted by Brian Hilgert:
I started looking over the heater meter code, but it's not lite reading for me. I can follow loosely, but it takes some work ;-) As far as I can tell, I didn't see anything in the code that causes it to treat the Ambient probe any differently than the rest. So I should be able to use /set?pc3=A,B,C,Known R, Type and po3=0 just like the rest of the probes, correct? Or did I not read far enough into it?

Yeah exactly. The code doesn't treat the Ambient sensor differently than any other of the sensors. The only one that is special is the first one (index 0) in that its value controls the fan speed. The code does try to do some sanity checking to keep the values from doing divide by zero and the like, but I wonder if somehow that's happening? I'm at a loss because even looking through the code I can't think how things could go that haywire.

Maybe add some Serial.print()s to it and see if you can figure out where it goes bonkers. After every print() put a delay(100); to wait for the serial to be flushed.

 

[Brian Hilgert]

I think I found my issue. As I'm not currently using buttons, and the HeaterMeter uses analog0 for said buttons, I thought maybe I was getting drift/noise/spill on pin 0 when I had the lowest probe attached. Made sense as once I detached the ambient probe, I could simple rest the sp and probe offsets, and I was back in business.

So I commented out the call to Menus.doWork() at the end of hmcore.cpp; and she's been humming along for the past half hour without issue. I'll let it run until after work tomorrow to see how she does on the long haul ;-)

 

[Bryan Mayland]

Aha! I've heard of other people having problems with the buttons pin floating too. I'm not sure how it goes haywire because it should only allow one "button press" for every like 200ms (I forget the actual value). If you want the scrolling menus without the buttons you should be able to change readButton() in hmmenus.cpp. Just add a new first line: return BUTTON_NONE;

 

[Brian Hilgert]

Originally posted by Bryan Mayland:
Aha! I've heard of other people having problems with the buttons pin floating too. I'm not sure how it goes haywire because it should only allow one "button press" for every like 200ms (I forget the actual value)

After closer examination of the serial output, that would seam right. It would just cycle through various set points, probe offsets, etc. Then every once in a while it reset to defaults. Rinse and repeat . After commenting out menus.dowork, she ran perfectly with all 4 probes for the past 24+ hours