EmonTH 2 with 3 external probes, nothing received

Tommy_Monk · 9 August 2023 19:28

I purchased two emonth2 and a bunch of DS18B20, I got the tranceiver to plug into a pi.

I set the first one up with it’s default firmware, node 23 and 1 external sensor, it’s working great and all reading are registered in emoncms.

The second one is destined for my heat pump and I have soldered together three sensors and attached them, I set the dip switches to node 24

I first tried building the multiple_ds18b20_external branch, set EXTERNAL_TEMP_SENSORS to 3 and flashed it using the usb programmer.

With this firmware, when monitoring the serial output I see all temperatures but no matter what emonhub config I try, no messages are received.
I then tied the master branch firmware, when monitoring it’s output I see “DS18B20 found = 0 of 3”, it’s messages also are not received in emonhub

Any ideas what I’m doing wrong ?

Robert.Wall · 9 August 2023 23:36

Welcome, Tommy, to the OEM forum.

I can’t immediately see what your problem might be. I can’t trace the exact same version of the sketches you’re using (probably because Github is an unfathomable tangle to me), so I need a direct link or sight of the sketches themselves if you’ve changed anything.

The way emonHub works is the Node specification must either be generic, or it must match exactly the format of the data coming from the sketch, in terms of the byte count if it’s not to be rejected outright, and the data types if it’s to be interpreted correctly.
The reference documentation is here: emonHub Configuration File — OpenEnergyMonitor 0.0.1 documentation

Tommy_Monk · 10 August 2023 08:58

Hi @Robert.Wall

Thanks for the warm welcome!

I’m a software engineer so have a good understanding of GitHub, but I’m struggling with some of the nomenclature.

I’ve seen this word ‘sketches’ mentioned throughout posts in the community but hadn’t been able to pin down their exact definition.
I think you’re referring to the firmware used by the sending and receiving devices, if correct that means you’re asking me which tag/release/commit I’m working with ?

I’ve tried flashing the following from the emonth2 repo, each time with the same result, my emonpi (a raspberry pi with RFM69SPI 433Mhz Transceiver running emonSD-10Nov22 fully updated to 11.3.22) does not receive the messages.

Release/tag 4.1.3 on master (commit e836d42bd4eac74fb98b36637aa6992f8c338fd5)
The latest commit on the multiple_ds18b20_external branch (commit bc9ee1d29895478f3ce4df1fa4318451e1be58c0)

It is my understanding that by default the emonth2 firmware is configured for a single external sensor so whichever tag I choose, I’ll need to set EXTERNAL_TEMP_SENSORS 3. I’m unsure if that’s the only change I need to make.
Maybe there is a source of ‘generic’ firmware for the emonth2 supporting multiple 3 external sensors I’m just not aware of ?

It looks to me that the config I added should be matching the same number of fields and data types being sent by the code I’ve been flashing

    [[24]]
        nodename = emonth2_24
        [[[rx]]]
            names = temperature, external_temp_0, external_temp_1, external_temp_2, humidity, battery, pulsecount
            datacodes = h, h, h, h, h, h, L
            scales = 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 1.0
            units = C, C, C, C, %, V, p

I was also second guessing whether I was using the correct radio type for the pi as I don’t know which of the three radio types my working (node 23) emonth2 is using.

It looks that by default the emonth2 firmware is using RFM69_LOW_POWER_LABS which I assume will be compatible with my emonpi ?

Robert.Wall · 10 August 2023 11:12

“Sketch” is Arduino-speak for the user’s code, compiled in the IDE, uploaded into the processor’s flash memory, and invoked by the bootloader at power-up, watchdog reset etc. It comprises just two main functions, setup() invoked first and run once only, and loop() invoked next and repeated forever. Both take no parameters and return nothing.
The absolute simplest useful Arduino sketch is “blink”:

void setup() {
  // initialize digital pin 6 as an output.
  pinMode(6, OUTPUT);
}

// the loop function runs over and over again forever
void loop() {
  digitalWrite(6, HIGH);         // turn the LED on (HIGH is the voltage level)
  delay(1000);                       // wait for a second
  digitalWrite(6, LOW);         // turn the LED off by making the voltage LOW
  delay(1000);                       // wait for a second
}

(Won’t work on an emonTH - the LED pin is wrong, it’s 9 for all emonTHs.)

Now that’s totally meaningless to me.

