Heatermeter webpage works for a bit and then displays blank page?


 

JasonL

TVWBB Member
I have a heatermeter 4.2 that had been working for quite a bit but today I fired it up (didn’t hook up the fan all if it matters). When I plug it in everything works fine, but when I try going back like 30min later the webpage is just a blank screen with a link that says LuCI - Lua configuration interface. Any ideas? If I pull the power and plug in again it works immediately
Edit: has been happening all day. Would work for a bit and eventually I’d go back to the page and it would just display that page. If I click on the link it just sits there and eventually times out. I updated both firmwares to the latest (latest snapshot for avr and v14 for linkmeter) but that didn’t seem to help
 
Last edited:
It sounds like either the web server on the Pi is crashing, or the Pi itself it crashing, or the wifi is going offline. It is hard to say which of the three, but you can check to see if it is still on the network by trying to ping it when you can't connect. I'd say most likely the wifi is dropping off an not able to reconnect for some reason? Perhaps the adapter is going bad? You can also try to use a different SD card to find out if there's an issue with that causing the Pi to hang.
 
I had something similar happen 10 days ago. My 4.2 HM with a recent image stayed on the network (responded to IGMP ping packets,) the main page was apparently still updating, but all other services were failing with a text page referring to LUCI issues. It also was responding to SSH login requests, but failing to authenticate. A reboot fixed the issue, and it ran for another 20 hours without any other problems. This was after 10:00 PM, I was more interested in keeping the brisket on smoke than gathering logs.
 
Thanks. I’ll give your suggestions a shot on diagnosing. It was happening pretty regularly so should be easy to replicate.
 
I got a new SD card and loaded on a new image and things have been running smoothly. It’s just running inside but the probes are all plugged in / similar to how it was running when I had a lot of issues last week. Hopefully no more issues but only time will tell. Thanks again!
 
What should I read into it if it wouldn’t connect a couple hours ago and when I tried again just now it showed up fine? Previous attempts would show the luci link and eventually get a timeout/no response error. Will the web server auto restart after some time period?

The uptime in the Status tab shows 11hr 30min so whatever that represents did not restart

The ipv4 wan connected time shows 11+ hrs too
 
Last edited:
Well that's good news that it isn't crashing out for some reason. The web server also doesn't not auto-restart so that means it is running all the time too. Sounds like it is dropping off wifi and eventually coming back. Check your Status -> System Log and see if there are error messages around the times you're getting the drop outs. It should read just "sending renew" and "lease obtained" along with a few "Discarding duplicate update" and errors saying "'net.nf_conntrack_max' is an unknown key" (not really an error). You can also check Status -> Kernel Log and see if there are errors there as well although the time format is in seconds since boot so you'll have to do some math to figure out when is when.
 
Well that's good news that it isn't crashing out for some reason. The web server also doesn't not auto-restart so that means it is running all the time too. Sounds like it is dropping off wifi and eventually coming back. Check your Status -> System Log and see if there are error messages around the times you're getting the drop outs. It should read just "sending renew" and "lease obtained" along with a few "Discarding duplicate update" and errors saying "'net.nf_conntrack_max' is an unknown key" (not really an error). You can also check Status -> Kernel Log and see if there are errors there as well although the time format is in seconds since boot so you'll have to do some math to figure out when is when.

thanks. I'm finally back in town and getting to try this out. I went ahead and purchased a new wifi adapter and letting that run, though I guess the smart thing would have been to use the old one and check the logs. Thanks for the help, really appreciate it. Will report back my findings when I get some!

-Jason
 
Its been a while and figured I’d try and tackle this issue again. I had been just unplugging and replugging it back in whenever it happened to resolve and it’s gotten old.


I had it running all of last night and today. It worked fine every time I tried connecting up through this morning, tried again around lunchtime and it didn’t work, and then just now and it seems to be back up.

Looked in the kernel logs and nothing interesting at all after initial boot up. Didn’t see anything too interesting in the system log other than the following. Unfortunately I didn’t keep track of exactly when it was working vs not working on if the dhcp renewal is related at all. I have my wireless router give the heatermeter a static IP address of 192.168.1.253.


