The LinkMeter Snapshot and YOU


 
New snapshot 20201123
  • [lm] Add linkmeter.daemon.serial_log option for setting the path to and enabling serial logging
  • [lm] Request retransmit for missing or corrupted config items. Fixes blank items on the Configuration page as well as one reason the page might report "No Communication" even when data is clearly flowing.
This update resolves the issue I had seen yesterday which was linkmeterd reporting it wasn't communicating because it couldn't query the AVR for version information. Strangely, I see this error popping up on about 75% of the boots on my Pi Zero W on the bench here, but it never happens if I just restart the linkmeterd over and over again (hundreds of times), *while* running an ultra-high priority process using 100% CPU, *and* downloading a file over HTTPS through the wifi. I'm wondering if there is something in the boot process that opens or resets the serial port for some reason which corrupts the data.

Making this more robust has been on my TODO list for something like 5 or 6 years, but the couple times I've coded solutions I wasn't happy with them. They were either not much of an improvement or they could get themselves wedged into requesting retransmissions in a loop. What I came up with today is fairly simple but is doing a perfect job of fixing corrupt segments from HeaterMeter even when multiple errors happen in a row. You'll see this kind of error in the Status -> System Log as "linkmeterd: Requesting config retransmit for UCID,HMPD" (where UCID and HMPD are the corrupted transmissions in this example).

I'm marking the issues from the weekend as resolved for now, so please let me know if Snapshot 20201123 does not fix the "No Communication" error or no data appearing on the home page.
 
Brian,
Found snapshot dated 20201013 and went ahead and installed the backup. Went and setup my WiFi and then set the lid open parameters up to the default 6% and 240 Seconds. When I set the lid open to the default settings and performed a save the HM went into manual fan mode showing the 0% with the down arrow. When I booted up the HM was in off mode. Thought this was odd, but is it normal? When it boots up shows the 20201002 which looks good.
 
Gary V said:
Set the lid open parameters up to the default 6% and 240 Seconds. When I set the lid open to the default settings and performed a save the HM went into manual fan mode showing the 0% with the down arrow.
Click to expand...
I've never seen anything like this and it is not normal. I just tried it myself and it doesn't to that on my test system here, with the current snapshot or 20201013 snapshot (just installed and tested).

EDIT: Although it looks like if HeaterMeter is in "Off" mode and you set any configuration item, it will switch to manual mode 0% output. That's a bug in the config page that doesn't understand a starting "Off" state. That will be fixed when I finish the LidTrack config UI changes (not complete), which also changes the SetPoint field to more easily change units (already complete).
 
Last edited:
Thanks for getting back so quickly. Yup, every time I ran into the HM switching to manual fan was when the HM started off in "off mode". Glad you see it too. Good luck with the changes your working on. Will cook my big bird with my current snapshot. Looking forward to the next snapshot.
Have a great T day and stay healthy out there.
 
Brian,
Update. I am running on the 20201123 snapshot with no issues or hiccups. I took some time this morning and flashed a 32gb brand new sd card and put the latest img on that. But I might have figured out what could have caused a lot of my issues. When adding the script, I cut and pasted it from the post you made. I believe that when I originally did that, I added one more spare to the cut at the end of the sentence. So when pasted, it added that no character to the script after the "1".

So the steps I took this morning were as follows:
installed new sd card and set up password and time. Saved settings
added script and hit submit.
rebooted
logged in and then set lid detect to 0%, saved change
then sec time to 600, saved change
At the HM, I then put it back in "off" since it goes to manual fan when I make those changes.
Then I went to system/startup and I noticed a message in upper corner in red a message that said I had 1 unsaved change
went back to Linkmeter and did a save.
Went back to system/startup to see if there was any unsaved changes in upper right corner. non shown. Powered down HM and let sit for a minute and powered back up.
All changes made were still there and HM booted up in "off" like I left it.
Everything is working and stable.

Hope this is good information for you.
 
