All of my feeds that are wireless to my emonbase have stopped working - two emontx and three emonth.
Feeds sent over TCP via MQTT are working fine.
I’ve rebooted the emonbase but nothing has resolved itself.
The emonhub log doesn’t show received packets in debug mode which it would normally do.
Any ideas what to troubleshoot?
Hub log shows …
2020-08-10 15:32:40,569 INFO MainThread EmonHub emonHub (emon-pi variant) v2.1.5
2020-08-10 15:32:40,569 INFO MainThread Opening hub...
2020-08-10 15:32:40,570 INFO MainThread Logging level set to DEBUG
2020-08-10 15:32:40,570 INFO MainThread Creating EmonHubJeeInterfacer 'RFM2Pi'
2020-08-10 15:32:40,573 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2020-08-10 15:32:42,576 WARNING MainThread Device communication error - check settings
2020-08-10 15:32:42,577 INFO MainThread Setting RFM2Pi baseid: 5 (5i)
2020-08-10 15:32:43,579 INFO MainThread Setting RFM2Pi frequency: 433 (4b)
2020-08-10 15:32:44,581 INFO MainThread Setting RFM2Pi group: 210 (210g)
2020-08-10 15:32:45,584 INFO MainThread Setting RFM2Pi quiet: 1 (1q)
2020-08-10 15:32:46,586 INFO MainThread Setting RFM2Pi calibration: 230V (1p)
2020-08-10 15:32:47,588 DEBUG MainThread Setting RFM2Pi pubchannels: ['ToEmonCMS']
2020-08-10 15:32:47,589 DEBUG MainThread Setting RFM2Pi subchannels: ['ToRFM12']
2020-08-10 15:32:47,591 INFO MainThread Creating EmonHubMqttInterfacer 'MQTT'
2020-08-10 15:32:47,594 DEBUG MainThread Setting MQTT pubchannels: ['ToRFM12']
2020-08-10 15:32:47,595 DEBUG MainThread Setting MQTT subchannels: ['ToEmonCMS']
2020-08-10 15:32:47,596 INFO MainThread Setting MQTT node_format_enable: 1
2020-08-10 15:32:47,596 INFO MainThread Setting MQTT nodevar_format_enable: 1
2020-08-10 15:32:47,597 INFO MainThread Setting MQTT nodevar_format_basetopic: emon/
2020-08-10 15:32:47,598 INFO MainThread Creating EmonHubEmoncmsHTTPInterfacer 'emoncmsorg'
2020-08-10 15:32:47,600 DEBUG MainThread Setting emoncmsorg pubchannels: ['ToRFM12']
2020-08-10 15:32:47,601 DEBUG MainThread Setting emoncmsorg subchannels: ['ToEmonCMS']
2020-08-10 15:32:47,601 INFO MainThread Setting emoncmsorg apikey: set
2020-08-10 15:32:47,602 INFO MainThread Setting emoncmsorg url: https://emoncms.org
2020-08-10 15:32:47,602 INFO MainThread Setting emoncmsorg senddata: 1
2020-08-10 15:32:47,603 INFO MainThread Setting emoncmsorg sendstatus: 1
Edit - formatted text. BT - Moderator
emonHub is complaining about a data comm error.
Changing the comm port data rate to 9600 bps should fix it.
Ref: RFM12B with emonTH - no input appearing in emoncms
What has changed? Did you run an update?
There was a power cut earlier today.
Unless it is the older card (which I don’t think it is) that is not necessary.
If that is the only change between a working system and a defunct system I suspect failed hardware.
Is the emonBase connected via a surge protector?
I thought about that too. This made it look like the old card::
15:32:47,589 DEBUG MainThread Setting RFM2Pi subchannels: ['ToRFM12']
My notes say 9600, 38400 & 57600 have all been used at some point, so it’s worth trying each in turn.
You haven’t had the radio module off the RPi and put it back on the wrong pins? It should be right up to the end nearest the corner of the board, and not drooping so that it touches any of the other GPIO pins further along.
Is the SD card in a tangle because of that?
@Bill.Thomson @Robert.Wall as the only change to a working system was the power cut, the baud rate is irrelevant.
Not necessarily. I recall Robert mentioning (fairly recently) doorbells that had some of their stored parameters change bacause of a power hit.
Commercial power failures can, and often do, produce large voltage spikes that can cause some
pretty wild/weird stuff to happen. From altering memory contents to complete destruction of the
device and many things between those extremes.
I’m not saying this is what happened, but 45+ years of ET experience says it can’t be ruled
out completely. 
This isn’t a stored parameter. It is in a text file. A power spike editing a text file to change a specific parameter to a different, but potentially valid parameter, is impossible (and I don’t say that lightly).
I wasn’t referring to the file but rather the hardware.
So you are suggesting the firmware on the RFM Card has been corrupted? If so, how could changing the parameter at the other end, possibly help in resolving the issue?
Not necessarily corrupted, (although that’s a possibility) but changed.
Something has changed. Otherwise emonHub wouldn’t be flagging an error.
I’m not suggesting otherwise. But to offer changing the text file baud rate as a solution is nonsensical. if an update had been done, then yes there is a potential mismatch when older hardware is involved.
I read the thread, and that isn’t made clear. @greentangerine said there had been a power cut, he did not confirm that there had not been an update.
After 50+ years in electrical engineering, I’ve learned never to discount anything until it’s proven beyond doubt.
Well it’s all now working again but I’m not sure what the exact solution was. I shutdown the emonbase over a remote command line and then retrieved it from near the consumer unit some time later. Took the lid off and made sure the wireless unit was mounted firmly on the gpio pins (which it seemed to be). Took out and reinserted the SD card, took it back to the CU, plugged it in and by the time I got back to my desk the feeds had started up again.
Thanks for all the suggestions.
I’m now going to take an image of the SD card in the next day or two so it it stops working again I can get a new emonbase and perhaps a fresh card to work with and hopefully minimum downtime.
I should probably get a surge protected extension too.
That’s half-good to know. Those faults are the ones I really, really hate.
I’d surmise that either something somewhere got corrupted, and survived all previous attempts to restart, or by pure coincidence a bad contact had made its presence known at the wrong time. Nasty either way.
The backup module is pretty good in terms of restoring from the data it exports. Imaging the SD card can mean you carry issues across. Better to start with a new image and a backup file.