Wed Dec 18 12:07:35 2019 daemon.err uhttpd[348]: wc: /proc/net/nf_conntrack: No such file or directory
Wed Dec 18 12:07:35 2019 daemon.err uhttpd[348]: sysctl: error: 'net.nf_conntrack_max' is an unknown key
Wed Dec 18 12:24:57 2019 user.info : New -1 peak @1576670813=63.3 half=2460 per=19958 amp=-1.4 gain=1.9
Wed Dec 18 12:24:57 2019 user.info : Ziegler P=1.9 I=0.000 D=154.7
Wed Dec 18 12:56:25 2019 user.info : New 1 peak @1576671979=64.6 half=1166 per=3626 amp=1.3 gain=-0.1
Wed Dec 18 12:56:25 2019 user.info : Ziegler P=1.9 I=0.001 D=28.1
Wed Dec 18 14:26:49 2019 user.info : New -1 peak @1576674215=63.1 half=2236 per=3402 amp=-1.5 gain=-0.2
Wed Dec 18 14:26:49 2019 user.info : Ziegler P=1.9 I=0.001 D=26.4
Wed Dec 18 14:47:41 2019 daemon.notice netifd: wwan (592): udhcpc: sending renew
Wed Dec 18 14:47:41 2019 daemon.notice netifd: wwan (592): udhcpc: lease of 192.168.1.253 obtained, lease time 86400
Wed Dec 18 16:13:41 2019 user.info : New 1 peak @1576682899=64.7 half=8684 per=10920 amp=1.6 gain=0.1
Wed Dec 18 16:13:41 2019 user.info : Ziegler P=1.9 I=0.000 D=84.6
Wed Dec 18 16:43:44 2019 user.info : New -1 peak @1576686043=62.9 half=3144 per=11828 amp=-1.8 gain=-0.2
Wed Dec 18 16:43:44 2019 user.info : Ziegler P=1.9 I=0.000 D=91.7
Wed Dec 18 17:22:57 2019 user.info : New 1 peak @1576688196=64.5 half=2153 per=5297 amp=1.6 gain=-0.2
Wed Dec 18 17:22:57 2019 user.info : Ziegler P=1.9 I=0.001 D=41.1
Wed Dec 18 17:43:39 2019 user.info : New -1 peak @1576689813=63.4 half=1617 per=3770 amp=-1.1 gain=0.5
Wed Dec 18 17:43:39 2019 user.info : Ziegler P=1.9 I=0.001 D=29.2
Wed Dec 18 18:20:34 2019 user.info : New 1 peak @1576691239=64.5 half=1426 per=3043 amp=1.1 gain=0.0
Wed Dec 18 18:20:34 2019 user.info : Ziegler P=1.9 I=0.001 D=23.6
Wed Dec 18 18:45:22 2019 user.info : New -1 peak @1576693421=63.3 half=2182 per=3608 amp=-1.2 gain=-0.1
Wed Dec 18 18:45:22 2019 user.info : Ziegler P=1.9 I=0.001 D=28.0
Wed Dec 18 19:19:29 2019 daemon.err uhttpd[348]: wc: /proc/net/nf_conntrack: No such file or directory
Wed Dec 18 19:19:29 2019 daemon.err uhttpd[348]: sysctl: error: 'net.nf_conntrack_max' is an unknown key
 
Just saw this, not sure what to make of it.

Tried connecting and couldn’t around this time but a minute later was able to

