Really stupid question

Simonsse · 7 December 2021 18:57

Or maybe I should say really simple question from someone (me) who is acting below his pay grade.

For two years I have had an emonTH sat on a shelf waiting to be added to my emonPi monitoring setup. Wanting to put multiple DS18B20 probes on this stopped me until now.

I read lots of posts from happy Arduino users slightly less happy with wiring the probes up. I am the opposite - hardware no worries, but as an Arduino noob how do I get a new sketch into the processor. Have installed Arduino IDE on my Win10 laptop - seems reasonably bare bones (in a good way), compared to Platform IO which scared me off by talking about Python.

But I am stuck at the Tools | Board drop down. What kind of a board is the emonTH?

I didn’t know, so I selected Arduino Uno, and at some point pressed the Upload button (which in my head would have taken code from the emonTH back into the laptop), but I now think has compiled the bare bones example and blown away the factory emonTH image.

As a first step I would like to get back to the as delivered condition, and then crack on to the multi sensor choices - but I can’t find anywhere that tells me what to choose at Tools | Board.

All guidance warmly welcomed.

Robert.Wall · 7 December 2021 19:33

A very wise move, in my book - when I tried to use that piece of malware-as it turned out to be- it moved files and directories and screwed up my system.

It’s the same as an emonTx - everything in ‘Learn’ about the emonTx is true for the emonTH - or Arduino Uno, so you were right.