That sounds perfect. The "1 unsaved changes" thing is because the script sets lidtrack on, but doesn't make the change permanent. "Saved" is a bit confusing because it is saved, just not saved to flash. It would have been fine to leave it like that because that means to remove the change you'd just remove the line from the script and it would disable LidTrack on the next boot. I thought that might be preferable to having to add a different line to the startup script to turn it off which would be this:
Code: 
uci delete linkmeter.daemon.lidtrack_enabled
uci commit
Either way works though, and the UI changes should be coming soon to allow this to just be changed from the webui without having to muck with scripts. It is funny that making the UI takes so long, I've spent another hour on it this morning. The config page is incredibly complicated though because it has to pack and unpack data across multiple fields coming from several different places and different configuration stores. I'd rewrite it to use more organized classes and make it a lot cleaner but this is the last thing on my list for release v15 and I don't want to tear it all apart just yet.

Thanks for all of your reports, you provide great detail that helps me reproduce exactly what you're doing and it helps get things fixed!
 
Brian,
Got one more thing I ran into and not sure this is correct. Currently I have 2 sd cards, one with 20201013 snapshot and one with 20201123 snapshot. When I remove the card with the 20201123 snapshot and replace it with the 20201013 snapshot, the HM boots up telling me I have 20201123. When I go into Linkmeter, it says 20201013. Also the setting that were made with the 20201123 sd card are what I see when I am in Linkmeter with the 20201013 snapshot. The script for new lid open detector is gone with the 20201013 snapshot. I have tried a few reboots, but it comes up showing 20201123 on the HM and 20201013 in Linkmeter. When I go to devices it also shows 20201123b for the device it has located when I have the 20201013 sd card installed.
Not sure how to interpret this. To me when I swap sd cards with different software, it should reflect what version of software is on that sd card. From what I understand, the Pi is dependent on software on the card. Does the AVR retain more than settings?
 
Great observation, Gary! There are actually two firmware versions. First is the "HeaterMeter (AVR)" firmware that runs on the HeaterMeter controller which is shown only on the bottom of the LinkMeter -> Configuration page. The second is the "LinkMeter" firmware image that runs on the Pi, and that version number is shown on the top of every page. On first boot of any new LinkMeter image, it will flash the HeaterMeter with whatever AVR firmware is bundled with the LinkMeter image to sync them up. If you just swap SD cards that have already gone through their firstboot procedure, then the AVR version will persist.

I try to keep the protocol they speak between each other compatible so this usually isn't an issue, but there have been instances where newer AVR firmware will break older LinkMeter instances. In that case, you can just force the sync by going to LinkMeter -> AVR Firmware -> Bundled and flashing hm.hex.
 
Bryan - should I be running the AVR firmware bundled with the 20201123 snapshot release, "hm.hex", dated Mon Nov 06 2017, or from the online repository '/snapshots/trunk/heatermeter.hex', dated Sat Oct 10 2020?
 
I was wondering if that was the case. Nice to know date and the position on the linkmeter page tells you what firmware is running on the Pi and what firmwave is running on the AVR. Never have tried to update AVR firmware by going the the AVR Firmware page in Linkmeter, but will keep that in mind when the AVR looks like it might be acting buggy. Nice that I can just refresh the ".hex" firmware for the microp.
Thanks for clearing this up.
 
Curtis_Aotea said:
Bryan - should I be running the AVR firmware bundled with the 20201123 snapshot release, "hm.hex", dated Mon Nov 06 2017, or from the online repository '/snapshots/trunk/heatermeter.hex', dated Sat Oct 10 2020?
Click to expand...
You should be running the bundled AVR firmware. Thanks for reminding me I forgot to update the snapshot in the online repository. Should be up to the latest now.
 
Snapshoooooooooot!
  • [www] Add lidtrack_enabled to config page, just set the lid detection method to LidTrack and up your duration to at least 5 minutes, but 10 minutes is suggested
  • [www] Enhance setpoint option on config page. Supported units in a dropdown? Wow wowwowowow wow. Now borderline easy to understand?
  • [www] Thermocouple mv/C should no longer display values such as 4.9 as 4.899999999999997
  • [lm] Fix possible daemon crash when enabling Manual Mode
Note that if you added a line to your System -> Startup to enabled lidtrack (uci set linkmeter.daemon.lidtrack_enabled=1) then you should remove that line or else it will force enabling on every reboot. The config page now has an option for this.

For those tracking billable hours, note that it took me over a full day to make these changes. The config page has gotten complicated, yo. This is what happens when you take 100 different parameters packed into 60 values from 4 different methods of setting them and it almost all happens in the view. Compare that to me adding HTTPS TLSv1.2 support to an application written in 2004 which didn't even do HTTPS at all earlier this week, which took 6 hours.
 