19 01:42:20 2019 daemon.err uhttpd[348]: sysctl: error: 'net.nf_conntrack_max' is an unknown key
Thu Dec 19 01:42:24 2019 kern.err kernel: [82511.270722] rtlwifi: AP off, try to reconnect now
Thu Dec 19 01:42:24 2019 kern.info kernel: [82511.273908] wlan0: Connection to AP f0:79:59:7e:c5:60 lost
Thu Dec 19 01:42:24 2019 daemon.notice netifd: Network device 'wlan0' link is down
Thu Dec 19 01:42:24 2019 daemon.notice netifd: Interface 'wwan' has link connectivity loss
Thu Dec 19 01:42:25 2019 daemon.notice netifd: wwan (31488): udhcpc: received SIGTERM
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[31582]: exiting on receipt of SIGTERM
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: started, version 2.78 cachesize 150
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: DNS service limited to local subnets
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC no-ID loop-detect inotify
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: using local addresses only for domain test
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: using local addresses only for domain onion
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: using local addresses only for domain localhost
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: using local addresses only for domain local
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: using local addresses only for domain invalid
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: using local addresses only for domain example.net
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: using local addresses only for domain example.org
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: using local addresses only for domain example.com
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: using 3 more local addresses
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: reading /tmp/resolv.conf.auto
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: using local addresses only for domain test
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: using local addresses only for domain onion
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: using local addresses only for domain localhost
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: using local addresses only for domain local
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: using local addresses only for domain invalid
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: using local addresses only for domain example.net
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: using local addresses only for domain example.org
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: using local addresses only for domain example.com
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: using nameserver 192.168.1.1#53
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: using 3 more local addresses
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: read /etc/hosts - 4 addresses
Thu Dec 19 01:42:27 2019 daemon.info dnsmasq[10142]: read /tmp/hosts/dhcp.cfg02411c - 0 addresses
Thu Dec 19 01:42:28 2019 kern.info kernel: [82514.940136] wlan0: authenticate with f0:79:59:7e:c5:60
Thu Dec 19 01:42:28 2019 kern.info kernel: [82514.981326] wlan0: send auth to f0:79:59:7e:c5:60 (try 1/3)
Thu Dec 19 01:42:28 2019 kern.info kernel: [82514.986753] wlan0: authenticated
Thu Dec 19 01:42:28 2019 kern.info kernel: [82514.998041] wlan0: associate with f0:79:59:7e:c5:60 (try 1/3)
Thu Dec 19 01:42:28 2019 kern.info kernel: [82515.035013] wlan0: RX AssocResp from f0:79:59:7e:c5:60 (capab=0x1411 status=0 aid=2)
Thu Dec 19 01:42:28 2019 daemon.notice netifd: Network device 'wlan0' link is up
Thu Dec 19 01:42:28 2019 daemon.notice netifd: Interface 'wwan' has link connectivity
Thu Dec 19 01:42:28 2019 daemon.notice netifd: Interface 'wwan' is setting up now
Thu Dec 19 01:42:28 2019 kern.info kernel: [82515.149428] wlan0: associated
Thu Dec 19 01:42:28 2019 daemon.notice netifd: wwan (10151): udhcpc: started, v1.26.2
Thu Dec 19 01:42:29 2019 daemon.notice netifd: wwan (10151): udhcpc: sending discover
Thu Dec 19 01:42:32 2019 daemon.notice netifd: wwan (10151): udhcpc: sending discover
Thu Dec 19 01:42:32 2019 daemon.notice netifd: wwan (10151): udhcpc: sending select for 192.168.1.253
Thu Dec 19 01:42:32 2019 daemon.notice netifd: wwan (10151): udhcpc: lease of 192.168.1.253 obtained, lease time 86400
Thu Dec 19 01:42:32 2019 daemon.warn dnsmasq[10142]: no servers found in /tmp/resolv.conf.auto, will retry
Thu Dec 19 01:42:32 2019 daemon.notice netifd: Interface 'wwan' is now up
Thu Dec 19 01:42:32 2019 daemon.info dnsmasq[10142]: reading /tmp/resolv.conf.auto
Thu Dec 19 01:42:32 2019 daemon.info dnsmasq[10142]: using local addresses only for domain test
Thu Dec 19 01:42:32 2019 daemon.info dnsmasq[10142]: using local addresses only for domain onion
Thu Dec 19 01:42:32 2019 daemon.info dnsmasq[10142]: using local addresses only for domain localhost
Thu Dec 19 01:42:32 2019 daemon.info dnsmasq[10142]: using local addresses only for domain local
Thu Dec 19 01:42:32 2019 daemon.info dnsmasq[10142]: using local addresses only for domain invalid
Thu Dec 19 01:42:32 2019 daemon.info dnsmasq[10142]: using local addresses only for domain example.net
Thu Dec 19 01:42:32 2019 daemon.info dnsmasq[10142]: using local addresses only for domain example.org
Thu Dec 19 01:42:32 2019 daemon.info dnsmasq[10142]: using local addresses only for domain example.com
Thu Dec 19 01:42:32 2019 daemon.info dnsmasq[10142]: using nameserver 192.168.1.1#53
Thu Dec 19 01:42:32 2019 daemon.info dnsmasq[10142]: using 3 more local addresses
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10142]: exiting on receipt of SIGTERM
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: started, version 2.78 cachesize 150
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: DNS service limited to local subnets
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC no-ID loop-detect inotify
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: using local addresses only for domain test
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: using local addresses only for domain onion
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: using local addresses only for domain localhost
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: using local addresses only for domain local
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: using local addresses only for domain invalid
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: using local addresses only for domain example.net
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: using local addresses only for domain example.org
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: using local addresses only for domain example.com
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: using 3 more local addresses
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: reading /tmp/resolv.conf.auto
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: using local addresses only for domain test
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: using local addresses only for domain onion
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: using local addresses only for domain localhost
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: using local addresses only for domain local
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: using local addresses only for domain invalid
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: using local addresses only for domain example.net
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: using local addresses only for domain example.org
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: using local addresses only for domain example.com
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: using nameserver 192.168.1.1#53
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: using 3 more local addresses
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: read /etc/hosts - 4 addresses
Thu Dec 19 01:42:34 2019 daemon.info dnsmasq[10245]: read /tmp/hosts/dhcp.cfg02411c - 0 addresses
 
