Emonhub on my EmonBase stopped working for some reason about 5am a couple of days ago

emonHub
1

Hello,
Not sure this will be a useful bug report…but the emonhub stopped working on my emonbase a few days ago and I am not sure why. After a reboot it has been working normally again. Could be my fault as I am still learning about the systems and the app and how they work together.

Just in case it’s worth checking out, here are the logs;

EmonCMS

2020-12-07 20:49:26.768|ERROR|index.php|Not Authenticated|config/getemonhublog
2020-12-07 20:49:30.198|ERROR|index.php|Not Authenticated|config/getemonhublog
2020-12-07 20:49:32.255|ERROR|index.php|Not Authenticated|config/getemonhublog
2020-12-07 20:49:33.378|ERROR|index.php|Not Authenticated|config

EmonHUB: (only the very top and bottom)

2020-12-07 02:17:20,056 DEBUG    emoncmsorg Buffer size: 3
2020-12-07 02:17:20,058 INFO     emoncmsorg sending: https://emoncms.org/input/bulk.json?apikey=E-M-O-N-C-M-S-A-P-I-K-E-Y&data=[[1607307408.501673,20,9.3,0,76.5,2.7,1,0,-41],[1607307410.0138235,21,9.200000000000001,0,73.8,2.7,1,0,-35],[1607307421.5963137,22,9.3,0,73.60000000000001,2.7,1,0,-29]]&sentat=1607307440
2020-12-07 02:17:21,763 DEBUG    emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org
2020-12-07 02:17:47,123 DEBUG    RFM2Pi     21768 NEW FRAME : OK 20 93 0 0 0 252 2 27 0 1 0 0 0 (-41)
2020-12-07 02:17:47,125 DEBUG    RFM2Pi     21768 Timestamp : 1607307467.123635
2020-12-07 02:17:47,126 DEBUG    RFM2Pi     21768 From Node : 20
2020-12-07 02:17:47,127 DEBUG    RFM2Pi     21768    Values : [9.3, 0, 76.4, 2.7, 1, 0]
2020-12-07 02:17:47,128 DEBUG    RFM2Pi     21768      RSSI : -41
2020-12-07 02:17:47,128 DEBUG    RFM2Pi     21768 Sent to channel(start)' : ToEmonCMS
2020-12-07 02:17:47,129 DEBUG    RFM2Pi     21768 Sent to channel(end)' : ToEmonCMS
2020-12-07 02:17:47,227 DEBUG    MQTT       Publishing: emon/emonth2/temperature 9.3
2020-12-07 02:17:47,228 DEBUG    MQTT       Publishing: emon/emonth2/external temperature 0
2020-12-07 02:17:47,230 DEBUG    MQTT       Publishing: emon/emonth2/humidity 76.4
2020-12-07 02:17:47,232 DEBUG    MQTT       Publishing: emon/emonth2/battery 2.7
2020-12-07 02:17:47,233 DEBUG    MQTT       Publishing: emon/emonth2/5 1
2020-12-07 02:17:47,234 DEBUG    MQTT       Publishing: emon/emonth2/6 0
2020-12-07 02:17:47,235 DEBUG    MQTT       Publishing: emon/emonth2/rssi -41
2020-12-07 02:17:47,237 INFO     MQTT       Publishing 'node' formatted msg
2020-12-07 02:17:47,237 DEBUG    MQTT       Publishing: emonhub/rx/20/values 9.3,0,76.4,2.7,1,0,-41
2020-12-07 02:17:49,753 DEBUG    RFM2Pi     21769 NEW FRAME : OK 21 92 0 0 0 225 2 27 0 1 0 0 0 (-36)
2020-12-07 02:17:49,755 DEBUG    RFM2Pi     21769 Timestamp : 1607307469.753179
2020-12-07 02:17:49,756 DEBUG    RFM2Pi     21769 From Node : 21
2020-12-07 02:17:49,756 DEBUG    RFM2Pi     21769    Values : [9.200000000000001, 0, 73.7, 2.7, 1, 0]
2020-12-07 02:17:49,757 DEBUG    RFM2Pi     21769      RSSI : -36

…

