Auto reboot WiFi on Hetermeter


 

Chris D Norton

TVWBB Member
I saw this post from Steve_M and have no idea how to implement this into the interface.

I don’t want to mess this bad boy up and wanted to know if someone can baby step me through how to get this going. Ultimately I believe this checks my WiFi and reboots the meter if no connection?


Save the script below as /mnt/mmcblk0p4/net-watchdog.sh and make sure it's executable

Add a cron job to call the script every 10 minutes.

Code:
*/10 * * * * /mnt/mmcblk0p4/net-watchdog.sh
What it does: Pings the gateway ( your wireless router ) and checks for the message "1 packets received". If that's not found, it will first attempt to restart the networking stack on the RasPi. It will then wait 2 minutes for things to stabilize and check again. If it still doesn't get a response, it will reboot the RasPi and that should get things sorted out.

Code:
#!/bin/sh

checkgw () {
ping_gw=$(netstat -nr | grep "UG" | awk '{print $2}' | xargs ping -q -w 1 -c 1 | grep "1 packets received")
result=$?
}

checkgw
if [ "$result" -ge 1 ]
then
logger -p user.alert "Restarting network"
/etc/init.d/network reload
sleep 120
checkgw
if [ "$result" -ge 1 ]
then
logger -p user.alert "Rebooting"
/sbin/reboot
fi
fi
 
Are you able to ssh into the HM? If so, then do this:

1)
Code:
cd /mnt/mmcblk0p4
2)
Code:
curl -O https://raw.githubusercontent.com/shmick/hm-configs/master/net-watchdog.sh
3)
Code:
chmod +x net-watchdog.sh

Now login to the HM web config and and go to System > Scheduled Tasks and add this line

Code:
*/10 * * * *  /mnt/mmcblk0p4/net-watchdog.sh

Click submit to save. You'll want to reboot the raspi after this and now it should run the check every 10 minutes.
 
Worked great!! Not that it’s a big deal but I notice that when my router reboots at 5:00 and the meter looses connection it reconnected the next time it scanned fir access but lost all of the data on the graph and logs. Any way to salvage the data as well?

Thanks again Steve M. Really amazing community here.
 
https://tvwbb.com/showthread.php?73475-Cook-progress-saving

You might want to take a quick look there.

Steve, et al... is /sbin/reboot appropriate in this environment, or would '/sbin/shutdown -r now' or some such be better. In the enterprise environments I work in, a reboot is distinctly different in that it's an immediate act without any opportunity for any to shut down gracefully, no disk sync, etc.
 
On a real linux server, yes, a proper shutdown sequence would be the correct way to go. The heatermeter runs OpenWRT / LEDE and most of the system tools are provided via BusyBox, so /sbin/shutdown doesn't even exist.

If the data was missing after a reboot, it could be a fluke event. Under normal operating conditions, you would simply pull the power to the HM, no shutdown scripts involved, so running /sbin/reboot shouldn't be any more harmful than power cycling it.
 
Worked great!! Not that it’s a big deal but I notice that when my router reboots at 5:00 and the meter looses connection it reconnected the next time it scanned fir access but lost all of the data on the graph and logs. Any way to salvage the data as well?

Thanks again Steve M. Really amazing community here.

Did it actually reboot or did it just re-connect?

The events are saved to a logfile, ssh into the HM and run this command:

Code:
cat /mnt/mmcblk0p4/net-watchdog.log

You'll see "Rebooting" or "Restarting network" as the messages.
 
Just tested it again to see. I rebooted my router and of course lost connection to the HeaterMeter. After 15 or 20 min I logged in to the meter to see if it worked and worked perfectly like before.

Now the graph displays 8:00am or so of info and the log lost all data from 9:00pm last night as well. It shows when I turned is on last night at 9:00pm huge gap then it looks like I started it up again at 8:00am this morning.

Same look before I rebooted at 8:00am when I was checking. Instead the gap was from 9;00 last night to 5:00am this morning. Now all data from 5:00am to 8:00am is gone too. Weird.
 
I leave my HM on all the time, connection never drops, and it connects back after the wifi reboots without issue. Are you using the Edimax WiFi? I switched over to the Comfast CF-WU715N quite a while ago and it doesnt seem to suffer some of the quirkiness of the Edimax.
My thought is perhaps address the root issue rather than using a bandaid fix like this? Either your wifi is wonky or perhaps your HM is losing connection to the pi and causing this issue?

EDIT: CF-WU715N uses the RALINK 5370 chipset which has been very reliable on my HM
 
Last edited:
On a real linux server, yes, a proper shutdown sequence would be the correct way to go. The heatermeter runs OpenWRT / LEDE and most of the system tools are provided via BusyBox, so /sbin/shutdown doesn't even exist.

I really haven't spent much time with a Pi, raspbian, or the like. I do grok that I have to be careful crossing distributions, hence why I ask. And not just Linux, any Unix or Unix like OS has this sort of issue.

Something goofy is certainly going on, though, with Chris' installation.
 
Hmmm. Well I have a raspberry pi 3 with built in wifi.

I have another pi I can test and I also have a new SD card coming. The one I’m using I got on eBay a long time ago and I have a suspicion it was fake. So I ordered a freshie.

I’ll test the other pi and the sd card when it comes Wednesday.

