Feature request: Public server for displaying progress/results

[Ron Van Iwaarden]

Ok, I know I am new here and, in fact, my first heatermeter won't be here until next week but I have a feature request for heatermeter already.

About two weeks ago, my buddy posted a link on facebook to his smoker temperature control, a flameboss. I thought this was the coolest thing in the world, having struggled with temperature control on my WSM so I started researching smoker temperature controllers. The flame boss was pricy at $350 if you wanted the internet feature and I eventually found the heatermeter which I thought was far cooler and more fun because of the openness of the project.

The internet capabilities to show a cook over the internet are wonderful while the heatermeter is on but, once it is off, the graphs go away as compared to flame boss where data are stored on some public server somewhere. I know heatermeter already phones home to a public server so you can find the IP address of your heatermeter at http://heatermeter.com/devices/. It would be cool to have this feature extended to also publish and archive the stats of a cook. It would be nice for those who are unable to punch holes through their firewall to display live data as well.

The code to do this is probably relatively simple but the more significant issue I would imagine would be the data load for someone's server and maintaining that server.

Another option would be to create a server that users could install on one of their own machines that does not get turned on and off like the heatermeter does and each user could store their own data. This would require the heatermeter to have a configuration page to tell it where to send the data as the cook runs.

Anyway, just a nice to have feature that would build on the awesomeness that has already been developed.

--Ron

 

[Steve_M]

You mean something like this?

It's a simple ask, but really, there's a lot more involved to it. If you take the route I chose, you need to setup a thingspeak account, setup the channels and then use 3rd party libraries/tools to display the data.

I've got the scripts and html up here.

thingmeter.sh is what sends the data to thingspeak via a cron job and thingmeter.html display the data.

 

[Ron Van Iwaarden]

Certainly in the direction I was going. I was thinking about something where one would archive specific cooks. So I could have

https://myserver.something.other/vaniwaar/7962 which was a cook of a brisket on 8/17/2015
https://myserver.something.other/vaniwaar/8452 which was a cook of turkey on 12/25/2015
https://myserver.something.other/vaniwaar/9307 which was baby back ribs on 3/23/2016
https://myserver.something.other/jblow/14 which was Joe Blow's smoked chicken on 5/17/2015
...
https://https://myserver.something.other/vaniwaar/current which is whatever is currently cooking (if anything) on my heatermeter

How did you set up what you showed? Perhaps this could be done without touching the heatermeter code and making a standalone server which is something I could do as a separate standalone project!

--Ron

 

[Steve_M]

If all you want to do is save the graph, you can download a png of it from the archive section and slap it on a photo sharing site.

I didn't modify any heatermeter code for this to work, it's a script that runs on the heatermeter via a cron job. The nice thing about the raspberry pi on the heatermeter is that there's plenty of resources left over to run misc things like this without any worry of creating a problem. I posted a link to the scripts in my first reply.

 

[Ron Van Iwaarden]

First time I pulled up your post it only had the first line. Curious. Anyway, I think I have the initial idea of a solution.

This describes ways of querying the HM data including one that streams the data. So, I thought about writing a program that has a list of 'users' and their HM urls. It would, every x minutes, ping that HM to see if it is up and running. Once up and running, it would then attach to that HM through the streaming URL and download all the data until the HM goes away. That data would then be stored as a single 'cook' with a unique ID for that user.

The program would also then have a HTTP server side and would be a sort of directory structure of users/cookID. Clicking on a given cookID would then generate the standard HM graphs of the data as a PNG similar to what your script is doing. Perhaps I could just store the PNG rather than all the data but I would need to think about that. If the user were logged into the server, (s)he could type in some data about the cook, like short and long descriptions, perhaps some notes about PID or other things related to the cook. The user would also have the ability to delete cooks from the database as well.

I am not too sure about how to display the live stream because I don't have a lot of experience with building 'live' web pages but this would be a nice time to learn.

The nice thing about this approach is it requires no changes to anything on the HM, requires no special software running on the HM and only needs a URL to monitor for a given HM. It does not require recompiling when HM is upgraded to new/different hardware and would work with HMs from different versions of software and hardware as long as this interface stays consistent. Finally, it is also a tightly contained task that I can do on my own as soon as my HM arrives!

--Ron

 

[Matt Fine]

To display the live cook, just provide a link to the user's HeaterMeter whenever you see that it is active.

 

[Steve_M]

Your first post says this would be good for those who can't punch a hole in their firewall to allow external access. If you're doing a remote polling of data, you'll need to be able to get at the heatermeter sitting behind the user's router/firewall, which requires them to setup port forwarding.

