Heatermeter 4.x (v13) on Raspberry Pi 2


 
C

Carlos_Primo

New member
Hi there,

New to the forum. I had a working heater meter on a PI model A but the PI died. I bought a PI 2 model B, downloaded the heatermeter software from http://heatermeter.com/devel/release/bcm2708/13/

BUT the heatermeter openwrt distribution, with the bcm2708 target, doesn't seem to work with the PI 2 according to the openwrt forum:
https://wiki.openwrt.org/toh/raspberry_pi_foundation/raspberry_pi

I checked this and indeed the bcm2708/13/ heatermeter distro doesn't work with the PI 2. However, if I download the openwrt distro for bcm2709 target, everything works fine.

I'm at a lost since the heatermeter site claims that https://github.com/CapnBry/HeaterMeter/wiki/HeaterMeter-4.x-Software is for 4.x including 4.3 which should work with the Pi 2.

Anyone got heatermeter to work with the Pi 2 model B? Do I have to use my own openwrt distro and install the heatermeter daemon?

THANKS!
 
Hi Carlos,

Are you able to attach the Pi 2 to a TV or monitor to see where it stalls on bootup? While there should be no major technical obstacle to getting the Pi 2 to boot, I'm don't recall anyone actually trying to use one with a heatermeter until now, mostly because they're way overpowered for what the heatermeter needs!

Update: It looks like the Pi 2 requires the kernel7.img file to boot, not kernel.img

Give this a try. Download this zip file, which contains the kernel version used in the v13 release of linkmeter.

Inside the zip file you'll see a kernel7.img file.

You'll need to put this kernel7.img file into the root folder of the SD card, but there's not enough room on the card to do so. You'll have to delete the kernel.img from the card first, then copy the kernel7.img to the card.

Also, this might not work too well, as it's a generic kernel, not the kernel built for Openwrt. If it boots further than it did without kernel7.img, we're on the right track.
 
Last edited:
After looking into this some more, I don't think that it's going to be possible to support the Pi 2 and Pi 3 on this version of LinkMeter, based on Openwrt 12.09, using kernel 3.3.8

The support for the newer processors requires a newer kernel, which means using a newer version of Openwrt.
 
Steve_M said:
After looking into this some more, I don't think that it's going to be possible to support the Pi 2 and Pi 3 on this version of LinkMeter, based on Openwrt 12.09, using kernel 3.3.8

The support for the newer processors requires a newer kernel, which means using a newer version of Openwrt.
Click to expand...

Thanks Steve_M!

So Openwrt Chaos Calmer completely runs compiled for target 2709
https://downloads.openwrt.org/chaos_calmer/15.05.1/brcm2708/bcm2709/

Is there a way to add the linkmeter software to this openwrt distro?

Thanks again
Carlos
 
It's a big undertaking, mostly due to the changes with the luci config interface. Your best bet is to use anything but a Pi 2 or Pi 3.
 
Steve_M said:
It's a big undertaking, mostly due to the changes with the luci config interface. Your best bet is to use anything but a Pi 2 or Pi 3.
Click to expand...

I see. Can the heater meter be compiled against the new LuCi? I can see that it has changed quite a bit from openwrt 12 to openwrt 15.

Cheers
 
With enough time and money, anything is possible :)

Bryan is currently working on a universal build of Openwrt to allow better device compatibility, but I wouldn't expect a beta until the end of 2016 at the earliest.
 
