The LinkMeter Snapshot and YOU


 
Glad you like the changes!

I probably won't move the Light link, it is something I don't think should be part of the main navigation since it is its own thing. You can just bookmark the link though and get to it easily that way?

EDIT: I mean ideally the whole webui should be rewritten. It started out being designed for mobile-first but as more and more features are added and the capabilities increased I've realized it has become less and less cellphone friendly. A whole lotta scrolling around and zooming in and out now days. A rewrite is on my todo list but I've done three new full mockups now and hated every one of them once I was halfway done so it is just waiting on me to have the proper inspiration to come up with something I like.
 
Last edited:
Bryan Mayland said:
AVR firmware 20200107B:
  • Enabled noise diagnostics in the standard build, no special firmware necessary any more

New snapshot firmware
  • Includes AVR firmware 20200107B (and 20191226B changes)
  • [www] Adds support for Inkbird thermistor probes used in models IBT-2X, IBT-4XS, IBT-6X. I calibrated one of these from 45F to 200F and it should be within about 1F across that range. I wouldn't recommend using one for a pit probe because I can not do the correlation up to temps above boiling.
  • [www] Reorganized the list of themistor presets
  • [www] Modified the noise graph display. Now shows probe names instead of ADC port number in reverse order, and added a button to turn off noise dumping. To turn on noisedumps, click a probe's noise icon (yellow / red lightning bolt) in its respective box when logged in. It takes up to 10 seconds for the dump to update so be patient. To turn on noise dumps even if no probe is showing a noise warning indicator, press 'N' on your keyboard or use the configuration page's "Raw set command" to set "tp=,5"
  • [www] Pause updating the graph on the home page when the browser tab isn't visible to save CPU cycles
  • [www] Fix HTML error in credits page
  • [wrt] Silence net.nf_conntrack_max is an unknown key error
Click to expand...

What option do I select for the inkbird probes please?
 

Attachments

  • Untitled.png
    Untitled.png
    11.6 KB · Views: 3
New snapshot releases for both the AVR Firmware 20201120B and Pi image (which includes the new AVR Firmware too)
  • [lm] Add parameter to LMSS to stream only hmstatus-type messages, useful for MQTT streaming e.g. `lmclient LMSS,1`
  • [lm] Flush the output after each lmclient line output to remove buffering delay when streaming
  • [hm] Reset pit TemperatureAvg when changing units to prevent D term going bonkers due to the value changing
  • [hm] LidOffset of 0 now disables lid mode detection (in the HeaterMeter itself)
  • [hm] Include units in HMPD, remove pidb reporting (zeroed out)
  • [hm] Report the PID units when changed
  • [lm] Scale peak detector thresholds by PID units and Setpoint
  • [lm] Add external LidTrack to peak detector plugin
The last one is the major feature and is still waiting on UI in the config page to enable it. I'm not going to finish the other changes I am making to the config page today, so I figure I will release it now for anyone wanting to try it. Since there's no way to turn it on in the webui, you'll need to go to System -> Startup -> Local Startup and add a line to turn it on. If you haven't added your own stuff to the startup script then just make it look like this:
Code: 
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

uci set linkmeter.daemon.lidtrack_enabled=1

exit 0
If you've added your own stuff to the startup script, I bet you'll be able to figure out what the important line here is ;) IMPORTANT: You'll probably want to disable the existing lid tracking by setting "Activate at X% below setpoint." on the config page to 0, and extend the duration beyond the default, because LidTrack should now end Lid Mode early as it sees fit. I set mine to 600 seconds. Be sure to test it once before relying on it!

For more information about LidTrack, see the dedicated thread Feature Spotlight: LidTrack Smarter Lid Mode Detection. Any questions about it or bug reports specifically about it should go there.
 
Might have to do a quick test run today to see how it works. I like the other updates added to the update. Definitely going improve the control and HM meter function. Todays test would give me a chance to test placement of thermocouple for big bird cook. Need to locate closer to heat source instead above bird in top of dome. Normally I position the thermocouple in the upper dome area around the dome thermometer. Added the script and ready to go when it warms up.
 
FYI, I just flashed the latest snapshot release and after reboot linkmeter said it has no communication with the AVR, no temps were showing etc. I flashed back to the snapshot I downloaded 11-11 and it was working again. I re-downloaded the latest snapshot and flashed again with the same result, no communication.... so I think there is some kind of issue with the snapshot this time around.
 
