Emonhub stopped - rfm2Pi issue?

emonHub
,
1

For some reason last night my emonPi stopped processing data from all units using rfm2pi. Other data coming via mqtt is still being processed. I tried an emonhub restart, then full emonpi reboot etc but still no receipt of data from anything connected through rfm69. The emonhub log is stationary at:


2022-03-29 09:58:08,759 DEBUG    RFM2Pi     acknowledged command: > 0q
2022-03-29 09:58:08,760 DEBUG    MainThread Setting MQTT pubchannels: ['ToRFM12']
2022-03-29 09:58:08,761 DEBUG    MainThread Setting MQTT subchannels: ['ToEmonCMS']
2022-03-29 09:58:08,761 INFO     MainThread Setting MQTT node_format_enable: 1
2022-03-29 09:58:08,761 INFO     MainThread Setting MQTT nodevar_format_enable: 1
2022-03-29 09:58:08,762 INFO     MainThread Setting MQTT nodevar_format_basetopic: emon/
2022-03-29 09:58:08,763 INFO     MainThread Creating EmonHubEmoncmsHTTPInterfacer 'emoncmsorg'
2022-03-29 09:58:08,764 DEBUG    MainThread Setting emoncmsorg subchannels: ['ToEmonCMS']
2022-03-29 09:58:08,764 INFO     MainThread Setting emoncmsorg apikey: set
2022-03-29 09:58:08,764 INFO     MainThread Setting emoncmsorg url: https://emoncms.org
2022-03-29 09:58:08,765 INFO     MainThread Setting emoncmsorg senddata: 1
2022-03-29 09:58:08,765 INFO     MainThread Setting emoncmsorg sendstatus: 1
2022-03-29 09:58:08,864 DEBUG    RFM2Pi     device settings updated: E i5 g210 @ 433 MHz
2022-03-29 09:58:08,965 DEBUG    RFM2Pi     acknowledged command: > 1p
2022-03-29 09:58:09,272 DEBUG    RFM2Pi     acknowledged command: <nn> i     - set node ID (standard node ids are 1..30)
2022-03-29 09:58:09,376 DEBUG    RFM2Pi     acknowledged command: <n> b      - set MHz band (4 = 433, 8 = 868, 9 = 915)
2022-03-29 09:58:09,481 DEBUG    RFM2Pi     acknowledged command: <nnnn> o   - change frequency offset within the band (default 1600)
2022-03-29 09:58:09,690 DEBUG    RFM2Pi     acknowledged command: <nnn> g    - set network group (RFM12 only allows 212, 0 = any)
2022-03-29 09:58:09,816 DEBUG    RFM2Pi     acknowledged command: <n> c      - set collect mode (advanced, normally 0)
2022-03-29 09:58:10,023 DEBUG    RFM2Pi     acknowledged command: ...,<nn> a - send data packet to node <nn>, request ack
2022-03-29 09:58:10,127 DEBUG    RFM2Pi     acknowledged command: ...,<nn> s - send data packet to node <nn>, no ack
2022-03-29 09:58:10,232 DEBUG    RFM2Pi     acknowledged command: <n> q      - set quiet mode (1 = don't report bad packets)
2022-03-29 09:58:10,337 DEBUG    RFM2Pi     acknowledged command: <n> x      - set reporting format (0: decimal, 1: hex, 2: hex+ascii)
2022-03-29 09:58:10,442 DEBUG    RFM2Pi     acknowledged command: <nnn> y    - enable signal strength trace mode, default:0 (disabled)
2022-03-29 09:58:10,547 DEBUG    RFM2Pi     acknowledged command: sample interval <nnn> secs/100 (0.01s-2.5s) eg 10y=0.1s
2022-03-29 09:58:10,859 DEBUG    RFM2Pi     acknowledged command: <hchi>,<hclo>,<addr>,<cmd> f     - FS20 command (868 MHz)
2022-03-29 09:58:10,963 DEBUG    RFM2Pi     acknowledged command: <addr>,<dev>,<on> k              - KAKU command (433 MHz)
2022-03-29 09:58:11,167 DEBUG    RFM2Pi     device settings updated: E i5 g210 @ 433 MHz

System details are:

EMONCMS
Version
low-write 11.0.5
Git
URL
https://github.com/emoncms/emoncms.git
Branch
* stable
Describe
11.0.5
Components
Emoncms Core v11.0.5 | App v2.5.1 | EmonHub Config v2.1.1 | Dashboard v2.2.3 | Device v2.1.7 | Graph v2.1.6 | Network Setup v1.0.2 | WiFi v2.1.1 | Backup v2.3.2 | DemandShaper v2.2.2 | Postprocess v2.2.4 | Sync v2.1.3 | Usefulscripts v2.3.9 | EmonScripts v1.3.8 | RFM2Pi v1.4.1 | Emonhub v2.3.2 | EmonPi v2.9.5

Is there a way to test if the rfm69 unit is faulty?

2

The RFM69 is on the “emon” board - that does NOT reboot when you reboot the Raspberry Pi. I suggest a controlled shutdown followed by a power-down, which will reboot the Atmel 328P that controls the RFM69CW. This is a long shot, because it does appear to be responding to the commands sent by the Pi.

3

Thanks - I did a shutdown, removed power and then restart but no change. I did notice the LED on the RFM69 board did light briefly on repower, which I think is normal. Maybe time to order a new RFM module?

4

Can you clarify - do you have an emonPi or an emonBase? You’re talking about an RFM2Pi (for an emonBase) AND an emonPi, and they are different things.

If you mean RFM12Pi or RFM69Pi module, Possibly, they are known to fail - particularly the “black blob” RFM12B type, as I understand. (Like the fourth one down here: Learn→Electricity Monitoring→Networking→RFM12B & RFM69cw wireless transceiver modules)

If you have an emonPi, it’s a complete emonPi Shield that you’ll need, unless you have the equipment and expertise to remove the RFM12B/RFM69CW without damaging the main PCB.

5

Yes, sorry - I have the emonBase with the RFM69Pi 433Mhz Raspberry Pi Base Station Transceiver

6

I’ve not heard of an RFM69CW failing (except one working as a transmitter at maximum power without an antenna - which was to be expected), and I don’t know the software of the module intimately; but as the RFM69CW doesn’t actually respond when the RFM69Pi processor sends commands to it, so the RFM69Pi responding to the Pi doesn’t tell us that the RFM69CW is actually working.

As you say it’s receiving from no units (plural), it does seem likely that the RFM69CW has failed and it’s not the sensor nodes that are transmitting to it.

7

I’ve ordered a replacement, so will know one way or another in a couple of weeks…