Yes, that’s what you did. UPload is loading from the machine you’re working on - in this case to the emonTH. What you need to do is get (DOWNload from the external source to your machine) the default (or the sketch you want to put into the emonTH) from wherever (the default is at https://github.com/openenergymonitor/emonth2/tree/master/firmware/src ), move or copy it into the “sketchbook” directory that the Arduino IDE uses, then compile and upload it to the emonTH. That sketch will accept many sensors - the config file (emonhub.conf) in your emonPi won’t accept more than a single external one without a small change, details are in the sketch comments (line 52 et seq.).

And, BTW, the question wasn’t stupid, you told us enough to know what the problem was. The stupid question is one that assumes we already know all the details of your set-up.

[Edit]
It’s probably worth mentioning that once the code is compiled and uploaded, you CANNOT get the original source code for the sketch back from the processor. The best you could do, and you’d need a rather more advanced programmer/debugger, is extract the low-level non-human-readable code.

Simonsse · 20 December 2021 20:33

@Robert.Wall my great apologies for taking so long to reply to your most gracious and exceedingly prompt reply to my call for help. You encouraged me greatly, and after a few more stumbles with the Arduino IDE I have gained the confidence to add to my setup and start recording Boiler Feed and Return temperatures on my Gas central heating. Thank you many times over, I am very appreciative of the time you took to write your message.

I now have this new section (within green rounded rectangle) in my emoncms dashboard

My new question is - why are there gaps in the Feed records? You can see the graphs have missing sections. Looking in closer on, for example, the Boiler Feed

You can see gaps in the recorded data, which I do not understand. This page offers a CSV download, resulting in

"Date-time string", "emonth2A:BoilerFeed"
2021-12-20 17:12:50, 59.7
2021-12-20 17:13:50, 58.0
2021-12-20 17:14:50, null
2021-12-20 17:15:50, null
2021-12-20 17:16:50, 53.3
2021-12-20 17:17:50, null
2021-12-20 17:18:50, 50.5
2021-12-20 17:19:50, 50.2
2021-12-20 17:20:50, 53.0
2021-12-20 17:21:50, 56.2
2021-12-20 17:22:50, 59.2
2021-12-20 17:23:50, 60.2
2021-12-20 17:24:50, 58.2
2021-12-20 17:25:50, null
2021-12-20 17:26:50, 54.1
2021-12-20 17:27:50, 57.1
2021-12-20 17:28:50, 54.2
2021-12-20 17:29:50, 52.3
2021-12-20 17:30:50, 54.7
2021-12-20 17:31:50, 57.7
2021-12-20 17:32:50, 60.3
2021-12-20 17:33:50, 60.0
2021-12-20 17:34:50, 57.5
2021-12-20 17:35:50, 55.2
2021-12-20 17:36:50, null
2021-12-20 17:37:50, 52.1
2021-12-20 17:38:50, 50.8
2021-12-20 17:39:50, 51.3
2021-12-20 17:40:50, null
2021-12-20 17:41:50, 54.3
2021-12-20 17:42:50, 57.6
2021-12-20 17:43:50, 60.5

Taking as an example the first 7 data points (recorded as 59.7, 58.0, null, null, 53.3, null, 50.5) , when I go and look in emonhub.log for 59.7 near 17:12:50 I see (snipping 2 extra lines either side of what I think are relevant)

[Point 1 - csv record is 17:12:50, 59.7] At 17:13:55.793 (ie 65.8 seconds later than timestamp) :-

2021-12-20 17:13:55,725 INFO     MQTT       Publishing 'node' formatted msg
2021-12-20 17:13:55,726 DEBUG    MQTT       Publishing: emonhub/rx/5/values 26.964,615.357,642.321,236.48390999999998,15.100000000000001,0,0,0,0,0,1567932
2021-12-20 17:13:55,793 DEBUG    RFM2Pi     111225 NEW FRAME : OK 23 230 0 85 2 251 1 11 1 181 1 30 0 1 0 0 0 (-71)
2021-12-20 17:13:55,795 DEBUG    RFM2Pi     111225 Timestamp : 1640020435.793473
2021-12-20 17:13:55,796 DEBUG    RFM2Pi     111225 From Node : 23
2021-12-20 17:13:55,797 DEBUG    RFM2Pi     111225    Values : [23, 59.7, 50.7, 26.700000000000003, 43.7, 3, 1]
2021-12-20 17:13:55,798 DEBUG    RFM2Pi     111225      RSSI : -71
2021-12-20 17:13:55,798 DEBUG    RFM2Pi     111225 Sent to channel(start)' : ToEmonCMS
2021-12-20 17:13:55,799 DEBUG    RFM2Pi     111225 Sent to channel(end)' : ToEmonCMS
2021-12-20 17:13:55,939 DEBUG    MQTT       Publishing: emon/emonth2A/temperature 23
2021-12-20 17:13:55,941 DEBUG    MQTT       Publishing: emon/emonth2A/exttemp0 59.7
2021-12-20 17:13:55,943 DEBUG    MQTT       Publishing: emon/emonth2A/exttemp1 50.7
2021-12-20 17:13:55,944 DEBUG    MQTT       Publishing: emon/emonth2A/exttemp2 26.700000000000003
2021-12-20 17:13:55,948 DEBUG    MQTT       Publishing: emon/emonth2A/humidity 43.7
2021-12-20 17:13:55,950 DEBUG    MQTT       Publishing: emon/emonth2A/battery 3
2021-12-20 17:13:55,953 DEBUG    MQTT       Publishing: emon/emonth2A/pulsecount 1
2021-12-20 17:13:55,955 DEBUG    MQTT       Publishing: emon/emonth2A/rssi -71
2021-12-20 17:13:55,956 INFO     MQTT       Publishing 'node' formatted msg
2021-12-20 17:13:55,957 DEBUG    MQTT       Publishing: emonhub/rx/23/values 23,59.7,50.7,26.700000000000003,43.7,3,1,-71
2021-12-20 17:14:00,530 DEBUG    RFM2Pi     111226 NEW FRAME : OK 5 41 0 117 2 158 2 210 95 151 0 0 0 0 0 0 0 0 0 0 0 188 236 23 0 (-0)
2021-12-20 17:14:00,532 DEBUG    RFM2Pi     111226 Timestamp : 1640020440.529990

My emonth is a V2, which I have named emonth2A and is at default RFID 23. The boiler feed temperature is reported on MQTT topic emon/emonth2A/exttemp0.

[Point 2 - csv record is 17:13:50, 58.0] The next Node : 23 record is at 17:14:58.204 (ie +68.2 seconds compared to the csv timestamp)

2021-12-20 17:14:55,763 INFO     MQTT       Publishing 'node' formatted msg
2021-12-20 17:14:55,764 DEBUG    MQTT       Publishing: emonhub/rx/5/values 44.298,603.8009999999999,648.0989999999999,236.48390999999998,15.100000000000001,0,0,0,0,0,1567932
2021-12-20 17:14:58,204 DEBUG    RFM2Pi     111238 NEW FRAME : OK 23 230 0 68 2 0 2 12 1 181 1 30 0 1 0 0 0 (-70)
2021-12-20 17:14:58,205 DEBUG    RFM2Pi     111238 Timestamp : 1640020498.204504
2021-12-20 17:14:58,206 DEBUG    RFM2Pi     111238 From Node : 23
2021-12-20 17:14:58,206 DEBUG    RFM2Pi     111238    Values : [23, 58, 51.2, 26.8, 43.7, 3, 1]
2021-12-20 17:14:58,206 DEBUG    RFM2Pi     111238      RSSI : -70
2021-12-20 17:14:58,207 DEBUG    RFM2Pi     111238 Sent to channel(start)' : ToEmonCMS
2021-12-20 17:14:58,207 DEBUG    RFM2Pi     111238 Sent to channel(end)' : ToEmonCMS
2021-12-20 17:14:58,380 DEBUG    MQTT       Publishing: emon/emonth2A/temperature 23
2021-12-20 17:14:58,380 DEBUG    MQTT       Publishing: emon/emonth2A/exttemp0 58
2021-12-20 17:14:58,381 DEBUG    MQTT       Publishing: emon/emonth2A/exttemp1 51.2
2021-12-20 17:14:58,382 DEBUG    MQTT       Publishing: emon/emonth2A/exttemp2 26.8
2021-12-20 17:14:58,383 DEBUG    MQTT       Publishing: emon/emonth2A/humidity 43.7
2021-12-20 17:14:58,383 DEBUG    MQTT       Publishing: emon/emonth2A/battery 3
2021-12-20 17:14:58,384 DEBUG    MQTT       Publishing: emon/emonth2A/pulsecount 1
2021-12-20 17:14:58,385 DEBUG    MQTT       Publishing: emon/emonth2A/rssi -70
2021-12-20 17:14:58,386 INFO     MQTT       Publishing 'node' formatted msg
2021-12-20 17:14:58,386 DEBUG    MQTT       Publishing: emonhub/rx/23/values 23,58,51.2,26.8,43.7,3,1,-70
2021-12-20 17:15:00,543 DEBUG    RFM2Pi     111239 NEW FRAME : OK 5 26 0 111 2 137 2 241 95 151 0 0 0 0 0 0 0 0 0 0 0 188 236 23 0 (-0)
2021-12-20 17:15:00,546 DEBUG    RFM2Pi     111239 Timestamp : 1640020500.543228

[Point 3 - csv record is 17:14:50, null] There is no Node : 23 message approximately one minute later (ie around 17:16:00), so a null record might be expected.

[Point 4 - csv record is 17:15:50, null] There is no Node : 23 message approximately one minute later (ie around 17:17:00), so a second null record might be expected.

[Point 5 - csv record is 17:16:50, 53.3] The next Node : 23 record is timestamped 12.9 seconds later at 17:17:02.915 and reports exttemp0 as 53.30000000000004.

2021-12-20 17:17:00,673 INFO     MQTT       Publishing 'node' formatted msg
2021-12-20 17:17:00,673 DEBUG    MQTT       Publishing: emonhub/rx/5/values 19.259999999999998,606.6899999999999,625.9499999999999,236.31056999999998,15.100000000000001,0,0,0,0,0,1567932
2021-12-20 17:17:02,915 DEBUG    RFM2Pi     111264 NEW FRAME : OK 23 230 0 21 2 241 1 14 1 181 1 30 0 1 0 0 0 (-69)
2021-12-20 17:17:02,918 DEBUG    RFM2Pi     111264 Timestamp : 1640020622.915614
2021-12-20 17:17:02,918 DEBUG    RFM2Pi     111264 From Node : 23
2021-12-20 17:17:02,919 DEBUG    RFM2Pi     111264    Values : [23, 53.300000000000004, 49.7, 27, 43.7, 3, 1]
2021-12-20 17:17:02,919 DEBUG    RFM2Pi     111264      RSSI : -69
2021-12-20 17:17:02,920 DEBUG    RFM2Pi     111264 Sent to channel(start)' : ToEmonCMS
2021-12-20 17:17:02,920 DEBUG    RFM2Pi     111264 Sent to channel(end)' : ToEmonCMS
2021-12-20 17:17:03,096 DEBUG    MQTT       Publishing: emon/emonth2A/temperature 23
2021-12-20 17:17:03,098 DEBUG    MQTT       Publishing: emon/emonth2A/exttemp0 53.300000000000004
2021-12-20 17:17:03,099 DEBUG    MQTT       Publishing: emon/emonth2A/exttemp1 49.7
2021-12-20 17:17:03,100 DEBUG    MQTT       Publishing: emon/emonth2A/exttemp2 27
2021-12-20 17:17:03,102 DEBUG    MQTT       Publishing: emon/emonth2A/humidity 43.7
2021-12-20 17:17:03,103 DEBUG    MQTT       Publishing: emon/emonth2A/battery 3
2021-12-20 17:17:03,104 DEBUG    MQTT       Publishing: emon/emonth2A/pulsecount 1
2021-12-20 17:17:03,105 DEBUG    MQTT       Publishing: emon/emonth2A/rssi -69
2021-12-20 17:17:03,106 INFO     MQTT       Publishing 'node' formatted msg
2021-12-20 17:17:03,107 DEBUG    MQTT       Publishing: emonhub/rx/23/values 23,53.300000000000004,49.7,27,43.7,3,1,-69
2021-12-20 17:17:05,540 DEBUG    RFM2Pi     111265 NEW FRAME : OK 5 20 0 113 2 133 2 205 95 151 0 0 0 0 0 0 0 0 0 0 0 188 236 23 0 (-0)
2021-12-20 17:17:05,543 DEBUG    RFM2Pi     111265 Timestamp : 1640020625.540560

[Point 6 - csv record is 17:17:50, null] There is no Node : 23 message approximately one minute later (ie around 17:19:00), so a second null record might be expected.

[Point 7 - csv record is 17:18:50, 50.5] The next Node : 23 record is timestamped 17.9 seconds later at 17:19:07.915 and reports exttemp0 as 50.5.

2021-12-20 17:19:05,650 INFO     MQTT       Publishing 'node' formatted msg
2021-12-20 17:19:05,651 DEBUG    MQTT       Publishing: emonhub/rx/5/values 16.371,605.727,622.098,236.36835,15.100000000000001,0,0,0,0,0,1567933
2021-12-20 17:19:07,635 DEBUG    RFM2Pi     111290 NEW FRAME : OK 23 230 0 249 1 224 1 12 1 178 1 30 0 1 0 0 0 (-70)
2021-12-20 17:19:07,637 DEBUG    RFM2Pi     111290 Timestamp : 1640020747.635361
2021-12-20 17:19:07,638 DEBUG    RFM2Pi     111290 From Node : 23
2021-12-20 17:19:07,639 DEBUG    RFM2Pi     111290    Values : [23, 50.5, 48, 26.8, 43.400000000000006, 3, 1]
2021-12-20 17:19:07,639 DEBUG    RFM2Pi     111290      RSSI : -70
2021-12-20 17:19:07,640 DEBUG    RFM2Pi     111290 Sent to channel(start)' : ToEmonCMS
2021-12-20 17:19:07,640 DEBUG    RFM2Pi     111290 Sent to channel(end)' : ToEmonCMS
2021-12-20 17:19:07,774 DEBUG    MQTT       Publishing: emon/emonth2A/temperature 23
2021-12-20 17:19:07,775 DEBUG    MQTT       Publishing: emon/emonth2A/exttemp0 50.5
2021-12-20 17:19:07,776 DEBUG    MQTT       Publishing: emon/emonth2A/exttemp1 48
2021-12-20 17:19:07,777 DEBUG    MQTT       Publishing: emon/emonth2A/exttemp2 26.8
2021-12-20 17:19:07,778 DEBUG    MQTT       Publishing: emon/emonth2A/humidity 43.400000000000006
2021-12-20 17:19:07,779 DEBUG    MQTT       Publishing: emon/emonth2A/battery 3
2021-12-20 17:19:07,780 DEBUG    MQTT       Publishing: emon/emonth2A/pulsecount 1
2021-12-20 17:19:07,781 DEBUG    MQTT       Publishing: emon/emonth2A/rssi -70
2021-12-20 17:19:07,782 INFO     MQTT       Publishing 'node' formatted msg
2021-12-20 17:19:07,783 DEBUG    MQTT       Publishing: emonhub/rx/23/values 23,50.5,48,26.8,43.400000000000006,3,1,-70
2021-12-20 17:19:10,568 DEBUG    RFM2Pi     111291 NEW FRAME : OK 5 38 0 108 2 146 2 129 95 152 0 0 0 0 0 0 0 0 0 0 0 189 236 23 0 (-0)
2021-12-20 17:19:10,571 DEBUG    RFM2Pi     111291 Timestamp : 1640020750.568060

So it looks like I am genuinely missing RF packets from emonth2A.

There looks to be a sequence ID for RFM2Pi packets, and the logged packets have the following IDs 111225
111238
111264
111290
The increments between are 13, 26 & 26.

The logged timestamps are
17:13:55.793 (1640020435.793s)
17:14:58.204 (1640020498.204s)
17:17:02.915 (1640020622.915s)
17:19:07.635 (1640020747.635s)
The increments between are 62.411s, 124.711s & 124.720s.

In between the emonth2A packets there appear to be around 12 packets per minute from Node : 5, the emonpi, eg packet IDs 11291 & 11292

2021-12-20 17:19:07,782 INFO     MQTT       Publishing 'node' formatted msg
2021-12-20 17:19:07,783 DEBUG    MQTT       Publishing: emonhub/rx/23/values 23,50.5,48,26.8,43.400000000000006,3,1,-70
2021-12-20 17:19:10,568 DEBUG    RFM2Pi     111291 NEW FRAME : OK 5 38 0 108 2 146 2 129 95 152 0 0 0 0 0 0 0 0 0 0 0 189 236 23 0 (-0)
2021-12-20 17:19:10,571 DEBUG    RFM2Pi     111291 Timestamp : 1640020750.568060
2021-12-20 17:19:10,571 DEBUG    RFM2Pi     111291 From Node : 5
2021-12-20 17:19:10,572 DEBUG    RFM2Pi     111291    Values : [36.594, 597.06, 633.654, 235.44387, 15.200000000000001, 0, 0, 0, 0, 0, 1567933]
2021-12-20 17:19:10,573 DEBUG    RFM2Pi     111291 Sent to channel(start)' : ToEmonCMS
2021-12-20 17:19:10,573 DEBUG    RFM2Pi     111291 Sent to channel(end)' : ToEmonCMS
2021-12-20 17:19:10,600 DEBUG    MQTT       Publishing: emon/emonpi/power1 36.594
2021-12-20 17:19:10,602 DEBUG    MQTT       Publishing: emon/emonpi/power2 597.06
2021-12-20 17:19:10,604 DEBUG    MQTT       Publishing: emon/emonpi/power1pluspower2 633.654
2021-12-20 17:19:10,605 DEBUG    MQTT       Publishing: emon/emonpi/vrms 235.44387
2021-12-20 17:19:10,607 DEBUG    MQTT       Publishing: emon/emonpi/t1 15.200000000000001
2021-12-20 17:19:10,608 DEBUG    MQTT       Publishing: emon/emonpi/t2 0
2021-12-20 17:19:10,610 DEBUG    MQTT       Publishing: emon/emonpi/t3 0
2021-12-20 17:19:10,611 DEBUG    MQTT       Publishing: emon/emonpi/t4 0
2021-12-20 17:19:10,613 DEBUG    MQTT       Publishing: emon/emonpi/t5 0
2021-12-20 17:19:10,614 DEBUG    MQTT       Publishing: emon/emonpi/t6 0
2021-12-20 17:19:10,616 DEBUG    MQTT       Publishing: emon/emonpi/pulsecount 1567933
2021-12-20 17:19:10,617 INFO     MQTT       Publishing 'node' formatted msg
2021-12-20 17:19:10,618 DEBUG    MQTT       Publishing: emonhub/rx/5/values 36.594,597.06,633.654,235.44387,15.200000000000001,0,0,0,0,0,1567933
2021-12-20 17:19:15,602 DEBUG    RFM2Pi     111292 NEW FRAME : OK 5 41 0 103 2 144 2 140 95 151 0 0 0 0 0 0 0 0 0 0 0 189 236 23 0 (-0)
2021-12-20 17:19:15,605 DEBUG    RFM2Pi     111292 Timestamp : 1640020755.602012
2021-12-20 17:19:15,605 DEBUG    RFM2Pi     111292 From Node : 5
2021-12-20 17:19:15,606 DEBUG    RFM2Pi     111292    Values : [39.483, 592.245, 631.728, 235.5498, 15.100000000000001, 0, 0, 0, 0, 0, 1567933]
2021-12-20 17:19:15,606 DEBUG    RFM2Pi     111292 Sent to channel(start)' : ToEmonCMS
2021-12-20 17:19:15,607 DEBUG    RFM2Pi     111292 Sent to channel(end)' : ToEmonCMS
2021-12-20 17:19:15,769 DEBUG    MQTT       Publishing: emon/emonpi/power1 39.483
2021-12-20 17:19:15,770 DEBUG    MQTT       Publishing: emon/emonpi/power2 592.245
2021-12-20 17:19:15,772 DEBUG    MQTT       Publishing: emon/emonpi/power1pluspower2 631.728
2021-12-20 17:19:15,773 DEBUG    MQTT       Publishing: emon/emonpi/vrms 235.5498
2021-12-20 17:19:15,774 DEBUG    MQTT       Publishing: emon/emonpi/t1 15.100000000000001
2021-12-20 17:19:15,775 DEBUG    MQTT       Publishing: emon/emonpi/t2 0
2021-12-20 17:19:15,776 DEBUG    MQTT       Publishing: emon/emonpi/t3 0
2021-12-20 17:19:15,777 DEBUG    MQTT       Publishing: emon/emonpi/t4 0
2021-12-20 17:19:15,778 DEBUG    MQTT       Publishing: emon/emonpi/t5 0
2021-12-20 17:19:15,779 DEBUG    MQTT       Publishing: emon/emonpi/t6 0
2021-12-20 17:19:15,780 DEBUG    MQTT       Publishing: emon/emonpi/pulsecount 1567933
2021-12-20 17:19:15,783 INFO     MQTT       Publishing 'node' formatted msg
2021-12-20 17:19:15,783 DEBUG    MQTT       Publishing: emonhub/rx/5/values 39.483,592.245,631.728,235.5498,15.100000000000001,0,0,0,0,0,1567933
2021-12-20 17:19:19,719 DEBUG    emoncmsorg Buffer size: 7
2021-12-20 17:19:20,557 DEBUG    RFM2Pi     111293 NEW FRAME : OK 5 40 0 100 2 140 2 179 95 151 0 0 0 0 0 0 0 0 0 0 0 189 236 23 0 (-0)
2021-12-20 17:19:20,559 DEBUG    RFM2Pi     111293 Timestamp : 1640020760.556909

I don’t understand why these are RFM2Pi messages - surely the internal Arduino doesn’t talk wirelessly to the host Raspberry Pi when there’s connectivity available to wire up UART to UART?

And the emonth seems to be on too long a timebase, sending out messages just over a minute apart, rather than just under. Where in the sketch should I look to tweak that? Presumably using more sensors (3 external DS18B20’s plus the Si7031 is pushing some critical timing over a tipping point.

I think I need to look at these

// These variables control the transmit timing of the emonTH
const unsigned long WDT_PERIOD = 80;                                   // mseconds.
const unsigned long WDT_MAX_NUMBER = 690;                              // Data sent after WDT_MAX_NUMBER periods of WDT_PERIOD ms without pulses:
                                                                       // 690x 80 = 55.2 seconds (it needs to be about 5s less than the record interval in emoncms)

If I get 62s between records with my hardware config and 690 periods of 80ms, can I just set WDT_MAX_NUMBER to 55 / 62 * 690 = 612 ? What else might I break?

Phew - much learning already under my belt, and more to go. Having more fun now than I was

[Side Notes: My 1890’s solid brick suburban semi enjoys the benefit of a floor standing low tech cast iron lump of a boiler complete with 24/7/365 pilot light, but no go-wrong-after-5-year electronics.

I enjoy reading tales of low flow temperatures in condensing boilers, but do not aspire to being forced into owning such a life-limited device. 10, maybe 15, years seems to be a normal lifespan, compared to the unit here, which was I guess already at least that old when we moved in 25 years ago - and has largely been untouched since.

I have toyed with ASHP, but don’t fancy the upheaval of replacing many radiators, nor the difficulty of siting a filing cabinet sized external unit in a noise-suitable Permitted Development location.

Also the current potential for disastrous electricity prices that increase by multiples of the underlying gas price increase has rather put that idea out of my head for the time being.]

Robert.Wall · 20 December 2021 21:41

You’re right on the money there. emonCMS records the data into a “slot” that is open for the set interval. If no data arrives while the slot is open, it records a NULL value. If two items arrive, only the last is stored.

You need to reduce the gap between transmissions of the emonTH. Unlike emonLibCM, the emonTH sleeps for the gap between transmissions, rather than starting each transmission at a set interval.

That sounds about right - but while you can calculate the time each transmission takes, the time for each sensor to respond can be variable. That’s why we aim significantly under the 60 s interval. I don’t think it will break anything.

It’s because the “emon” part and the radio receiver are both part of the emonPi “shield” - all data is handled by the Atmel '328P and sent by serial connection into the Pi.

Simonsse · 30 December 2021 16:06

Thanks again @Robert.Wall I am making halting progress.

I shrank the sampling interval by changing WDT_MAX_NUMBER to 612, and now see an emonTH2A sampling interval of around 55.4s, as measured by emonhub.log timestamps.

Fewer missing temperature samples, but not zero. Delving into community history, missing data seems to have been experienced in the past - e.g. https://community.openenergymonitor.org/t/problem-with-missing-data-on-graph-second-post/5677 or https://community.openenergymonitor.org/t/data-dropouts/14741.

Looking carefully at timestamps on the emonhub.log entries, I wonder if the emonPi “shield” is masking Node : 23 traffic when Node : 5 traffic is already active - some of the missing emonTH packets look like they would would have occurred during the 12 times more frequent emonPi packets. The Arduino looks to have limited capability, and if (say) it could not respond to the 55.4s interval Node:23 radio receiver interrupt whilst sending a 5s interval Node:5 data packet that would explain a good part of my observed situation. Has this been discussed before?

It also crosses my mind that I have a Honeywell wireless intruder alarm in the house, whose sensors may also be transmitting in the 433MHz band at similar order of minute intervals. The alarm and the emonTH could well be tripping over each other - I do occasionally (ca. once every few months) have an RF Error on the alarm that requires me to wait for a minute or two before I can do a Full Set.

Or indeed anybody with a remote locking car key could be blitzing an emonTH packet.

At this point I’m not looking to bring SDR into my home automation, so I’ll leave a few pounds in my pocket until that undoubtedly fascinating topic comes up again.

I do have some other questions though, which I’ll post as topics of their own.

Robert.Wall · 30 December 2021 16:55

I suspect the blame doesn’t lie entirely at the Arduino’s door, but also with the RFM12B. That has a 1-character message buffer, meaning that data in and out has to be handled as it arrives. The RFM69CW that we use now does have a sensible buffer, but while our own library can use that when transmitting (as in the emonTx), it’s not possible to use it receiving (as in the emonPi). So if a radio message comes in while the processor is handling something else and the interrupt from the radio isn’t acted on sufficiently quickly, the checksum fails and the message gets thrown out.

Of course, you’ve actually exacerbated the problem by making the message longer. You could slow the emonPi’s reporting rate - I think the intention at some point is to slow it to a nominal 10 s rate (probably 9.8 s or something like that).

This too is a likely problem. If you knew your alarm’s exact frequency, it should be possible to move the emonTH and emonPi’s frequencies to a different place within the band.