Brian,
Doing some testing and ran into something odd. As soon as my grill reached setpoint temp. I got a lid open detection and started to count down. I am including graph showing the trigger. So I found out what the issue was I believe. A screen that I have never seen, probably because I have not edited the system/startup page. So the test continues. Now to the bad. Soon I lost communications with the AVR like Ralph posted above. Spent time going through the Wi-Fi setup and no luck. I removed flash card and loaded previous build, but kept getting same issue. If I was close to my master router, it would connect on 2.4ghz for about a minute, then drop. I switched to 5ghz radio and both my master and node routers connect and hold. So far on 5ghz radio I have not dropped comms. Prior to all this happening I ran for at least an hour on the 2.4ghz radio before any issues. After the first issue with my false lid detection, I started to get dropout from my thermocouple. Tried 2 more couples with the same results. All 3 were brand new. Will dissect them today when I get a chance and make sure the junction welds are not cracked. Lastly, and this one really confuses me, is the HM controlled temp is now within 10-20 degrees of what my grills probe reads. I tried a thermocouple on the grates down low and at my usual spot about an inch or two away from grill probe up high. My grill grate thermocouple is isolated from lump by ceramic plates, so no direct flame. Also used a brick on the grill for load. I have not seen these all match like this for a couple of years. Thought I would add this too. Just powered up HM and it connected to the 5ghz radio and is holding just fine. This is from my master mesh router in my office which is 3' from HM.
Other than what I listed above, it looks like I might have to retune the PID loop. After I verify the health of my thermocouples, I should have time before Thursday to test and tune if needed before big bird gets cooked.
Save Script screen..png

False Lid open trigger.png
 
RalphTrimble said:
I think there is some kind of issue with the snapshot this time around.
Click to expand...
I just downloaded snapshots for both Pi versions and tested them on both sets of hardware. Then reinstalled the previous snapshot 20201013 on one of them and upgraded it to 20201120 through the webui and also had no problems. Even tried it with a thermocouple inserted. It sounds like there could be a bug crashing the linkmeterd but I can't reproduce it by any installation path?

EDIT: Maybe you can copy-paste your "Full Config Url" here and I can copy your HeaterMeter config to see if there's some config item that's making linkmeterd unhappy?
 
Last edited:
Gary V said:
Soon I lost communications with the AVR like Ralph posted above. Spent time going through the Wi-Fi setup and no luck.
Click to expand...
I'll have to investigate the reason lid mode kicked in when the pit temperature was reached. The last 10 or so lines of the System Log would be helpful for future reference.

There's nothing that's changed with the wifi for like 2 years now though, so I don't know what to tell you about that. If you're conflating wifi with "Not communicating" though, that's not related. It is hard to tell if you're associating the two. Also nothing has changed with the thermocouple reading process or reporting of temperatures so I've got nothing for you there either.
 
When experiencing the lost communication I went to router/s and verified they were connected and or seeing the HM. The HM network information gave the same IP that was found on the router, but the device registration did not show success. If I connected with a hard cable, this took a few try's, I could see the HM finding both my mesh router WiFi radio`s and showed it was connected to the master. Still HM showed no communication. I got positive connections when I switched radio bands. I dumped the 2.4ghz connections many times without success and even tried to make dedicated connections with the master and node routers. Not until switching radio`s did the connection return and not drop out. I know the router radios work because all my other 2.4ghz devices work just fine. I also did a test to check coverage of 2.4Ghz radio/s to see if the radio output throttled down, but it did not. Since my last post this morning my HM has been out in the cold and connected to my 5Ghz radio on my mesh node and is solid and fast.
One other note is when I went back to previous snapshot, I only formatted the sd card and then loaded snapshot img to card. I suspect the problem might be related to the Pi update because this stated after new snapshot and I think I read that there was a Pi code update imbedded as well.
If I knew how to bomb out the Pi, I would go back to previous img and try that again without Pi updates.

The Lid Open error I got was because I did not confirm script addition correctly. The one picture I posted previously was what I found after the false trigger. Never got a chance to verify it worked after I found that screen. Linkmeter told me, in the upper screen with changes not confirmed message, I did not confirm script addition.

I am back on latest snapshot and after I get Xmas lights up and check 2 of my thermocouple probes, I will fire grill back up and test. Probably tomorrow at the earliest.
 
Gary V said:
When experiencing the lost communication I went to router/s and verified they were connected and or seeing the HM.
Click to expand...
What I am confused about is if you're equating "No communication" displayed when go to the Configuration page with loss of wifi signal. "No communication" means the Pi and the HeaterMeter aren't talking, although the wifi would be working because you just loaded the configuration page over wifi.

New snapshot posted:
  • [lm] Spit out an error message when a segmentCall fails instead of crashing
NOTE!! This doesn't actually FIX anything for people who were experiencing "No Communication", now you need to tell me what the error is in Status -> System Log that starts with "(date and time) user.err linkmeterd: Error handling ...."
 
just went and added script for new lid open tracker. Saved change. Then went to Linkmeter and set lid open settings to 0% and 600. Did a save. Now the SVR is requesting a reboot. Reboot fails. pdf of sys log, reboot graph that came up add when I rebooted. It comes back with reboot failed, and current graph. current graph.jpgNo reboot.pngattached the latest system log update for your viewing.
 