As Steve said, it is in the works (I'm actually replying while yet another build takes place). There are a bunch of problems going to from Attitude Adjustment to Chaos Calmer or Designated Driver (trunk). A lot of the internals have changed and there's some deprecated stuff that we rely on. That's the main reason you can't just install the linkmeter package from one distro to the other, there's no framework for it to run in. Some of the changes are more straightforward than others, however the different kernel requirement might rely on some hacks to get a unified build that works on all platforms. There's always the fallback to have two images which isn't terrible though.

My question would be: how do you plan on hooking the HeaterMeter to your new Pi? They don't fit together at all so you'll have to rely on running wires between them, and the cases don't fit either. It might be easier to find a original Pi B or A+ which do fit.
 
At the end of the day, is it really going to be a lot more work to fully decouple linkmeter from openwrt? Openwrt does keep the footprint small, but that's not really a big deal considering the price of an SD card, unless the plan is to replace the Pi with a cheaper all in one embedded system.
 
Steve_M said:
At the end of the day, is it really going to be a lot more work to fully decouple linkmeter from openwrt? Openwrt does keep the footprint small, but that's not really a big deal considering the price of an SD card, unless the plan is to replace the Pi with a cheaper all in one embedded system.
Click to expand...

I don't think the package size is as much of an issue as the ability to withstand a sudden unplug. Most linux distributions expect a clean shutdown and Openwrt is one that can easily handle being unplugged. It is certainly not acceptable to have to ask a user to 'shutdown' the linkmeter before unplugging. I don't know what Bryan is planning but perhaps running linux from a read only filesystem and then have the settings in another read only file system that gets remounted as RW when new options are set and then remounted back to read only.

Of course, this requires some significant work in getting things set up and ready to roll. Not to mention the parts of linkmeter that depend on Openwrt code to build and run...

--Ron
 
Openwrt doesn't provide any protection against FS corruption. It's still an ext3/4 filesystem on an SD card, which are flaky on the best of days! Since the Pi has no nvram, it's no less susceptible to corruption than anything else. This is why all the routers and other devices are able to handle power on/off events more gracefully.
 
You are right Steve, I had never logged into my router to really examine it much. Anyway, I would still be exceedingly concerned about fs corruption because, as you say, ext3/4 on an SD card is flaky. I have had nowhere near the time to think about this like Bryan and likely yourself but here is how I would go about it.

First, I would get linkmeter completely standalone to where it can run on any standard linux with Lua installed. I would have it 'installed' by untaring a linkmeter package into a directory and then simply running from that directory.

As far as execution goes, I would have $linkmeter/setupA/ and $linkmeter/setupB/ where $linkmeter is the installation directory. When loading the setup, it would look at config.txt and checksum in each of setupA and setupB. Whichever is the newest and passes checksum is the setup.txt I would use to configure things.

When saving, I would use the oldest of setupA and setupB for the oldest setup.txt or the one that does not pass checksum. I would then attempt to remount the FS containing that directory as rw, save the setup.txt and checksum and then remount back to ro.

This gives something that I think can be easily tested on new versions of linux easily as long as they have Lua, can recompile what little code needs to recompile, and support a consistent interface to the heatermeter. I am sure I am missing some (many) things here but that is the gross approach I would take to a universal version of linkmeter.

As part of the universal port Bryan has the additional responsibility of building screens for configuration and replicating all the features that DDwrt used to provide for free...

Now, one does not want the user to have to install linux and unzip the package so the public distribution would settle on a small distribution of linux and then strip it down further, getting rid of all the services one never wants. I know nothing about creating images for distribution but I would go about it by taking an SD card, creating three partitions, one for linux, and two tiny ones for setupA and setupB. I would have all three mounted readonly and create a ramdisk for /. Now, I think we are safe from FS corruption. At worst, one of setupA and setupB could get corrupted and there is no way to corrupt the FS for the linux distribution. This SD could then be turned into a img for distribution.

Anyway, I am really interested to see how Bryan cracks this nut in the end!
 
Well the beauty of it is I really don't think it is an issue. First, linkmeter runs its data off a ramdisk. This data is "backed up" to SD on a periodic basis (5 minutes?) using a sync file operation. If the power was pulled at this moment, possible corruption. You've got about 1ms every 5 minutes this can happen. Odds are very low. If this does happen, reimage the SD card with stock heatermeter and you're back up and running with the old config again.

Config backups are stored in an offline partition every bootup too so this can't be corrupted unless the user pulls the power at just the right instant on boot and this is only a one time operation per boot. Even in your chrooted A vs B setup there is always a chance of corruption when moving or backing from one to the other.

The real point is Is filesystem corruption a problem? to which I say no, so what's the point in trying engineer another system? All the heatermeter software is designed like the filesystem is not writable except in places where we're explicitly moving data between filesystems. It is not at all like a typical linux system with online filesystems that are constantly being written to by software designed to run on live filesystems. Even if you run on an overlay filesystem of some sort, there's always the chance of something going worong

There in short is no nut to crack! Unless you mean how to get up to the latest OpenWrt version, which isn't an unreasonably difficult task.
 
At the risk of dropping a rock in the pond and getting lots of "me to" sounding off, here is a neat platform I happen to have at home: http://vocore.io/

When I get everything else working and Bryan gets further along in the universal build process, then porting to other platforms starts to become interesting.
 
I have some VoCores as well, from their kickstarter. The platform is pretty good but the device itself is almost too small to be practical for amateur solderers to install onto a host board. With something like 30 pins twice as close together as all the other HeaterMeter connections, I could see getting some bridges that might destroy the VoCore module and then it would be really nasty to try and get out.
 
You must log in or register to reply here.

 

Back
Top