HeaterMeter OS Questions: Is it just modified Open WRT?


 

Jon Singer

New member
What exactly is HeaterMeter? I haven't worked much with OpenWRT directly but I used ddWRT back in the day. How open is it for modifications? Can it be forked? How much of the router/firewall software has been trimmed back or gutted out?
 
The Pi side of the system is all OpenWRT with new packages created for things we need, like the custom linkmeterd that handles all the background HeaterMeter stuff. It is cut down to just be what we need so it can be as small as possible. Most of the "router" type stuff is removed, like firewall control, QoS, quotas, traffic logging, and just the stuff needed to be a client device remains. It is actually LEDE, because they broke off and took most the good development ideas with them so I converted from OpenWRT to LEDE. Now they're re-merged back to OpenWRT and I haven't had the time to re-sync with their tree.
 
Thanks Bryan. I appreciate that explanation. I think I may have had a brief exchange with you on another forum about this. I'm looking for something a little bigger than the stock HM. More sensors, accessories and devices as well as the ability to control multiple cooks at same time. If I'm reading this correctly, it looks like you can run OpenWRT inside docker on a Rasbperry Pi:

https://hub.docker.com/r/nmaas87/docker-openwrt/

I don't want to reinvent the wheel but do not think running multiple instances of HM at same time inside a Pi is the best option. Main reason would be the routing/IP addressing. Navigating to different pages for each cook would be tedious. I'd like to push sensor data into a database and go from there. (Python + sqlite) I'd also like to assign profiles to cookers and coordinate the profiles with LED lights over/under each temp sensor port. This way if cooking two butts and a brisket you can color-code graph lines that correspond to each item as well as the LED next to the temp sensor. Make it idiot proof so the green LED goes into the brisket or the blue K-type LED goes into drum one and the red K-type LED goes into drum two.

Do you think there is any way to expand upon (or maybe fork the processes within) OpenWRT/HM to accomplish this or should I start from scratch and not use OpenWRT?

Thanks.
 
I do like the idea of some RGB LEDs on each port that are configured to match the graph color chosen as a flashy addition.

The problem you'll run into with multiple HeaterMeters on one Pi in docker instances is that there's just the one UART exposed on the Pi so you can only practically connect one HeaterMeter. You could run USB TTL serial modules but that's going to be real messy real fast. There's no getting around the fact that the webui (and backend) is also designed for 4 probes and not N probes so you'll have a lot of work just upping that number and finding that it makes a real mess of the webui being jam packed full of too much information.

Given that you'll probably want to redo all that, you might consider making a broker that runs all the HeaterMeters over USB TTL serial cables (just wire a $2 eBay module to GND, RX, TX on the HeaterMeter and a micro USB output). Each HeaterMeter would have 1 control output and 4 probe inputs. Then your broker just listens to all the incoming data and stores it / provides graphs. A Pi has 4 USB ports and built-in wifi so you could handle 16 inputs and 4 outputs arranged like an octopus which would be good for probe wire management because all 16 probes wouldn't come out of the same block. The HeaterMeters would still need 12V run to them though if you want to power blowers on them (they could pull off the USB current if no output is needed) although maybe you could be inventive there as well. However, if you didn't need control there are off the shelf systems for data collection and monitoring that would be a zero-software-written solution.
 
still need 12V run to them

Cool. Thanks so much for taking the time to write all that out. This is actually really funny... Read the first sentence of this description:

https://www.auberins.com/index.php?main_page=product_info&cPath=14_40&products_id=741

I convinced someone at that yellow company to send me some files for 3D printing (battery interface) and a bunch of other info. I can't share it publicly because they want to see the prototype first (so they can decide what they want to do with it... own/license, etc.). They also make bluetooth batteries and told me what to look for to get battery percentage vs. just 1, 2 or 3 bars via bluetooth. So that's my end-goal. Being able to plug a tool battery into a smoker controller, have it step down to correct voltages and be able to monitor everything --power consumption, battery life remaining, cook stats, graphs, be able to override fan/blower relays, damper servo's, etc. all remote from a phone (or touch screen on the controller). So if I'm at a competition in the pouring rain I don't need to get out of bed at 3am unless the battery is dying. Or when I'm at home on a long cook, I can take 20min and run out to the hardware store, or so we can take a minute to walk the dogs around the block, etc. etc.


I recently picked up a sls printer for a work project so will be perfect to do a controller like this too. Not sure I want to have one controller with 16 temp ports. That's a bit much. But enough to to have two cooks on same controller would be cool. We'll see. Hoping to be able to start with some existing platform/code vs. having to write everything from scratch. Also don't want to step on anyone's toes. If there are projects in development I'm happy to help or support something existing vs. go it alone.

Cheers!
 
Jon,

I recently had an exchange with Bryan in a GitHub issue about this very topic. My interest is in using something other than OpenWRT/LEDE on the Pi--preferably Arch Linux. I am also interested in adding some new data distribution methods, like gRPC. I wrote some software for my weather station that allows for data sharing in a pluggable way, and includes plugins for gRPC, InfluxDB (time-series DB, if you're not familiar with it), etc. I envision writing a replacement for linkmeterd that shares data in a similar fashion. The idea is that you have this simple single-binary daemon that runs on any platform and talks to the HM Arduino via serial or TCP/IP and serves as the backend for almost anything. It could support additional databases beyond RRDTool, provide simple boilerplate code generation for mobile and desktop apps, etc.

If I can get this thing written, I wanted to have a go at building my own web UI and Linux desktop display, like I did for the weather station.

It's a lot of work. The first step, I think, is to properly document the protocols used between the HM and linkmeterd and also linkmeterd and the Web UI.
 
Last edited:

 

Back
Top