If you’re going to bandy that around, I can’t help you. You need to attach or paste the sketch into a post here, or provide a complete URL to the code file itself.

Unless you’ve updated your emonPi with the LPL option, no it won’t be. The format of the radio transmission itself is different between LPL and JeeLabs, so unless both ends are using the same, it won’t work.

Tommy_Monk · 10 August 2023 12:04

Here is the sketch I modified from the multiple_ds18b20_external branch.

src.ino (20.8 KB)

Robert.Wall · 10 August 2023 14:59

This sketch is using JeeLib, hence the JeeLabs transmission characteristics (bit rate, bandwidth etc) and with the preprocessor substitution #define EXTERNAL_TEMP_SENSORS 3 the message structure is

    [[23]]
      nodename = emonTH_5
      firmware = V2.x_emonTH_DHT22_DS18B20_RFM69CW_Pulse
      hardware = emonTH_(Node_ID_Switch_DIP1:OFF_DIP2:OFF)
      [[[rx]]]
         names = temperature, external temperature1, external temperature2, external temperature3, humidity, battery, pulseCount
         datacodes = h,h,h,h,h,h,L
         scales = 0.1,0.1,0.1,0.1,0.1,0.1,1
         units = C,C,C,C,%,V,p

which looks identical in structure to the Node definition you have.

So what I’d question now is what is your emonPi set up to receive, JeeLabs or LPL library r.f. transmission standard?

Now I’m not sure what your Node 23 is using. If your emonPi is receiving that one and not Node 24, it suggests Node 23 and the emonPi are using LPL, while Node 24 is now back to using JeeLabs.

As LPL will be used going forwards, I’d suggest getting the “latest” emonTH2 sketch: https://github.com/openenergymonitor/emonth2/blob/master/firmware/emonth2.ino and setting it up as

#define RadioFormat RFM69_LOW_POWER_LABS
#define EXTERNAL_TEMP_SENSORS 3