2020-12-07 17:20:22,656 DEBUG    RFM2Pi     acknowledged command: <nn> i     - set node ID (standard node ids are 1..30)
2020-12-07 17:20:22,759 DEBUG    RFM2Pi     acknowledged command: <n> b      - set MHz band (4 = 433, 8 = 868, 9 = 915)
2020-12-07 17:20:22,863 DEBUG    RFM2Pi     acknowledged command: <nnnn> o   - change frequency offset within the band (default 1600)
2020-12-07 17:20:23,069 DEBUG    RFM2Pi     acknowledged command: <nnn> g    - set network group (RFM12 only allows 212, 0 = any)
2020-12-07 17:20:23,175 DEBUG    RFM2Pi     acknowledged command: <n> c      - set collect mode (advanced, normally 0)
2020-12-07 17:20:23,385 DEBUG    RFM2Pi     acknowledged command: ...,<nn> a - send data packet to node <nn>, request ack
2020-12-07 17:20:23,489 DEBUG    RFM2Pi     acknowledged command: ...,<nn> s - send data packet to node <nn>, no ack
2020-12-07 17:20:23,595 DEBUG    RFM2Pi     acknowledged command: <n> q      - set quiet mode (1 = don't report bad packets)
2020-12-07 17:20:23,702 DEBUG    RFM2Pi     acknowledged command: <n> x      - set reporting format (0: decimal, 1: hex, 2: hex+ascii)
2020-12-07 17:20:24,017 DEBUG    RFM2Pi     acknowledged command: <hchi>,<hclo>,<addr>,<cmd> f     - FS20 command (868 MHz)
2020-12-07 17:20:24,123 DEBUG    RFM2Pi     acknowledged command: <addr>,<dev>,<on> k              - KAKU command (433 MHz)
2020-12-07 17:20:24,329 DEBUG    RFM2Pi     device settings updated: E i5 g210 @ 433 MHz q1
2

For future reference, when posting code or bash output, please put in 3 ‘backticks’ (found at the top left of the keyboard normally) on a line on their own, then the code, then 3 more backticks on a line following the code.

    ```
    code
    ```

If it is something like php you can add a language identifier that after the first 3 backticks so ```php

3

Not authenticated simply means you tried to access the admin page when not logged in.

Is the first portion of the emonhub log, before you rebooted or after?

4

Thanks. Just to check are the three backticks for log (or any output) as well as raw code?

1 Like
5

Emon Hub: I rebooted about 5pm the same day after the error (7th Dec). I don’t know what happened at 2:17am (the whole log is pretty huge!).

6

What I was getting at, is what were the last entries before you rebooted. Was there nothing after the 02:17 entry?

It’ll be a bit late now probably, but if it happens again, have a look in the syslog for any exceptions.

7

OK, thanks the help. I will keep an eye on the syslog file if it happens again. (is that /var/log/syslog, right?)

1 Like
8

just answer this myself for future reference

9

And if it’s not code you’re posting and you don’t want words highlighted, it’s text you put after the opening three backticks:

```text
Some text you don’t want highlighted.
```
will appear as

Some text you don't want highlighted.

but would otherwise come out as

Some text you don't want highlighted.
1 Like
10

Thats strange all four of my EmonTH’s signals no longer are ‘reaching’ the Emonhub basestation. This has happened twice this week.
Restarting the basestation seems to bring those EmonTH’s back to reporting. (do I have the EmonTH’s too close together??- they are stacked up in a pile maybe I will spread them out)

On the plus side happy to see that a UGreen PB166 20,000mAH powerbank can run the EmonBase station. (at 12:10 the PowerBank displays 78% charge remaining - wonder how long it will last?)

11

Each emonTH sends its data once every 58 s approx, that’s 12 bytes of payload, plus 9 bytes of overhead, so it takes a fraction over 3.4 ms to transmit. That 58 s value will vary over time, temperature and start out different for each emonTH, so the chances of two transmitting at the same time and blocking each other is remote (about 1 in 17,000 for one pair, or say 1 in 4,000 for any 2 out of the 4), for all four to do it at the same time is almost non-existent. And as far as I know, there’s no mechanism whereby two could synchronise themselves. So I think you can rule out stacking as being a cause.

I think you should be looking first towards your emonBase.

Are they not being received by emonHub, or is the data being corrupted and rejected, or is emonHub stopping, or is the data not getting through from emonHub and into emonCMS? My knowledge of the inner workings of the emonBase is not great, but these are the sorts of questions that someone who is better able to help is likely to ask.

12

Thank for the help @Robert.Wall. Happy New Year for tomorrow.

At the time I tried restarting the EmonHub but no change, so I assume an EmonHub failure is not the problem. It did ‘pick up’ the EmonTH’s only after I fully rebooted the Emonbase.

I will keep an eye on it to see if it repeats. Next step could be to flash the SD card (and then if need be the EmonTHs). It is not a big worry but I haven’t seen this behaviour from my emonPi and its EmonTH’s.

As of 15:10 the battery is down to 73% (so 3 hours was roughly 5%- upscaling that would roughly be a runtime of 60 hours [3 days] for a full battery’s charge).

13

For what it’s worth, I have put exactly the same (low-write 10.2.6) download on 2 emonPi’s and one emonHub (on a Pi 2B), and apart from a new sketch in the Atmel 328P front end of the two emonPi’s, the same software has run for months on all three. So I’m inclined to think it’s something in your configuration - or of course that particular SD card. I can’t see it being the emonTH’s - all four together? - hardly likely.

What exactly is “it” - where are you looking? The first place in the chain is the LED on the RFM69Pi module on your emonBase. Was that showing activity? A brief flash each time it receives something from one on the emonTx’s? i.e, 4 flashes irregularly spaced every minute, roughly? After that, the next accessible place is emonHub log. Set that to Debug (at the top of the config file) and you should see a message corresponding to each flash of that LED. Look at both while it’s working so that you know what to look for.

While you’re looking, just check that the RFM69Pi isn’t shorting on the rest of the GPIO connector. And check the power for an iffy connector.

14

As of 14:10 (next day) the battery was down to 30%. That means the best part of the battery (the 80 to 30% bit was consumed in 26 hours). Data was collected as normal and there seemed to be no problems during this 26 hours.

As a rough figure, 50% of a 20,000 mAh battery is 10,000 mAh. This was consumed in 26 hours so 10,000 /26 = 384mAh consumption. This feels a little bit high…but it’s only a guess.

15

Just found out that the battery headline capacity is 20,000 but it’s ‘rated’ capacity is 12,600mAh. This means that actually 50% energy draw is only 12,6000 * 50% = 6,300 mAh. Per hour over 26 hours this means a consumption of 242mAh per hour (or 242mA continuous).This isn’t low as a current draw but the emonbase however is running wifi and radio signals so this would increase consumption.