Community
OpenEnergyMonitor

Community

Emonhub suddenly died (but has revived).. or was it a clash with another rfm69?

Tags: #<Tag:0x00007f6e037d0578> #<Tag:0x00007f6e037d0488>

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?

1 Like

Glad you got it back to work @icenov