So to be clear when your WiFi goes down and reboots the pi on the HeaterMeter should just autoconnect like my iPhone does?


If all this fails maybe a solder connection?
 
Last edited:
I recall some discussion about proper shutdown for the HM and I believe Bryan indicated it wasn't necessary, though I don't recall the exact details why. It was in context of power interruption, which is about as abrupt of a shut down you could have.
That said, I would still favor fixing the issue rather than adding a routine to monitor the wifi and reboot if dropped.
 
OK, the info about your pi version and wifi is helpful. IDK if the Pi3 uses the same wifi chipset as the zero-w? (I dont have a rPi 3 to play with). I just rebooted my wifi router and the HM with the Zero-W did not reconnect, but the HM with the rPI B and RT5370 wifi reconnected immediately. It must be something associated with the wifi driver or software on the HM I guess...
IDK if using a wifi dongle with a different chipset would fix the issue or cause more problems (since you cannot remove the built in wifi on the rPi 3). Maybe this is something Bryan can look into on the software side?
 
I did some testing here...

added an RT5730 dongle to my HMv4.2.4 with rPi zero-W, connected it to my wifi. Both wireless devices connect to my wifi simultaneously without issue and I can access the HM from either IP address.

I reset the wireless router and the RT5730 wifi reconnected immediately but the built in wifi on the zero-w did not reconnect.

So it does appear to be some issue with the onboard wifi device on these newer pi's, or a driver/software issue with this wifi chipset...

PS I installed the latest developmental snapshot release on the HM before doing the above testing.
 
Last edited:
So it sounds like you may be experiencing the same issues as me?

So maybe it’s the new hardware of these pi’s as the culprit? If so that would save me a ton of headache testing my solder job as I think I may do more harm than good. Haha

I appreciate you helping me out with this.
 
Yes, I am having the same issue as you with my rPi zero-w, the built in wifi does NOT reconnect automatically if connection is dropped. If I use a RT5730 wifi on the same rPi that one DOES reconnect automatically. So it seems to be an issue with the hardware or software associated with the onboard wifi on these rPi boards.
 
Oh that is quality. Looks like the RPi3 and Zero W will not reconnect on reboot (the driver is crapping out) but the new RPi3B+ and Edimax (snapshot firmware) do reconnect. Message on the 3/W
Code:
brcmfmac: brcmf_sdio_hostmail: unknown mailbox data content: 0x40012
brcmf_do_scan: error -52
(another repeating error message about the scan timeout)
Trying to change any parameters on the interface fail after this with "-110" which is timeout. Seems once it gets that error message the driver has gone into an error state and stops working until reboot (reload does nothing). EDIT: Looks like this may have been fixed a few months ago, but like all things Raspberry Pi, nobody has bothered trying to get the fix pushed upstream. Working on a solution.
 
Last edited:
I've tried the solution (different firmware and patch the brcmfmac driver) and the good news is that the HeaterMeter no longer gives the errors on disconnect. It reconnects to wifi, gets a new IP, and can connect out and updates heatermeter.com/devices. The bad news is that I can't connect to it.

I can see when I try to connect (by IP), arp resolution fails. If I try to ping it from my router, which has the HeaterMeter MAC cached already from doing DHCP, the ping works. On my windows machine, I can add a static arp cache entry with
Code:
netsh interface ip add neighbors "Ethernet 3" "192.168.2.44" "b8-27-eb-cf-f2-fd"
And I can then ping the HeaterMeter and also connect to the webui and everything is fine. If I delete the static ARP entry, it stops working. I tried a `/etc/init.d/network reload` on the HeaterMeter itself and it does nothing (as none of the network config has changed). Completely stopping the network and restarting it appears to fix whatever's in a weird state on the Pi but that's not very helpful. Rebooting also fixes the issue.

I'm not sure what to do next to fix this. I will not add a service that watches the wifi IP and if it changes, restarts all the networking, that's an awful hack. Linux devices change IPs all the time and continue to work so there's something unique here that needs to be fixed but I'm not sure where to even look.
 
Last edited:
I've tried the solution (different firmware and patch the brcmfmac driver) and the good news is that the HeaterMeter no longer gives the errors on disconnect. It reconnects to wifi, gets a new IP, and can connect out and updates heatermeter.com/devices. The bad news is that I can't connect to it.

I can see when I try to connect (by IP), arp resolution fails. If I try to ping it from my router, which has the HeaterMeter MAC cached already from doing DHCP, the ping works. On my windows machine, I can add a static arp cache entry with
Code:
netsh interface ip add neighbors "Ethernet 3" "192.168.2.44" "b8-27-eb-cf-f2-fd"
And I can then ping the HeaterMeter and also connect to the webui and everything is fine. If I delete the static ARP entry, it stops working. I tried a `/etc/init.d/network reload` on the HeaterMeter itself and it does nothing (as none of the network config has changed). Completely stopping the network and restarting it appears to fix whatever's in a weird state on the Pi but that's not very helpful. Rebooting also fixes the issue.

I'm not sure what to do next to fix this. I will not add a service that watches the wifi IP and if it changes, restarts all the networking, that's an awful hack. Linux devices change IPs all the time and continue to work so there's something unique here that needs to be fixed but I'm not sure where to even look.

Well I have no idea what half of that means, but I really appreciate you looking at it.

Thanks Bryan.
 

 

Back
Top