The LinkMeter Snapshot and YOU


 
Brian,
When my grilled reached temp, i noticed i could not maintain temp. Temp started dropping off and never recovered even when the servo showed it was open 50%. Thought maybe the thermocouple was flaky so i changed it. No change. When the temp dipped, servo would open and the fan would show 0% on the graph. So i checked the invert and then when the servo opened for more air the fan followed. the grill would then maintain temp. Then i let it settled for 15 minutes and control was working fine. I decided then to make a tweak to the "I" value from .0032 to .0034 and waited for the change, and 10 minutes after the change the controls went nuts and the temp dropped out and the controller locked up. I rebooted and the controls never really recovered. I reloaded 20200214 and all is working we. Back to normal. I do not need to check invert box for fan. Very interesting. The firmware i was using was the latest from the download page.today`s cook.jpg
 
Last edited:
Well that certainly is weird, but I've never seen anything like that or seen a HeaterMeter lock up in like 8 years. Those temperature drops look very suspect, unless you're opening the lid or something at those points. Also were you adjusting the setpoint or is something else going on there?

I've tried all the combinations I can come up with and even changing all the parameters all over the place I get exactly what I manually calculate the output should be. We're both on the same version too, 20200214 which is the latest snapshot on the download page.
 
here is more for the fire. never opened the lid till cook was done at 2:30 pm. first major drop i did a reboot and then waited. the second one i changed probe when it dropped. when it started dropping again i reload the 20200214 firmware. the last 2 who knows and then it started to stabilize when it started to get up around 40 degrees. As you can see early on the fan was acting strange. Way to fast on graph, even though it was hardly running. Problem stabilized after reload of image, but not even sure with that. Never experienced this either. I have re terminated the connector on the thermocouple probe in case that might have been an issue, but that connector under a magnifying glass looked good. Only other thing which could been an issue was i started cook when it was in the 20`s and a little wind, but not enough wind to cause issue with damper. I did order some new servos, hope according to tower pro website the dealer they recommend sells real TP parts. Noticed the current servo does have temp drift problem so i will replace. Found that only after control stabilized for the rest of cook.
 
I don't know what's going on with your setup, especially because reloading the firmware does nothing apart from reset the AVR and database. The Pi and database exist outside of the control function of the device, so there's no reason to reload its firmware. Rebooting the AVR resets all the internal state, which may reset something which is creating the symptoms you're seeing? There is a "Reboot AVR" button in the Configuration page that you can try as well, instead of reloading the firmware. When you say you rebooted, did you reboot or did you power cycle the device? A reboot would just restart the external processes but a power cycle would also include an AVR reboot.

If you want to pursue this further, please make a new thread about it instead of posting here since I do not believe this to be related to the snapshot firmware.
 
Wow I've been forgetting to post the changes to this thread, huh? Not that there has been very much going on, but let's get caught up
  • [www] Option to show both Fan and Servo output on home screen
  • [hm] Allow servo ranges to be reversed
  • [lm] Enable CORS on /lm/stream and /lm/hist if allowcors is set
  • [wrt] Update ca-certificates to fix heateremeter.com SSL error
  • [hm] Add LCD boot menu. Shows avr firmware version on boot.
  • [hm] Beep when entering the engineering debug menu non-probe item. This is accessed from a left long-press from the "Manual Mode?" LCD menu on the device.
  • [hm] Fix ADC dump reporting too many readings for the button pin
 
  • [www] Add a "Reboot AVR" button to the config noconf template. Sometimes this can fix a wedged communication issue when the AVR and the Pi are getting their messages garbled.
 
  • [www] Make iframe popup more generic, convert archive page to POST using iframe
  • [www] Add QRCode popup for apikey to conf page
  • [www] Use about:blank as a clear iframe target since the javascript:false does not seem to work

The change to the archive page has been a long time coming. That was something I wrote as just a "Well the backend is there so I'll come back and make this better later" that I never got around to. Now when you stash a database, reset the database, delete a database, or set a database as active, it will pop up a dialog instead of going to a new page you have to go navigate back from. The page also reloads itself to show the new stashed file instead of forcing you to reload-- it is like a real working webpage now.

Pedantically, the stash uses POST now as the HTTP method which is what it should have been using all along instead of a simple GET action which was easier to implement but bad programming. The next build will enforce that all stash operations be done over POST now (already in, but forgot to include it in the build).
 