and I think this should get you going using the Node definition you have in emonHub.
I’d advise starting with the serial output on and monitoring it to make sure it looks OK at this stage. (i.e. it reports “RadioFormat: LowPowerLabs”, the correct frequency (433 MHz), number of sensors starting up, etc

[I refuse to use platformio because it moved files around without asking and screwed up my system. So I can’t help you if you use that. I recommend staying with the Arduino IDE, despite its many faults.]

Tommy_Monk · 10 August 2023 16:14

Thanks for this, looking at the emonhub logs I see a clue that it might be using LPL

I just flashed the https://github.com/openenergymonitor/emonth2/blob/master/firmware/emonth2.ino sketch with the two changes you advised and this is what I see when monitoring it by serial.

Here is the file for transparency
emonth2.ino (25.5 KB)

It seems to be indicating the it’s using the LPL radio but says DS18B20 found = 0 of 4

I have no idea why it doesn’t seem to be detecting the sensors when the other sketch I posted the picture of earlier seems to output the three ext readings (albeit using the wrong radio) ?

Robert.Wall · 10 August 2023 18:33

I think this is because the addresses are not (yet) saved in EEPROM. That comes from the “emonth2_config.ino” file. After this is read and no sensor addresses are found, only then is a search done for the sensors. So if a sensor has gone missing, those remaining won’t be reallocated to new slots.

If you uncomment if (numSensors) etc, the sensors should have been found by then.

[One of the quirks of the Arduino IDE is the files constituting a sketch are and must be all in the same directory. In this case, your sketch is in two files: emonth2.ino and emonth2_config.ino]

Tommy_Monk · 10 August 2023 18:43

Yes you are correct, after uncommenting that I see this;

From adding debug log lines I can see that it is sending RF data but I’m guessing it’s structure isn’t matching what I have in emonhub.

I need to try working out how data sent by radio.send(5, (const void*)(&emonth), sizeof(emonth)); looks on the wire

Robert.Wall · 10 August 2023 18:52

It’s a byte stream. It’s emonHub that counts bytes and allocates them to the variables according to type, size and signed/unsigned.
struct { ... } payload sets it up in the first place.

(Dunno why it’s typedef’d when there’s only ever one instance.)

But this isn’t necessarily the fault. If the r.f. parameters are wrong, nothing will come out of the receiving RFM69CW.

It’s worth trying each of
#define RadioFormat RFM69_LOW_POWER_LABS
#define RadioFormat RFM69_JEELIB_CLASSIC
#define RadioFormat RFM69_JEELIB_NATIVE
in turn, which might give an indication of what your emonPi is receiving.

Tommy_Monk · 10 August 2023 19:00

Thanks, I’m feeling quite stupid that I’ve only just noticed something in the logs that I totally overlooked last time trying this master branch code.

Any idea why the number of fields isn’t matching my expection ?

Robert.Wall · 10 August 2023 19:07

In your sketch, Node 23 is defined as 12 bytes: h,h,h,h,L (4×2 + 4)

In the struct with EXTERNAL_TEMP_SENSORS 3, it’s sending
int temp;
int temp_external[EXTERNAL_TEMP_SENSORS];
int humidity;
int battery;
unsigned long pulsecount;

= 2 + 3×2 + 2 + 2 + 4 = 16
which is what you’re seeing. So you need to make your emonHub entry for Node 24 match what’s being sent: h,h,h,h,h,h,L and all the other lines to match.

Tommy_Monk · 10 August 2023 19:27

I’m still getting it wrong somehow, this is my config now

[nodes]
    [[23]]
        nodename = emonth2_23
        [[[rx]]]
            names = temperature, external temperature, humidity, battery, pulsecount
            datacodes = h, h, h, h, L
            scales = 0.1, 0.1, 0.1, 0.1, 1.0
            units = C, C, %, V, p

    [[24]]
        nodename = emonth2_24
        [[[rx]]]
            names = temperature, external_temp_0, external_temp_1, external_temp_2, humidity, battery, pulsecount
            datacodes = h, h, h, h, h, h, L
            scales = 0.1, 0.1, 0.1, 0.1, 0.1, 0.1, 1.0
            units = C, C, C, C, %, V, p

But I’m still seeing this in the hub logs even after reboot.

Robert.Wall · 10 August 2023 19:34

You mean restart emonHub.

Have you got two "Node 24"s defined in the file?

Are you even looking at the right log entry? I can only see those few lines, not what precedes and follows.

Tommy_Monk · 10 August 2023 19:38

I tried restarting the hub and then altogether rebooting the pi.

Here is the entire config, I redacted my API key, I don’t see any duplicate

config.txt (4.2 KB)

Here is a larger chunk of the log

2023-08-10 20:35:48,909 INFO     SPI        Packet received 12 bytes
2023-08-10 20:35:48,910 DEBUG    SPI        7 NEW FRAME : 
2023-08-10 20:35:48,912 DEBUG    SPI        7 Timestamp : 1691696148.910601
2023-08-10 20:35:48,914 DEBUG    SPI        7 From Node : 23
2023-08-10 20:35:48,914 DEBUG    SPI        7    Values : [24.3, 23.200000000000003, 62.2, 3, 0]
2023-08-10 20:35:48,916 DEBUG    SPI        7      RSSI : -79
2023-08-10 20:35:48,917 DEBUG    SPI        7 Sent to channel(start)' : ToEmonCMS
2023-08-10 20:35:48,918 DEBUG    SPI        7 Sent to channel(end)' : ToEmonCMS
2023-08-10 20:35:49,108 DEBUG    MQTT       Publishing: emon/emonth2_23/temperature 24.3
2023-08-10 20:35:49,110 DEBUG    MQTT       Publishing: emon/emonth2_23/external temperature 23.200000000000003
2023-08-10 20:35:49,112 DEBUG    MQTT       Publishing: emon/emonth2_23/humidity 62.2
2023-08-10 20:35:49,113 DEBUG    MQTT       Publishing: emon/emonth2_23/battery 3
2023-08-10 20:35:49,114 DEBUG    MQTT       Publishing: emon/emonth2_23/pulsecount 0
2023-08-10 20:35:49,116 DEBUG    MQTT       Publishing: emon/emonth2_23/rssi -79
2023-08-10 20:35:49,220 DEBUG    emoncmsorg Buffer size: 1
2023-08-10 20:35:49,223 INFO     emoncmsorg sending: https://emoncms.org/input/bulk.json?sentat=1691696149&cb=1 (118 bytes of data, 1 frames, compressed)
2023-08-10 20:35:49,225 INFO     emoncmsorg compression ratio: 81%
2023-08-10 20:35:49,482 DEBUG    emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org (255 ms)
2023-08-10 20:36:08,894 INFO     SPI        Packet received 16 bytes
2023-08-10 20:36:08,896 DEBUG    SPI        8 NEW FRAME : 
2023-08-10 20:36:08,897 WARNING  SPI        8 RX data length: 16 is not valid for datacodes ['h', 'h', 'h', 'h', 'L']
2023-08-10 20:36:46,331 INFO     SPI        Packet received 12 bytes
2023-08-10 20:36:46,332 DEBUG    SPI        9 NEW FRAME : 
2023-08-10 20:36:46,334 DEBUG    SPI        9 Timestamp : 1691696206.332389
2023-08-10 20:36:46,334 DEBUG    SPI        9 From Node : 23
2023-08-10 20:36:46,335 DEBUG    SPI        9    Values : [24.3, 23.200000000000003, 62.2, 3, 0]
2023-08-10 20:36:46,335 DEBUG    SPI        9      RSSI : -79
2023-08-10 20:36:46,336 DEBUG    SPI        9 Sent to channel(start)' : ToEmonCMS
2023-08-10 20:36:46,336 DEBUG    SPI        9 Sent to channel(end)' : ToEmonCMS
2023-08-10 20:36:46,578 DEBUG    MQTT       Publishing: emon/emonth2_23/temperature 24.3
2023-08-10 20:36:46,581 DEBUG    MQTT       Publishing: emon/emonth2_23/external temperature 23.200000000000003
2023-08-10 20:36:46,582 DEBUG    MQTT       Publishing: emon/emonth2_23/humidity 62.2
2023-08-10 20:36:46,584 DEBUG    MQTT       Publishing: emon/emonth2_23/battery 3
2023-08-10 20:36:46,585 DEBUG    MQTT       Publishing: emon/emonth2_23/pulsecount 0
2023-08-10 20:36:46,587 DEBUG    MQTT       Publishing: emon/emonth2_23/rssi -79
2023-08-10 20:36:46,702 DEBUG    emoncmsorg Buffer size: 1
2023-08-10 20:36:46,703 INFO     emoncmsorg sending: https://emoncms.org/input/bulk.json?sentat=1691696206&cb=1 (118 bytes of data, 1 frames, compressed)
2023-08-10 20:36:46,704 INFO     emoncmsorg compression ratio: 81%
2023-08-10 20:36:46,942 DEBUG    emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org (237 ms)
2023-08-10 20:37:03,808 INFO     SPI        Packet received 16 bytes
2023-08-10 20:37:03,810 DEBUG    SPI        10 NEW FRAME : 
2023-08-10 20:37:03,811 WARNING  SPI        10 RX data length: 16 is not valid for datacodes ['h', 'h', 'h', 'h', 'L']
2023-08-10 20:37:43,665 INFO     SPI        Packet received 12 bytes
2023-08-10 20:37:43,666 DEBUG    SPI        11 NEW FRAME : 
2023-08-10 20:37:43,668 DEBUG    SPI        11 Timestamp : 1691696263.666744
2023-08-10 20:37:43,669 DEBUG    SPI        11 From Node : 23
2023-08-10 20:37:43,670 DEBUG    SPI        11    Values : [24.3, 23.200000000000003, 62.300000000000004, 3, 0]
2023-08-10 20:37:43,670 DEBUG    SPI        11      RSSI : -78
2023-08-10 20:37:43,671 DEBUG    SPI        11 Sent to channel(start)' : ToEmonCMS
2023-08-10 20:37:43,672 DEBUG    SPI        11 Sent to channel(end)' : ToEmonCMS
2023-08-10 20:37:43,930 DEBUG    MQTT       Publishing: emon/emonth2_23/temperature 24.3
2023-08-10 20:37:43,933 DEBUG    MQTT       Publishing: emon/emonth2_23/external temperature 23.200000000000003
2023-08-10 20:37:43,936 DEBUG    MQTT       Publishing: emon/emonth2_23/humidity 62.300000000000004
2023-08-10 20:37:43,939 DEBUG    MQTT       Publishing: emon/emonth2_23/battery 3
2023-08-10 20:37:43,942 DEBUG    MQTT       Publishing: emon/emonth2_23/pulsecount 0
2023-08-10 20:37:43,945 DEBUG    MQTT       Publishing: emon/emonth2_23/rssi -78
2023-08-10 20:37:43,967 DEBUG    emoncmsorg Buffer size: 1
2023-08-10 20:37:43,969 INFO     emoncmsorg sending: https://emoncms.org/input/bulk.json?sentat=1691696263&cb=1 (120 bytes of data, 1 frames, compressed)
2023-08-10 20:37:43,970 INFO     emoncmsorg compression ratio: 75%
2023-08-10 20:37:44,184 DEBUG    emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org (212 ms)
2023-08-10 20:37:58,642 INFO     SPI        Packet received 16 bytes
2023-08-10 20:37:58,643 DEBUG    SPI        12 NEW FRAME : 
2023-08-10 20:37:58,644 WARNING  SPI        12 RX data length: 16 is not valid for datacodes ['h', 'h', 'h', 'h', 'L']
2023-08-10 20:38:41,113 INFO     SPI        Packet received 12 bytes
2023-08-10 20:38:41,114 DEBUG    SPI        13 NEW FRAME : 
2023-08-10 20:38:41,115 DEBUG    SPI        13 Timestamp : 1691696321.113961
2023-08-10 20:38:41,116 DEBUG    SPI        13 From Node : 23
2023-08-10 20:38:41,117 DEBUG    SPI        13    Values : [24.3, 23.200000000000003, 62.300000000000004, 3, 0]
2023-08-10 20:38:41,117 DEBUG    SPI        13      RSSI : -79
2023-08-10 20:38:41,118 DEBUG    SPI        13 Sent to channel(start)' : ToEmonCMS
2023-08-10 20:38:41,119 DEBUG    SPI        13 Sent to channel(end)' : ToEmonCMS
2023-08-10 20:38:41,221 DEBUG    MQTT       Publishing: emon/emonth2_23/temperature 24.3
2023-08-10 20:38:41,223 DEBUG    MQTT       Publishing: emon/emonth2_23/external temperature 23.200000000000003
2023-08-10 20:38:41,224 DEBUG    MQTT       Publishing: emon/emonth2_23/humidity 62.300000000000004
2023-08-10 20:38:41,226 DEBUG    MQTT       Publishing: emon/emonth2_23/battery 3
2023-08-10 20:38:41,228 DEBUG    MQTT       Publishing: emon/emonth2_23/pulsecount 0
2023-08-10 20:38:41,230 DEBUG    MQTT       Publishing: emon/emonth2_23/rssi -79
2023-08-10 20:38:41,326 DEBUG    emoncmsorg Buffer size: 1
2023-08-10 20:38:41,328 INFO     emoncmsorg sending: https://emoncms.org/input/bulk.json?sentat=1691696321&cb=1 (120 bytes of data, 1 frames, compressed)
2023-08-10 20:38:41,330 INFO     emoncmsorg compression ratio: 75%
2023-08-10 20:38:41,583 DEBUG    emoncmsorg acknowledged receipt with 'ok' from https://emoncms.org (252 ms)
2023-08-10 20:38:53,470 INFO     SPI        Packet received 16 bytes
2023-08-10 20:38:53,471 DEBUG    SPI        14 NEW FRAME : 
2023-08-10 20:38:53,472 WARNING  SPI        14 RX data length: 16 is not valid for datacodes ['h', 'h', 'h', 'h', 'L']

Robert.Wall · 10 August 2023 19:44

You haven’t changed the DIP switch for Node 24. You have two types of data packet arriving from Node 23, one with 12 bytes and one with 16 bytes. That’s illegal - each sensor node MUST have an unique Node ID.

Or you can hard-code it in the sketch if you prefer.

Tommy_Monk · 10 August 2023 19:45

I did change the dip switches to what I think is correct, it seems to be backed up by the serial output ?

Robert.Wall · 10 August 2023 19:57

The Node number 24 certainly isn’t getting as far as the emonHub log - there’s something with 16 bytes arriving but it’s not Node 24.

I don’t have an emonPi with the latest RFM69 module. I need to do more digging to find out how the data is received by emonHub.

Tommy_Monk · 10 August 2023 20:01

It looks to me that emonth2.ino has nodeID set to 23 and relies on emonth2_config.ino for reading the dips.

I may be reading it wrong but I don’t see how the correct nodeId that is being calculated and printed to serial then makes it’s way back to the emonth2.ino.

It may be some old value 23 stored in eerom too I guess, I will hard code 24 to test the theory

UPDATE
Yes this has fixed it, I’m now seeing the readings come through from node 24, even though the node is reporting itself as 25 by serial monitor

Tommy_Monk · 10 August 2023 20:18

@Robert.Wall thanks you so much for all your help on this, much appreciated.