Realistically, the device with the data ( HeaterMeter ) should be sending the data off to a remote location ( <insert random cloud service here> ), which drastically reduces the complexity of things on the end user's side. This is pretty much how every connected home device works these days. My Nest thermostat and WeMo outlets and light switches didn't require any network changes on my end. Once I got them onto my home wifi, they establish a connection with a remote endpoint and send and receive data that way.

This is basically what DavidNP did with his Espress for HeaterMeter setup.

That being said, I'm not trying to discourage you from doing anything, I'm just trying to point out some road blocks and give advice on a more ideal approach.

 

[Ron Van Iwaarden]

Your first post says this would be good for those who can't punch a hole in their firewall to allow external access. If you're doing a remote polling of data, you'll need to be able to get at the heatermeter sitting behind the user's router/firewall, which requires them to setup port forwarding.

I realize I am giving that up but am looking at this as a two step process. First, get the server done where it pulls the data. Then I can look to writing a client that lives on the PI and pushes the data. For someone who can/will punch a hole in the firewall, the first method can be used. For the second method, the person needs to be willing to SFTP and SSH into the PI and edit configuration files. Neither solution is 100% of what I want but it is along the right path.

Realistically, the device with the data ( HeaterMeter ) should be sending the data off to a remote location ( <insert random cloud service here> ), which drastically reduces the complexity of things on the end user's side. This is pretty much how every connected home device works these days. My Nest thermostat and WeMo outlets and light switches didn't require any network changes on my end. Once I got them onto my home wifi, they establish a connection with a remote endpoint and send and receive data that way.

EXACTLY!!!!! My ideal solution would be for HM to work just like Nest and WeMo work! However Nest and WeMo (and Flame Boss) all are companies that provide the server side of things which HM does not have. If Nest ever goes out of business, my Nest thermostat becomes a dumb thermostat/hockey puck. That is why I am working on writing a standalone server which can provide the server side of HM. If, at some point Bryan would feel that this is cool enough it could get integrated into HM source with a configuration page, defaulting to a server that perhaps he provides. However, the server code is public and anyone could set up their own server if Bryan decided to stop running the default server.

This is basically what DavidNP did with his Espress for HeaterMeter setup.

This approach is cool except for the fact it requires one to further modify the hardware. Again, I am looking for something that is easy to setup and, personally, any soldering that is more complex than sweating copper pipes together is beyond my abilities...

That being said, I'm not trying to discourage you from doing anything, I'm just trying to point out some road blocks and give advice on a more ideal approach.

I appreciate the suggestions. Writing software in a vacuum is, IMHO, not a good way to go. Having others critique a plan/design makes things much better in the end because the collective we are smarter than any individual. Your suggestion of how to handle the 'live' cook data was perfect and one of those things I wish I would have thought of myself...

 

[Matt Fine]

The HM already has the ability to save (archive) the data. You could write something to run local to archive the cook and then send the file to the server.

That would not cover live cooks, but it should be fairly simple to do.

 

[Ron Van Iwaarden]

The HM already has the ability to save (archive) the data. You could write something to run local to archive the cook and then send the file to the server.

That would not cover live cooks, but it should be fairly simple to do.

Thought about this too but the user needs to actively do something at the end of a cook rather than just have it happen automatically. This may be an itch that only I need scratching but I want it to happen automatically. The user should not have to do anything after it has been configured and every subsequent time they use the HM, things are just done.

 

[Len M.]

Ron, I understand your desire for an automatic upload of HeaterMeter data, but I for one would rather not tell the world I have just powered up my BBQ controller. It would be nice to be able to easily share the data if desired but definitely not automagically.

There could be a lot of undesirable possibilities for automatic data shares, and it would be wrong to have to take action to NOT share.

 

[Ron Van Iwaarden]

Agree that there should be a way to disable automatic publishing and this should be the default.

 

[Steve_M]

Since this is a community / DIY project, there's no central logging solution. It would be easy enough to bake-in something that auto-logged the data to thingspeak, which is what my script is doing. I'm sure some of the cost of the flameboss goes towards running the backend that stores the cook data. Have a look at my script. it's not doing anything complex. It's taking output from lmclient and storing them as 7 unique data points in thingspeak ( set point, lid state, fan speed, probe[0-3] temp ).

 

[Ron Van Iwaarden]

I was just browsing the wiki and found the todo list. Heatermeter Live is essentially what I had been suggesting and is already at least bubbling around the brain of Bryan...

--Ron

 

[Bryan Mayland]

Yup exactly where that is going to go some day. Some sort of basic "current status" that you can make public or private, as well a dyndns sort of redirector (using my smoky.link domain) that can get you to your actual device. Then stashes can be uploaded to the server as well for viewing and sharing. As you can see there's a lot a lot a LOT to it and there has to be the infrastructure there for it, it's not on the immediate hotlist though.