Attachments

  • Sun Nov 22 07.pdf
    93.9 KB · Views: 2
One last thing. When I went out to remove power from HM I found it in manual fan mode. Since the HM was working , I switched back to "NO" manual fan and now my AVR communications did not come back.
This all happened when I added Lid Detect script, save, then set old lid detect parameters to 0% and 600secs, save.
Hope this helps
 
Last edited:
FYI, today after reading more about the focus of the snapshot release being lid mode detection I decided to check those settings and try the update again. Yesterday my lid mode setting was at 100% when I did the update, the old way to disable for high heat cooking, and I got no temp display after update.
Today I set the lid mode to 0%, did a fresh download of the snapshot and my HM is working after the flash this time around.... as far as I can tell I should say, temps are displaying etc but I wont be doing a cook today to test further.
I set lid mode to 100% after the update and that didn't seem to break anything, so it may be un related, IDK. The only thing I did different today was set lid mode to 0 before updating, and downloaded the snapshot again today. Yesterday I downloaded and flashed twice, both times resulted in temp display failure.
 
Gary V said:
just went and added script for new lid open tracker. Saved change. Then went to Linkmeter and set lid open settings to 0% and 600. Did a save. Now the SVR is requesting a reboot. Reboot fails. pdf of sys log, reboot graph that came up add when I rebooted. It comes back with reboot failed, and current graph. attached the latest system log update for your viewing.
Click to expand...
I don't think this system log is from the latest snapshot that has the error messages in the log. It should say "LEDE Reboot SNAPSHOT 20201122" on the top of the Configuration page.

RalphTrimble said:
Today I set the lid mode to 0%, did a fresh download of the snapshot and my HM is working after the flash this time around.... as far as I can tell I should say, temps are displaying etc but I wont be doing a cook today to test further.
Click to expand...
Yup, it should still not crash when there's an error but if it was broken on Friday's snapshot, it will still be crashing continuously in the background if using the snapshot from today. You need to provide me the end of the System Log so I can tell why it is crashing so I can fix it. I would NOT COOK using the snapshot if it was crashing for you previously because nothing has been fixed yet. Your "Full config URL" might also help in diagnosing the issue, but checking the log on the latest snapshot will at least tell me where it is crashing.

100% is still fine to use as the trigger level, that's what I did all my testing with, but 0% is now the preferred way to do it and it won't trigger at 0F (I wouldn't know if it did this previously, but theoretically it would trigger at 0F if you're running with 100% trigger threshold).
 
Brian,
Not sure this could be an issue, but here is what I just did to get the AVR communication loss to come up. The HM seems to work when this happens, but l Linkmeter is down. The last time the issue came up I just entered and saved script. Everything was still working. Next I changed the old lid detector settings to 0% and 600secs. As soon as I hit save, the message came up with ARV communications lost. When I looked at my HM, it had switched to manual fan and it displayed 0% with an arrow pointing down. Prior to this, the HM was still in off mode. I pressed left button to get the HM to go to off and the local HM seemed to still work. The Linkmeter connection was still giving the AVR communication error. I thought the snapshot of the system log I sent was of that event. The timestamp matched what I did at the time. Currently I am using the 20202211firmware. Will try to get the log next time it fails. Right now, no issues
 
I am not sure what is going wrong but I have been able to get it to fail now too. I've got numbers showing on the home page, config page says "No Communication", no error message in the log.

I'll have to pick it back up tomorrow morning though, but hold off on any more testing because at least I am able to reproduce it now.
 
Glad you experienced the problem. I thought I was going bonkers. With that point, is there a place where we can download previous snapshots?
 
No there's no previous snapshots.

I've spent 5 hours now trying to reproduce the issue again and have not had any luck. It happened last night that one time, right as dinner was finishing so I had to walk away, but now I've tried everything and it just won't fail. When it failed for me, I saw a few "checksum error" messages in the log from during the startup, which would certainly cause the "No communication" symptom, but it wouldn't fully break the home page so I am not sure how that happened for you, @Gary V. "Broken" for me meant I had data on the home page / graph but No Communication on the config page. I have not seen any errors reported by the new "Don't crash the server" logic.

What I'm focusing on right now is adding more robustness to the startup routine. It has been on the TODO list for years but it rarely causes a problem and is always fixed using the "Reboot AVR" button so it hasn't been a priority.

The current snapshot seems to be working fine for me so I don't feel like there's any need to take it down or roll back at this time. If anyone is experiencing an issue, perhaps responding with what Pi they are using and their "Full configuration URL" from the config page might help me diagnose that.
 
You must log in or register to reply here.

 

Back
Top