I think I may just try to replace the raspberry pi B with a raspberry zero WH. I confirmed the pi is not pingable at all when i am unable to connect to the web interface. I already replaced the WiFi adapter last year and that didn’t solve the issue. None of my other devices seem to have any issues so likely related to the WiFi/pi and the zero is so cheap seems like worth a shot
 
I was just re-reading your post and I think I glossed over your first post and thought you said you had tried both the snapshot and v14, but I see you're on v14 with the snapshot avr. I'd suggest trying the snapshot firmware (the whole pi image), since there is an update to the wifi driver for the Edimax module. If that's what you've got, then the snapshot might fix your wifi dropouts since that's what it addresses.
 
Thanks, so just take out the sd card and reimage it using https://heatermeter.com/dl/ to create the right image with the WiFi info configured?

Edit: actually how do I tell what version of linkmeter I’m on? I see this at the very top when I go into configuration.

LEDE | LEDE Reboot SNAPSHOT r4558-438dcbfe74
 
Last edited:
Installed the latest snapshot and will check over the next few days. Unfortunately my desktop is having issues so don’t have anything on the same network that I can just continuously ping the heatermeter to see if the connection ever drops.

Edit: looking pretty good so far. Has worked everything I’ve checked. Will hopefully get my desktop fixed when a new WiFi adapter shows up and can actually just ping it constantly to see if it ever drops
 
Last edited:
Oh for future reference, you don't need to pull the SD card to update your software. Just go in the webui to System -> Backup / Flash Firmware -> Image URL and paste the appropriate download link for your Pi model into the box and go. The links are on the download page, but they're just RPi 2/3 or RPi A/B/Zero.

There's not a good way to see what version of the Pi firmware is running other than the major version number in System -> Software -> linkmeter package. Both the snapshot and v14 release say v14 though because I didn't really think things through.
 
Thanks for the info will hopefully remember for next time. What is the LEDE thing at the top?

It now says

LEDE Reboot SNAPSHOT r5264-94491a1571

Whereas previously it was r4558
 
LEDE is the name of the open source software Linux ecosystem that runs on the Pi. They changed names earlier this year to (and from a couple years ago) OpenWrt if you've ever heard of that. The rXXXX-YYYYY refers to the source revision. They release on a very slow schedule so both versions of HeaterMeter are for their release named "Reboot".
 
Got my desktop back working and had the ping going and it went without stopping for 12 hours or so so guessing this is now resolved! Thanks for the help! The weird thing is that when I got this originally a few years ago I never had any issues with dropping, and then it started last year which Is why I figured maybe a hardware issue
 
Well that's good news that it went back to working again, you should be all set for another few years then right? :-D

My 3D printer has some sort of magic in it as well. It prints fine, everything sticks to the bed properly, then one day NOTHING sticks any more like someone sprayed it with teflon spray or something. It is boggling that it happens every few months or so, but if I take it apart and clean it there's a 50/50 chance it will restore the magic. I just keep taking it apart and cleaning it until its mojo comes back and I am set for another few months.

Hopefully, the software update made a difference in your case though so we don't have to rely on magic.
 

 

Back
Top