so i just downloaded the latest snapshot and tried to update my unit and it will not update by going through the avr path or sytem/restoreupdate firmware path. it shows img in the upload stage and then drops connection with 80% complete. heatermeter never restores and the usual image flashing progress page never shows on screen. Really do not want to open case and flash that way if necessary.
 
So i went ahead and reformatted sd card and then updated image. Booted up fine and is working properly. One thing though, with the filter in the off state, my thermocouple pit probe temp is rock solid. When switched to 50hz or 60hz the pit probes jumps around between .5 and 1 degree. Tried with battery and plug in power source. Same thing with the readings. I am using a brand new pit probe and I have tried the old one and an even older thermocouple with the same results. Thought this is kind of of strange,
 
Brian
Problem solved. The issue was with a new ASUS sound driver for my motherboard. Caused severe slowdowns of my web browser and other strange events that finally went away after uninstalling latest sound driver stuff and then re-installing the previous sound driver version. Good old ASUS strikes again.
 
Whoa that's crazy! It is really weird I had something similar happen last year when the audio driver got automatically "upgraded" as part of some Windows Update. Let me guess, is it a RealTek audio chip on that motherboard?

You can view the raw readings from the probe by going to the home page and pressing the "N" key (for Noise dump) on the keyboard when you're logged in (it doesn't have a Login link on the bottom of the page). It should look like this, bouncing back and forth +/- 1 or 2 units at the most. If it looks like a sin wave that fill almost the whole graph, then the noise filter should be helping, if it is full of just a buncha random jumpy values, then the noise filter won't help. There shouldn't have been any changes that affect the probe measurement and calculation bits unless I've made a big mistake somewhere.

In the future when you do the upgrade if you have similar issues uploading the img, it is best to let the HeaterMeter download the update itself instead of you downloading it then uploading it through the webui. Just use the "Download .gz" link from the download page. The wifi information on the bottom does not need to be filled out, but the version does have to be selected from the top half.
 
You guessed correctly, RealTek driver. It did not install it`s self, but had bad results for computer. That how I noticed the issue first was with the noise dump from the graph. Along with the Edge browser running really slow and erratic, I decided to remove last thing done, RealTek driver and all was well after that. All is well in PC land again. Going to smoke a large turkey breast today with a new thermocouple probe I made. Hope the probe`s response is not too slow, but will find out a little later.

Also things were so screwed up the download feature of the heatermeter would not even work. After the driver issue was corrected, I was able to download and install driver from heatermeter configuration avr page. Things were really messed up.
 
  • [lm/www] Ramp mode now can average multiple temperature probes instead of being tied to a single watch probe. Target Temperature default changed from 200 to 205 (because the food will never actually reach the target temperature)
HeaterMeter-ramp-mode.png

You'd never guess (I certainly didn't) that the 15 minutes it took me to implement this on the backend would be crushed by the 6 hours it took me to make the checkboxes work the way I wanted them to! Ramp mode is great for going to bed and not worrying that your smoked meats will shoot past the done temperature. After your watch probe passes the trigger temperature, the pit setpoint is lowered so that the watch probe and setpoint converge at the target temperature. That's the theory, but in practice it will take like a day for them to converge so I've never once completed a ramp mode ramp. It does slow down the cooking after the stall which can be advantageous when you put food on a little too early.

The other way you can handle this is with an alarm with a SetPoint action: once the food reaches done temperature, cut the SetPoint to a hold temperature (160F). The problem with that action is that the fire will usually go out when dropping in one big move since the damper will be closed for the half an hour that it takes to go that low, and the blower will kick in and then start actively cooling everything. The two features can be used together as well, with a ramp target of 210 and an alarm SetPoint action at 205 although there are still no guarantees the fire won't go out during the alarm temperature cut.
 
Heh.... in my monster GF, dropping from 275 to 175 via a SetPoint action takes about 3 hours right now. And, amazingly enough, I don't lose fire.

I have some cheap charcoal left, I'll see about updating to the latest snapshot and running a quick test if you're interested.
 
Haha wow that's a long time, I can see why it doesn't go out! I don't need any testing done, it is just a tool for everyone to have available as a way to delay / end their cooks. When I showed the Ramp feature to my Dad last year he suggested the option to average multiple probes and I thought it was a good idea. I don't think he's ever used the ramp mode though, so I don't know if I can ever make him love me (sad slumped emoji).
 
