Issue is resolved - seconds before I was going to post the message below!,
but thought it might be useful/interesting for tracking down problems with emonhub. It turns out the main emonhub froze because of some interaction with a completely separate rfm69 unit. I have 3 sensors in the wild (water tank level, rain gauge and GHI sensor) sending data through Adafruit feather rfm69 transceivers to an indoor receiver. I have this running on a separate rPi and use a python script to send the data via mqtt to the OEM “master”. It mostly works well, although I find one of the Adafruit feather units frequently stops sending and has to be reset in the field.
As a last resort, I reset the receiver for these sensors and the emonhub sprung back to life! I have no idea why the errant rfm69 tx jammed the main emon receiver, but it clearly locked it up somehow.
… … …
Noticed that some inputs stopped updating yesterday - not all, just those from a couple of emontx and emonth units. Other inputs from sensors like wifi relay/dsb1820 are still being logged. I did a reboot with no change, and full update/reboot still no emonhub activity. The emonhub log shows
2020-07-10 11:09:06,956 DEBUG RFM2Pi device settings updated: E i5 g210 @ 433 MHz
2020-07-10 11:09:07,057 DEBUG RFM2Pi acknowledged command: > 1p
2020-07-10 11:09:07,366 DEBUG RFM2Pi acknowledged command: <nn> i - set node ID (standard node ids are 1..30)
2020-07-10 11:09:07,471 DEBUG RFM2Pi acknowledged command: <n> b - set MHz band (4 = 433, 8 = 868, 9 = 915)
2020-07-10 11:09:07,578 DEBUG RFM2Pi acknowledged command: <nnnn> o - change frequency offset within the band (default 1600)
2020-07-10 11:09:07,791 DEBUG RFM2Pi acknowledged command: <nnn> g - set network group (RFM12 only allows 212, 0 = any)
2020-07-10 11:09:07,933 DEBUG RFM2Pi acknowledged command: <n> c - set collect mode (advanced, normally 0)
2020-07-10 11:09:08,140 DEBUG RFM2Pi acknowledged command: ...,<nn> a - send data packet to node <nn>, request ack
2020-07-10 11:09:08,243 DEBUG RFM2Pi acknowledged command: ...,<nn> s - send data packet to node <nn>, no ack
2020-07-10 11:09:08,346 DEBUG RFM2Pi acknowledged command: <n> q - set quiet mode (1 = don't report bad packets)
2020-07-10 11:09:08,450 DEBUG RFM2Pi acknowledged command: <n> x - set reporting format (0: decimal, 1: hex, 2: hex+ascii)
2020-07-10 11:09:08,553 DEBUG RFM2Pi acknowledged command: <nnn> y - enable signal strength trace mode, default:0 (disabled)
2020-07-10 11:09:08,657 DEBUG RFM2Pi acknowledged command: sample interval <nnn> secs/100 (0.01s-2.5s) eg 10y=0.1s
2020-07-10 11:09:08,976 DEBUG RFM2Pi acknowledged command: <hchi>,<hclo>,<addr>,<cmd> f - FS20 command (868 MHz)
2020-07-10 11:09:09,082 DEBUG RFM2Pi acknowledged command: <addr>,<dev>,<on> k - KAKU command (433 MHz)
2020-07-10 11:09:09,288 DEBUG RFM2Pi device settings updated: E i5 g210 @ 433 MHz
and on the admin page all services are active and running (except emonpiLCD which is not present)
I am wondering if the rfm69 transceiver has died?