Pushing last night's snapshot uncovered a very very long-standing bug so I was able to reproduce it and fix it! New snapshot
  • [wrt] Use the RRD backup as a basis for the system clock on startup instead of a config file in /etc when available. Fixes empty database after reboot after changing config
  • [lm] Add a stop_service function that performs a backup before shutting down
The bug was that sometimes the graph would reset when you reboot / power up. It is supposed to resume within 5 minutes of where it left off, but sometimes I'd boot up and have a fresh graph, with no history. It's been happening for years and years and I never could figure out why sometimes it would just not work. Turns out that in the 24 hours following any configuration change on the Pi (new wifi info, changing alarm email/sms settings, and now enabling LidTrack), the graph would never be restored. Most configuration changes are not stored on the Pi, they're HeaterMeter settings, so it was rare that this was triggered for me.

The first item on he list fixes that, the second just makes sure you lose the least amount of data if you reboot using the webui's System -> Reboot option. I found these this morning when I went to add another feature, so that will have to wait until tomorrow to get started because this took most of my Saturday.
 
Brian,
Went ahead and updated to your current snapshot. Just found a good one for you to try. Go into your config screen page. Make sure you have a damper connected and your heatermeter setup with a thermocouple. Now turn heatermeter to on and lets set it to 60-70 degrees at the heatermeter. I have mine on my office table right now. Now from your config page, go click the wifi page. I get a jump in the control loop. What do you get. This is not the only situation this occurs with Try other page to page clicks too.
 
Gary V said:
I get a jump in the control loop.
Click to expand...
What do you mean by this, like the output changes? I certainly have seen that the temperature can change by 0.5F or so when accessing the Pi connected on USB power. I've never seen that happen on one plugged into 12V though. In any case, if you're talking about the temperature changing when the website loads, that's not a software problem and not related to the snapshot so it doesn't belong in this thread. If that's not what you're talking about then probably still start a new thread and be more specific about the behavior you're seeing.
 
Exactly. The output and fan change. I have a video of this and you can see the damper open and hear the fan change. The heatermeter displays the output going from like 50% up to 85%. Love to figure out a way to send the video to you. 12.5meg I have noticed this back in another snapshot from I believe October. When this happens, the config pages changes to wifi page and the wifi says its scanning for networks. thens it jumps. Act like that task is interrupting the control task. Pretty weird. I have tried new sd cards and overwrite formatting. Still happens.
 
It is not related to the snapshot in any way. I can see that the blower and damper (the outputs) would move if the temperature changes, I don't need to see a video of a damper moving. All the things you do in the webui aren't run on the same device as what controls the output so there's zero chance of a wifi task interrupting the control task. What I think you're seeing is that hitting something in the webui sends out an RF pulse or electrical pulse that interferes with the analog circuitry doing the temperature reading like this dip (which is less than 0.004V peak-to-peak).
1608576715767.png
 
Could be a pulse of some kind. When I set the heatermeter up at the grill, I never see this spike and control manipulation. The only time I see jumps are when I log in or out of the config page. These are small and really do not bother me. I will be using latest snapshot when I cook on Xmas. Just interesting what was going in my office when testing latest snapshot. Must be a good router.
 
Firmware Snapshot 20201223
  • [lm] Add a stop_service function that performs a backup before shutting down. This means if you reboot mid-cook, the graph will have the smallest gap in it. Previously it would have up to 5 minutes missing.
  • [lm] Perform a stash operation if the time jumps forward to save the last session database automatically. See: Feature Spotlight: Automatic Database Archive (autostash)
  • [www] Add rename support to stash page
 
Brian,
Ran into an issue on Xmas while trying to BBQ a roast. I could not connect to my network. I usually do not have any issues with this, but since updating to that latest snapshot I cannot connect. So right now I decided to see if this was an elf playing games or a real bug. It`s real, not an elf pulling my strings.
Now for details. I have a AiMesh network. I use ASUS routers. I can connect to my main router when I have it in the office. When I setup at the grill, it just times out. When I login to router, it see the heatermeter on the Mesh node, the signal is strong, it shows Rx/Tx info, but no connect. Hope this is enough for you to troubleshoot. I downloaded the latest snapshot the same way as always. I am currently on a October snapshot and it connects just fine to both the main and node router.
 
You must log in or register to reply here.

 

Back
Top