Using linux containers for linkmeter

This is meant to be a brainstorming post, so bear with me.

One of the biggest changes happening right now in the linux world is the adoption of containers, with Docker leading the charge. It occurred to me that there might be a benefit in containerizing the heatermeter OpenWrt install, which could allow for a more modular system.

By running a generic, docker-enabled version of linux, such as this or this on the Raspberry Pi, you get access to pretty much every USB wifi dongle, as the base linux OS is now taking care of bringing up the network stack, you no longer have to hack this into the OpenWRT install.

The LinkMeter OpenWRT docker container image would be started with access to the serial port and SPI bus, allowing for communication to/from the heatermeter board.

Next up, run a second container with something like nginx or apache, acting as a web proxy to the luci web server on the OpenWRT image. This would allow you more flexibility in terms of being able to install and manage SSL certs, or create a config where you can create more advanced authorization methods, such as not needing a username & password if you're at home, only if you're coming from a remote IP.

You could run another container running a database like mysql that is being used to store all of the historical cook data.

We're no longer limited by the constraints of what OpenWrt can do, we're limited by the available resources of the Raspberry Pi.

Here's a neat blog post showing 2500 containers running on a Raspberry Pi 2!

http://blog.loof.fr/2015/10/how-to-run-2500-webservers-on-raspberry.html

I'm not exactly sure what docker is or containerizing means, but this is something you could sort of always do with ser2net fronting the Network <-> UART conversion and then just run linkmeterd somewhere else. This is sort of how the second HeaterMeter worked, which actually used Zigbee modules to transfer the data to a server running the monitoring and control process. Now that wifi is cheaper now (see the stuff DavidNP did to add wifi for under $5. I'd say ditch the RPi completely and just use an ESP module and MQTT to publish the data to anything.

The problem I have with all these cool technical solutions is that it comes down to the fact that somewhere there has to be a service running. The reason it doesn't pipe the data anywhere currently is because most people don't want to set up their own IFTTT or run their own web server on another machine or build their own cloud infrastructure. You still need to configure the networking on the device which is the largest hurdle someone has to overcome.

I mean if this were a commercial product sure maybe there would be an iPhone and Android HeaterMeter app that uses some wifi trickery to configure it to be on your network, then people would expect the app to be the frontend they interact with and you've got to write and maintain apps. You'd also need a heatermeter.com that's taking everyone's data once per second in and creating user accounts for logging in and database storage... this server infrastructure costs money as opposed to putting the server completely in the device which is free for life.

I see some thing where technically you could do more if it were hosted somewhere, but I don't find the OpenWrt toolset to be what's restricting anything someone would want to do with their HeaterMeter. Requiring an always-on internet connection or you can't use your HeaterMeter seems like a major weak point.

If 'extending the capabilities' requires moving to debian from openWRT, it would make more sense to just do native vs dockerizing. I have dockers on my unraid server that run Plex/SAB/Headphones and they run perfectly & screwing one up doesn't hurt the others. I'm not sure it makes as much sense with an appliance type of product such as HM -multiple config pages, what goes where?, etc. With Bryan looking at CHIP to reduce cost of the HM, I don't think this will get much play. I suspect it's going to come down to how easy OpenWRT runs on CHIP vs the utility & possibilities that will come with Debian/fullLinux OS on a 9$ piece of hardware that will replace the Pi, wifi Dongle and (possibly) reduce the PCB size.

Just from browsing the CHIP forums today (between that & the C-Bot discussion, I think I'm inadvertently stalking Bryan), it looks like OpenWRT support will happen sooner rather than later, unless there's a showstopper not yet known (and there's a lot of unknowns). That gives a small step change to CHIP from Pi.
Then you have CHIP able to run full-on debian, which could make sense as HM grows/adds functions.

I'm crossing my fingers - I should receive my CHIP just before I receive the Meater probes. The 9$ bluetooth to wifi bridge looks a lot better than the $100 one that Meater sells.

Bryan Mayland said:

I'm not exactly sure what docker is or containerizing means...
.
..The problem I have with all these cool technical solutions is that it comes down to the fact that somewhere there has to be a service running.

Click to expand...

Containers takes advantage of newer features in the linux kernel called LXC ( LinuX Containers ). Nothing in my first post requires any "always on" service that is running somewhere out. This is basically letting you run a virtualization layer on the raspberry pi.

What Docker allows you to do is launch multiple OS/App instances, all sharing a single kernel.

Rather than booting directly into OpenWRT, you would boot your raspberry pi with something like raspbian as the main OS and install docker, or an image that's already got docker installed and anything else needed.

You're now ready to start your docker containers.

Container 1 = LinkMeter OpenWRT - This starts up OpenWRT and everything for linkmeter runs and talks to the HM board.

Now lets say you wanted to extend the functionality of linkmeter to store the data in a mysql DB. Your choices are either modifying the OpenWRT image to include mysql, or you launch a second container running mysql and a util that talks to the LinkMeter container to stream the data directly into the DB.

You could even go one step further and run the DB in 1 container and the data processing util in another container.

From a development standpoint, you get the advantage of being able to run "version X" of linkmeter in a container and if it fails miserably, you just launch the last known good container version.


Anyways, this was just a brainstorming post.

CHIP looks like a great option for the heatermeter. Containers, interesting, but it seems like overkill.

Hi Steve and all,

Although this is my very first post, I have been lurking a lot! I very much like your (@Steve_M) idea. While I'm building a couple of HM on a Raspberry Pi B+ according to Peter F's and Bryan's designs and I believe you have something to do with that as well, I'm eager to reserve one to try out your thought process.

Another nice link for a Docker example is:
http://blog.xebia.com/docker-on-a-raspberry-pi/

Happy to share my findings soon (hopefully before end of the year)!