New snapshot releases for both the AVR Firmware 20201009B and Pi image (which includes the new AVR Firmware too)
  • The noisedump graph now has negligible performance impact on the HeaterMeter operation. Previously, every time it went to send all the graph data, it would pause all the internals during transmission to prevent the processes from corrupting the data it was trying to convert to send. This took on average about 250ms, so it wasn't terrible, but users with "A/C input line noise filter" enabled could frequently get a bad temperature reading during this time due to the filter requiring a continuous set of samples. The new system just pauses the noise capture instead of pausing everything.
  • The noisedump now uses a differential encoding method to send the data instead of a comma-separated raw list. This reduces the bandwidth required to send the graph down to about 25% of the previous method. It also comes in its own server-sent even message instead of coming over as a log message. This requires the corresponding decompression code on the webui side, so running a new AVR Firmware with an old webui will not display any noisedump graphs, however the webui supports the old and new method so running an older AVR Firmware with the new webui works.
  • Host interactive menus! The heck is that? The Pi can now create more complex interactions with the HeaterMeter LCD including reacting to buttons.
  • Netinfo LCD menu. The first host interactive menu is a network information display. Currently it just has the IP address again (which previously if you missed seeing it was gone forever), and the status of the HeaterMeter Device Registration process (http://heatermeter.com/devices/). This second one can also tell you why device registration is failing if you don't have any devices showing up in the list.
  • MQTT packages now included via mosquitto_pub / mosquitto_sub / libmosquitto. I'm hoping to integrate this into the linkmeterd process so it can forward the HeaterMeter raw data to another machine, but you're welcome to work on your own integrations because I am slow.
 
Bryan Mayland said:
  • MQTT packages now included via mosquitto_pub / mosquitto_sub / libmosquitto. I'm hoping to integrate this into the linkmeterd process so it can forward the HeaterMeter raw data to another machine, but you're welcome to work on your own integrations because I am slow.
Click to expand...
Nice! Can probably whip up a simple cron job that publishes the output of lmclient via mosquitto_pub and listen for events via mosquitto_sub. Alarm scripts that use MQTT could also tie nicely into Home Assistant.
 
Yeah that would be the simplest and quickest way to push data out of the HeaterMeter. I'm not sure if it would be helpful to make it so the output of `lmclient @LMSS` could optionally just be ONLY the hmstatus JSON and not any of the other event types or the "event: xxxx" header. Then you could just pipe `lmclient @LMSS | mosquitto_pub -h myserver -t "heatermeter/hmstatus" -l` continuously and get updates every 1-5 seconds. I think the longer term goal would be to get it to dump all the data to another server, so it would be mirroring the state of the local Pi exactly and then cloud-based webui is possible.
 
And that's what I've done! I rewrote a bunch of the streaming status code to allow it to be filtered per-client, which means you can now stream raw HeaterMeter status JSON over MQTT as easily as this:
Code: 
lmclient @LMSS,1 | mosquitto_pub -h myserver -t "heatermeter/hmstatus" -l
myserver is the MQTT server you want to publish to, and the -t topic can be any topic you want.

In doing this, I found that lmclient was buffering its output as well. I don't believe it was being buffered going to the web browser (streaming through HTTP -> lmclient object -> socket -> linkmeterd) but if it was then now it isn't! But it probably wasn't. It did affect MQTT streaming though and I guess any other user scripts that relied on `lmclient @LMSS`

The snapshot published today includes this change. EDIT: And is likely to become the v15 release candidate if there are no issues in the updates put out this week.
 
Last edited:
Bryan Mayland said:
Netinfo LCD menu. The first host interactive menu is a network information display. Currently it just has the IP address again (which previously if you missed seeing it was gone forever), and the status of the HeaterMeter Device Registration process (http://heatermeter.com/devices/). This second one can also tell you why device registration is failing if you don't have any devices showing up in the list.
Click to expand...
Thank you for this! on my old set up I set my router to assign a static IP for the HM. with this I don't need to do that anymore. btw I am loving al the "new" Updates. I haven't updated my old heatermeter in years, I am finding all sorts of new neat changes.

one request... could you move the "light Mode" link that shows up in the bottom right of the screen to the bar under the graph? I love that light mode for my cell phone, but it is a paint to get to.....
Light page request.png
 
You must log in or register to reply here.

 

Back
Top