I’ve been using an Emon base for 9 months. Plugged in - out of the box and configured. A couple of days ago, it stopped receiving data. There are 3 EmonTX V3 units in the home. All nodes show inactive. The only actions I’ve taken are to reboot the emon base and the EmonTX units. No change in result. What can I do for troubleshooting?
Is there any LED activity on the emonTx’s (if not battery powered) or the RFM2Pi, I’m assuming you have a RFM69Pi not an emonPi by the term “Emon base” (the RFM2Pi LED’s are very small and very easily missed, observe in a darkened room or cup your hands around it etc).
Have you looked at emonhub.log? (try setting loglevel = DEBUG in emonhub.conf if it isn’t already set)
Assuming you are using the emonSD, you can take a quick look via the emoncms “config” page, but that only gives the last few messages.
If not using the emonSD image (ie no “config” page) or to see the full log you can use ssh to access the emonbase and view /var/log/emonhub/emonhub.log directly using a text editor like “nano” or using “less” to scroll back through the logs, alternatively you can just restart emonhub so the setup stages are logged again at the end of the log files to save scrolling/searching. Restarting emonhub is done using
sudo service emonhub restart at the commandline`
Thank you for your response and interest.
There is a red flash on the EmonTx’s at intervals of 10 seconds or so. The base shows a solid red led on the board. By the ethernet port there is a solid amber light and a flashing green light.
Here’s the log output after a reboot just now:
2016-01-17 01:37:20,938 INFO MainThread EmonHub Pre-Release Development Version (rc2.0?)
2016-01-17 01:37:20,939 INFO MainThread Opening hub...
2016-01-17 01:37:20,940 INFO MainThread Logging level set to DEBUG
2016-01-17 01:37:20,941 INFO MainThread Creating EmonHubJeeInterfacer 'RFM2Pi'
2016-01-17 01:37:20,943 DEBUG MainThread Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2016-01-17 01:37:22,949 INFO MainThread RFM2Pi device firmware version: [RF12demo.12]
2016-01-17 01:37:22,950 INFO MainThread RFM2Pi device current settings: E i5 g210 @ 433 MHz
2016-01-17 01:37:22,951 INFO MainThread Setting RFM2Pi quiet: 0 (0q)
2016-01-17 01:37:23,953 INFO MainThread Setting RFM2Pi calibration: 230V (1p)
2016-01-17 01:37:24,955 DEBUG MainThread Setting RFM2Pi subchannels: ['ToRFM12']
2016-01-17 01:37:24,956 DEBUG MainThread Interfacer: Subscribed to channel' : ToRFM12
2016-01-17 01:37:24,957 DEBUG MainThread Setting RFM2Pi pubchannels: ['ToEmonCMS']
2016-01-17 01:37:24,958 DEBUG MainThread Interfacer: Subscribed to channel' : ToRFM12
2016-01-17 01:37:24,960 DEBUG RFM2Pi acknowledged command: > 0q
2016-01-17 01:37:24,962 INFO MainThread Creating EmonHubMqttInterfacer 'MQTT'
2016-01-17 01:37:24,963 INFO MainThread MQTT Init mqtt_host=127.0.0.1 mqtt_port=1883
2016-01-17 01:37:24,968 DEBUG MainThread MQTT Subscribed to channel' : ToEmonCMS
2016-01-17 01:37:24,970 INFO MainThread Creating EmonHubEmoncmsHTTPInterfacer 'emoncmsorg'
2016-01-17 01:37:24,972 DEBUG MainThread emoncmsorg Subscribed to channel' : ToEmonCMS
2016-01-17 01:37:25,063 DEBUG RFM2Pi device settings updated: E i5 g210 @ 433 MHz
2016-01-17 01:37:25,069 INFO MQTT Connecting to MQTT Server
2016-01-17 01:37:25,075 INFO MQTT connection status: Connection successful
2016-01-17 01:37:25,076 DEBUG MQTT CONACK => Return code: 0
2016-01-17 01:37:25,165 DEBUG RFM2Pi acknowledged command: > 1p
2016-01-17 01:37:25,178 INFO MQTT on_subscribe
2016-01-17 01:37:25,473 DEBUG RFM2Pi acknowledged command: <nn> i - set node ID (standard node ids are 1..30)
2016-01-17 01:37:25,578 DEBUG RFM2Pi acknowledged command: <n> b - set MHz band (4 = 433, 8 = 868, 9 = 915)
2016-01-17 01:37:25,699 DEBUG RFM2Pi acknowledged command: <nnnn> o - change frequency offset within the band (default 1600)
2016-01-17 01:37:25,931 DEBUG RFM2Pi acknowledged command: <nnn> g - set network group (RFM12 only allows 212, 0 = any)
2016-01-17 01:37:26,036 DEBUG RFM2Pi acknowledged command: <n> c - set collect mode (advanced, normally 0)
2016-09-21 13:10:50,653 DEBUG RFM2Pi acknowledged command: ...,<nn> a - send data packet to node <nn>, request ack
2016-09-21 13:10:50,789 DEBUG RFM2Pi acknowledged command: ...,<nn> s - send data packet to node <nn>, no ack
2016-09-21 13:10:50,894 DEBUG RFM2Pi acknowledged command: <n> q - set quiet mode (1 = don't report bad packets)
2016-09-21 13:10:51,020 DEBUG RFM2Pi acknowledged command: <n> x - set reporting format (0: decimal, 1: hex, 2: hex+ascii)
2016-09-21 13:10:51,331 DEBUG RFM2Pi acknowledged command: <hchi>,<hclo>,<addr>,<cmd> f - FS20 command (868 MHz)
2016-09-21 13:10:51,435 DEBUG RFM2Pi acknowledged command: <addr>,<dev>,<on> k - KAKU command (433 MHz)
2016-09-21 13:10:51,639 DEBUG RFM2Pi device settings updated: E i5 g210 @ 433 MHz
2016-09-21 13:10:51,745 DEBUG RFM2Pi Discarding RX frame 'unreliable content'? 143 233 252 112 204 190 255 124 193 56 117 215 83 123 9 34 221 204 31 98 66 (-82)
2016-09-21 13:10:51,851 DEBUG RFM2Pi Discarding RX frame 'unreliable content'? 159 38 175 181 105 56 165 47 64 252 163 136 61 211 119 241 24 204 100 23 238 (-79)
2016-09-21 13:10:52,056 DEBUG RFM2Pi Discarding RX frame 'unreliable content'? 3 1 0 7 0 0 0 0 0 8 96 168 11 56 7 48 23 112 15 80 10 (-54)
2016-09-21 13:10:55,316 DEBUG RFM2Pi Discarding RX frame 'unreliable content'? 197 254 162 231 186 92 243 247 230 246 159 155 29 215 5 27 206 94 12 52 50 (-80)
2016-09-21 13:11:10,495 DEBUG RFM2Pi Discarding RX frame 'unreliable content'? 189 107 187 124 188 49 135 105 85 133 99 36 181 154 178 78 246 214 183 237 147 (-73)
Are you using an RFM2Pi board (RFM12Pi or RFM69Pi) attached to a Raspberry Pi or an emonPi ?
The node id you are using “node 5” suggests an emonPi, but the fact you are getting a response to the “quiet mode (q)” command and receiving “discarded” data says you are using an RFM2Pi.
The RFM2Pi boards led should flash in sync with each of the 3 emontx’s led flashes
Have you moved the emonbase? done something to the antenna or moved a device close to it that can give interference? Is the board seated correctly, check to see if the underside of the board is touching the pins below it, only the first 10 pins of the gpio should make contact via the 10way connector of the RFM2Pi.
Going by the log alone, everything looks fine, your just not receiving anything, as if all 3 emonTx’s decided to stop at once. I do not believe that to be the case and suspect the base has stopped receiving valid packets, either due to weak signal, interference or obstruction etc.
When you “rebooted” did you power cycle too?
I do not expect this to be the cause either, but emonHub rc2.0? is very old, that was when the emonPi variant of emonHub first apeared but did not yet have it’s own version numbers.
Thanks for your questions and interest.
I examined the RF board attached to the PI. RFM69Pi, and assured that it was well seated. The unit is located as it has been for months. The antenna is solidly soldered to the board. The current log has similar “unreliable content” as before.
Do you think this may be a hardware failure of the RFM69Pi? I guess before we go there I could bring one of the emonTx’s, and place it adjacent to the base to see what we see.
Thanks again for your comments and questions.
It cannot be ruled out, but these are pretty hardy little things, we do not see many, if any failures.
I agree you should try and bring at least one emonTx closer to see if that effects anything, I would also suggest using a serial terminal such as minicom to see the serial data directly, you could then try setting the board to “group 0” to see if data is being transmitted to another group id.
Is it possible you have changed the network group at some point ?
Well! I checked into things just now and see that in the hour following my response of 9/21 that the base started collecting valid data again.
Perhaps it was simply power off and power on that got it started. Earlier, I had rebooted without a power cycle. I also wonder if the RFM69Pi board had actually become unseated. It seemed to have a bit of a wiggle which could have come from someone jostling the antenna. Since I both powered it down to examine it, and I re-seated the board, it could be either (or neither).
Paul, thanks for the time you spent with me. I’ll keep a watch here. I have another emonTX to install, to monitor laundry energy. Then I’ll have a pretty complete picture of energy consumption here.
The open energy monitor equipment gives me a rather nice picture of generation and consumption: http://home.duanemcguire.com That site is driven by a separate raspberry pi, which gathers generation from my solar array, weather from weatherunderground, and consumption from the emonpi/emoncms.
Thanks for your help.