Monitoring System Firmware Update

Hardware
, ,
1

My energy monitoring and control system currently includes:

  • 2 x emonTxV3.4.3 (with modified firmware based on emonTxV3.4 CM V2.0);
  • 3 x emonTHV2 (with firmware V3.2.4); and
  • an emonbase (RPi 5 fitted with RFM69PI V3.1 RF expansion board)

I would like to add an additional emonTH to the system, with 4 external DS18B20 temperature sensors or possibly modify one of the existing ones to use the 4 external sensors.

Review of the documentation indicates that, in either case, I will need to update the firmware of the emonTH to achieve this.

I have successfully modified and updated the firmware on the emonTx units previously using the Arduino IDE and a CP2102 USB-to-UART Bridge Controller. In preparing to update one of my existing emonTH units I have successfully read the serial output recently using this setup.

In exploring the available firmware for the emonTH (v4.2.1 at https://github.com/openenergymonitor/emonth2/tree/master/firmware), and attempting to retain the JeeLib Classic radio format that all my other devices use, I encountered several errors related to RF69_433_92MHZ not being defined in the version of the rfmTxLib.h file at https://github.com/openenergymonitor/rfmTxLib/blob/main/rfmTxLib.h.

Clearing out all references to RF69_433_92MHZ, the sketch compiled successfully however I’m not confident this will be the last of my problems with maintaing my existing configuration and it may be time to update everything to latest firmware configuration - including the Low Power Labs radio format.

So, assuming I am not the only person out there in this situation, I have the following questions:

1. Is updating all the above equipment to the latest firmware configuration, including the Low Power Labs radio format, possible?

2. Noting my preference to add an additional component the system, is updating all the above equipment to the latest firmware configuration, including the Low Power Labs radio format, recommended?

3. Is there a guide somewhere on how to it?

2

Welcome back.

Yes, it should be possible, but it is probably the most risky way. Ultimately though, probably the best long-term. The show-stopper would be a Hope RFM12B radio module in one of the devices - you should not have one, but it would be worth checking. There are pictures here: RFM12B & RFM69CW Wireless Transceiver Modules — OpenEnergyMonitor 0.0.1 documentation. You should be able to visually identity that you have all RFM69CW modules - these do all the processing that the original JeeLib did and a lot more besides, including encrypting the data.

Not that I know of. All the information is certainly on this site somewhere, either in Docs (the starting place) or buried in the forum, and if it’s there, your problem will be finding it. :anguished:

What exactly did you do to the emonTx’s? Presumably you’re reasonably happy with working with the C language and the Arduino IDE, do you think you can merge that change into the present default sketches?

3

Thank you Robert.

Nothing ground breaking:

  • added the supply frequency and power factors to the transmitted data;
  • increased the number of external temperature sensors to 4; and
  • reported the state of the digital input (normally used for pulse counting) to send on the state of some voltage free contacts in another nearby device.

I’ve had a look at the V2.4.0 version at https://github.com/openenergymonitor/emontx3/tree/master/firmware/emonTx34/emonTx34_CM and it appears as though it has not significantly changed the underlying code structure; so I think so.

The question will be how to sequence the equipment changes so I can test along the way while minimising the risks of not being able to revert and rendering everything useless. It is the RFM69PI expansion board that I am nervous about. It took some time to get it to work with the RPi5 and the shop does not appear to be selling this board or an equivalent at present. Can the RFM69PI board be easily changed between JeeLib Classic and Low Power Labs format?

4

No, not easily - you need to upload code to the on-board processor.
It appears I was wrong. It’s not difficult, it is actually documented (but they never tell us when the docs are updated) emonBase with RFM69Pi (ATmega328) — OpenEnergyMonitor 0.0.1 documentation

If you get its successor, the RFM69SPI, there is no separate processor on the module, it’s all done inside the RPi, so swapping back should be easy, if the JeeLib software exists in the RPi - but I don’t actually know. The shop page for the emonBase says “by default the new version of the emonBase with the RFMSPI is NOT compatible with older hardware e.g emonTx V3. Please contact us if you would like a version which is compatible with older hardware.” I think this is a half-truth - I think it really means the radio protocol is not compatible. So this has to be one for @TrystanLea to answer.

I can’t see a way that you can test as you go, unless you get a second emonBase with the RFM69SPI. Then, you could use this to test the first emonTx you change, then the second, then the emonTH’s, meanwhile sending the data back to the original emonBase via your LAN.

5

If you let the shop know when you order the emonTH can be supplied with the correct FW for 4x DS18B20s. So it will be plug and play with your existing setup.

6

This might be the easiest way to go in the short term but I suspect that, as @Robert.Wall suggested, it will be better in the long run to migrate the system to the Low Power Labs radio format.
I am confident in updating the firmware of my current emonTx and emonTH units, I have done this before. It is the is the RFM69PI that I am unsure of. Can the RFM69PI be reliably reconfigured to the different radio formats using the update firmware functionality in EmonCMS - specifically reverting it to the JeeLib Classic format?

image
image1124×244 13.4 KB

If so, then I think I will have a go at updating one of my emonTHs to the new radio format and testing it before committing to updating the emonTxs as well. The configuration of a new emonTH will then depend on the outcome …

7

All I can say is if you select JeeLib, the choice is this

image
image815×186 27.8 KB

So it would appear that the answer is yes. I haven’t got a working emonBase, so I can’t try it.

I think your route is, update an emonTH. You’ll know something has changed if it stops reporting. If this happens, update your emonBase. If the emonTH appears there and everything else disappears, all is well and you can follow with everything else. If not, I’d revert the emonBase and see if you still have the emonTx’s. I think this is the safest route.

8

Qualified Success.

  1. Updated one emonTH with V4.2.1 firmware configured for JeeLib Classic. Data recieved by the emonBase. This was a good sign.
  2. Updated same emonTH with V4.2.1 formware configured for Low Power Labs. Updated rfm69pi configured for Low Power Labs. EmonTH data recieved by emonBase. Also good.
  3. Updated rfm69pi configured for JeeLib Classic. Data recieved by other existing emonTH and emonTx. Good.
  4. Updated emonTH with V4.2.1 firmware configured for JeeLib Classic. NO data from this emonTH recieved by emonBase. Not good.
  5. Changed both emonTH and rfm69pi to Low Power Labs again and emonTH data recieved by emonBase. Good.
  6. Changed both emonTH and rfm69pi to JeeLib Classic again. No data from this emonTH recieved by the emonBase. Not good. Data recieved by other existing emonTH and emonTx. Good.

Tried many times to revert the emonTH to Jeelib Classic. No success.

This is the output of the emonTH from the serial monitor at startup.

OpenEnergyMonitor.org
emonTH FW: V4.2.1
Loaded EEPROM config
Group 210, Node 24, Band 433 MHz
pulses enabled = 0
pulse period = 50 ms
DS18B20 enabled = 0
RF on
Serial on
RF power = 7 dBm
RadioFormat: JeeLib Classic
Init RFM...
RFM Started
Int SI7021..
SI7021 Started, ID: 21
temp:21.85,humidity:57.89
Serial on
'+++' then [Enter] for config mode, waiting 3s...
Continuing without entering config mode...
temp:218,humidity:578,batt:28
temp:218,humidity:578,batt:29

but nothing from node 24 in the emonHub log.

All the above was conducted with the programmer connected to the emonTH. Disappointed, I decided to draft this post, to ask for help, expecting to have to come back another day.

Unplugged the programmer and, lo and behold, data from node 24 turned up in emonHub.

Swapped things back and forth again a couple of times to confirm. No data in JeeLib Classic configuration with the programmer connected. Data appears when the programmer is removed and the emonTH restarted. Not quite as expected, but worth proceeding.

So I think I will have a go at one of the emonTxs next.

9

I don’t understand why you want to go back to JeeLib, once you’ve proved you converted your emonBase successfully. My primary concern was the processor in the RFM69Pi is not an ATMega 328P, hence I would expect you to have struggled to update it using the Arduino IDE and uploading the compiled code to it via the RPi. Now that you’ve by-passed that, I think you will not have a problem with the emonTH’s and emonTx’s, because even if you ignore the pre-compiled upload from your emonBase and use the Ardiono IDE, it’s the same procedure as you’ve used before - the only difference is you’ll need the LPL library file when you compile.

10

The reversion is just to allow some time to set up the change for the emonTxs without losing all my monitoring functionality for too long.

11

So after some distraction, I came back to the task of trying to change over the emonTx3 to LPL.

After some difficulties with libraries, which I can detail later, I got an emonTx3 running with the LPL configured firmware. So I changed the emonTh2 and the RFM69PI over to the LPL firmware to test it all. The emonTh2 data was recieved but not the emonTx3. So I reverted everything to JeeLib Classic and everything was being recieved. Tried LPL again with similar results - emonTh2 recieved and emonTx3 not.

Is there a change to the interfacer settings in emonhub.conf that also needs to be made?

12

Indeed there is. In your emonhub.conf file, instead of this

[[8]]
    nodename = emonTx_3
    firmware =V2_3_emonTxV3_4_DiscreteSampling
    hardware = emonTx_(NodeID_DIP_Switch1:OFF)
    [[[rx]]]
       names = power1, power2, power3, power4, Vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1,1
       units =W,W,W,W,V,C,C,C,C,C,C,p

you need to have this:

[[15]]
  nodename = emonTx3cm15
  [[[rx]]]
    names = MSG, Vrms, P1, P2, P3, P4, E1, E2, E3, E4, T1, T2, T3, pulse
    datacodes = L,h,h,h,h,h,l,l,l,l,h,h,h,L
    scales = 1,0.01,1,1,1,1,1,1,1,1,0.01,0.01,0.01,1
    units = n,V,W,W,W,W,Wh,Wh,Wh,Wh,C,C,C,p

It’s OK to have both entries, but you must not have two entries with the same Node ID - the Node ID is the [[8]] and the [[15]] in the above.
If you still get nowt out, check the Node ID coming from your LPL emonTx3 - it’s quite in order to change the 15 to whatever the emonTx is configured as, bearing in mind the last sentence above.

Don’t confuse this - the Nodes Configuration - with an Interfacer. The interfacer is a separate piece of software, but still part of emonHub.

13

Hi Robert,

Firstly thank you for your timely and generous support of this forum and the experience that you continue to bring.

For my emonTx3, the only difference in the firmware I am loading between the operative state and the non-operative state is the line:

#define RadioFormat RFM69_JEELIB_CLASSIC

When in this configuration, the emonTx3 data is received by the RFM96Pi with the jeelib_classic, v1.4.0 firmware loaded.

I previously modified the firmware to transmit the power factors, an additional temperature sensor and another digital input. The data structure in the firmware is:

typedef struct {
    unsigned long Msg;
    int Vrms,F,P1,P2,P3,P4;                                // V2.4.0.J F added for line frequency
    long E1,E2,E3,E4; 
    int pf1,pf2,pf3,pf4;                                   // V2.4.0.J added power factors
    int T1,T2,T3,T4;                                       // V2.4.0.J added T4
    unsigned long pulse;
    boolean error;                                         // V2.4.0.J added error signal
} PayloadTX;
PayloadTX emontx;                                          // create a data packet for the RFM

and the corresponding node configuration I am using is:

[[15]]
    nodename = emontx3cm15
    [[[rx]]]
       names = MSG, Vrms, F, P1, P2, P3, P4, E1, E2, E3, E4, pf1, pf2, pf3, pf4, T1, T2, T3, T4, pulse, error
       datacodes = L,h,h,h,h,h,h,L,L,L,L,h,h,h,h,h,h,h,h,L,b
       scales = 1,0.01,0.01,1,1,1,1,1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1,1
       units = n,V,Hz,W,W,W,W,Wh,Wh,Wh,Wh,n,n,n,n,C,C,C,C,p,b
       whitening = 1

When I change the emonTx3 firmware to:

#define RadioFormat RFM69_LOW_POWER_LABS

and load the RFM69Pi with the lowpowerlabs, v1.1.1 firmware, there is no emonTx3 data recieved. In this configuration, there is data being recieved by appropriately configured emonTh units.

Could there be a packet length difference between the two radio formats that I have unwittingly exceeded with the emonTx3?

When I asked about interfacers, I was pointing to these lines in the emonhub.conf file:

### This interfacer manages the RFM12Pi/RFM69Pi/emonPi module
[[RFM2Pi]]
    Type = EmonHubJeeInterfacer

    [[[init_settings]]]
        com_port = /dev/ttyAMA0
        com_baud = 38400                        # 9600 for old RFM12Pi
    [[[runtimesettings]]]
        pubchannels = ToEmonCMS,
        subchannels = ToRFM12,

        group = 210
        frequency = 433
        baseid = 5                              # emonPi / emonBase nodeID
        calibration = 230V                      # (UK/EU: 230V, US: 110V)
        quiet = true                            # Disable quite mode (default enabled) to enable RF packet debugging, show packets which fail crc
        # interval =  300                         # Interval to transmit time to emonGLCD (seconds)

This appears to suggest that there is an aspect of the RFM69Pi interfacer that could be JeeLib specific.

14

You didn’t say you had kept your original but modified sketch.

There is a length limit for the RFM69 and LPL, according to the notes in Trystan’s custom version of LPL, it is 62 bytes, according to my notes, it is 61 bytes, down from 66 in the Jeelib ‘Classic’ format.

Radio Packet Formats.pdf (48.1 KB)

According to my count, you have 53 bytes so you should be OK. But what is “whitening” doing - and have you dealt with the encryption that’s built into the RFM69 and used by default in LPL and which renders whitening unnecessary?

Another possible problem - we’re changing the radio frequency, from 433.0 MHz to 433.92 MHz, so you need to know which you’re changing to. (433.00 MHz is actually illegal - part of the transmitted signal is outside the band, blame JeeLib.)

But that works as a switch and swaps many sections over from one library format to another, so unless you have all that, there’s a lot missing from your sketch.

What I think I need is a complete copy of your sketch - if you’ve mentioned it, I can’t find it now, so I don’t even know what it’s based on.

15

Here is a copy.

emonTx34_CMV2.4.J.zip (13.1 KB)

The lines I have modified are marked. You might notice that I removed references to 433.92 MHz. This was because the library supporting the JeeLib classic radio format that I have (rfmTxLib.h Version 2.0 10/3/2021), does not appear to support the value definitions for this frequency.

With respect to the legality of 433.0 MHz, I live in Australia and I am not sure of the details of the approved spectrum here. For reference I have used 433 MHz in the emonTh firmware as well.

  byte RF_freq = RF69_433MHZ;                                          // Frequency of radio module can be RF69_433MHZ, RF69_868MHZ or RF69_915MHZ. Note RF69_433_92MHZ is also availavle in the LPL library  //Jaddache set to RF69_433MHZ
16

From what I read here saying “Under the current ACMA Radio Communications (Low‑Power Devices) Class Licence, 433.050–433.650 MHz is allocated to the “Industrial, Scientific and Medical” (ISM) band and to short‑range devices. Devices such as remote keyless entry systems, garage door openers, and hobby‑radio transceivers are permitted provided they do not exceed 10 mW ERP, use a fixed antenna, and display the ACMA compliance label.” It would appear that both the original JeeLib and LPL both originally and as we now use it are non-compliant where you are. However, by limiting the output power to 10 mW (+10 dBm, and we default to work below that at +7 dBm anyway) and using a centre frequency of 433.35 MHz, it should comply. Both these things only require a small change in the LPL library (or overriding its settings during startup - I haven’t worked with LPL so I’d need to check).

Bearing this in mind, how would you like to end up? I’m guessing with all things working legally, as a baseline?

Would you want a complete custom set-up - which would mean modified firmware in every device?

I’m going to see what @awjlogan thinks here, because it has implications for the emonTx6 and emonPi3, and he knows more about those than anybody else.

17

Yes.

The emonTx will need to have custom firmware to transmit the extra digital signal and the forth temperature sensor. The emonTh can be standard but I will end up modifying one to use multiple external temperature sensors.

18

What I meant was, in regard to the ISM Band operating frequency. Obviously, that means all things - including any you add in the future - need to be adjusted for the Australian ISM band.

I’ve only just got your sketch loaded into an emonTx V3.4, it’s hitting the watchdog so I presume not getting through initialisation.

19

It looks as if this is morphing into something rather more complicated than it first appeared.

What I’m thinking of doing is a minor tweak to the r.f. libraries to operate on 433.35 MHz for Australia, and then merging your custom emonTx V3.4 sketch with the standard emonTx34_CM sketch. The problem is, G&T switched to the LPL library shortly after I’d developed the emonPiCM and before it was adopted as standard, effectively binning all the work I’d done on that, which left a bad taste. So I’ve had no interest in LPL or finding out anything about it. But I do know my way around the RFM69CW, and I know what needs changing. It’s just a matter of finding where it’s done in LPL.

I think going to LPL and changing the frequency to 433.35 MHz is going to be the best route for you, both in terms of future-proofing and legally with regard to the ISM Band in Australia. The unfortunate consequence is any new OEM kit you buy will need to have custom software compiled with your Australian LPL libraries (and just to complicate it further, there are two: RFM69 & RFM69_LPL).

It is important to say that from the limited information available to me at the time of writing, I believe OEM equipment modified as described will comply with the law where you are, but as importer, all liability rests with you.

I won’t start on this until you say so.

20

By way of checking that I still know what I’m doing (with Arduino, ATMega 328s, etc) I got the Github emonTx3 LPL sketch working fine using LPL, albeit with an 868 MHz radio working at 433 MHz, into an emonPi3. My initial problem with the watchdog was down to having two fixed-focus acrylic lenses in my eyes :roll_eyes: (I’d picked up the emonTx3 with an RFM12B.)

Now the bad news (perhaps) is, having put your Node 15 definition into my emonhub.conf but with your comments preceded by # (not // - it’s not C or C++), I’m also getting data from your sketch - having changed to LPL as you did.

2026-06-28 22:56:27,370 INFO     SPI        Packet received 53 bytes
2026-06-28 22:56:27,370 DEBUG    SPI        812 NEW FRAME : 
2026-06-28 22:56:27,371 DEBUG    SPI        812 Timestamp : 1782683787.370379
2026-06-28 22:56:27,371 DEBUG    SPI        812 From Node : 15
2026-06-28 22:56:27,371 DEBUG    SPI        812    Values : [50, 259.5, 50.01, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 300, 300, 300, 300, 0, 0, 0, 0.0]
2026-06-28 22:56:27,372 DEBUG    SPI        812      RSSI : -45
2026-06-28 22:56:27,372 DEBUG    SPI        812 Sent to channel(start)' : ToEmonCMS
2026-06-28 22:56:27,372 DEBUG    SPI        812 Sent to channel(end)' : ToEmonCMS
2026-06-28 22:56:27,598 DEBUG    MQTT       Publishing: emon/emonTx3cm15/MSG 50
2026-06-28 22:56:27,599 DEBUG    MQTT       Publishing: emon/emonTx3cm15/Vrms 259.5
2026-06-28 22:56:27,599 DEBUG    MQTT       Publishing: emon/emonTx3cm15/F 50.01
2026-06-28 22:56:27,600 DEBUG    MQTT       Publishing: emon/emonTx3cm15/P1 0
2026-06-28 22:56:27,601 DEBUG    MQTT       Publishing: emon/emonTx3cm15/P2 0
2026-06-28 22:56:27,601 DEBUG    MQTT       Publishing: emon/emonTx3cm15/P3 0
2026-06-28 22:56:27,602 DEBUG    MQTT       Publishing: emon/emonTx3cm15/P4 0
2026-06-28 22:56:27,603 DEBUG    MQTT       Publishing: emon/emonTx3cm15/E1 0
2026-06-28 22:56:27,603 DEBUG    MQTT       Publishing: emon/emonTx3cm15/E2 0
2026-06-28 22:56:27,604 DEBUG    MQTT       Publishing: emon/emonTx3cm15/E3 0
2026-06-28 22:56:27,605 DEBUG    MQTT       Publishing: emon/emonTx3cm15/E4 0
2026-06-28 22:56:27,605 DEBUG    MQTT       Publishing: emon/emonTx3cm15/pf1 0
2026-06-28 22:56:27,606 DEBUG    MQTT       Publishing: emon/emonTx3cm15/pf2 0
2026-06-28 22:56:27,607 DEBUG    MQTT       Publishing: emon/emonTx3cm15/pf3 0
2026-06-28 22:56:27,607 DEBUG    MQTT       Publishing: emon/emonTx3cm15/pf4 0
2026-06-28 22:56:27,608 DEBUG    MQTT       Publishing: emon/emonTx3cm15/T1 300
2026-06-28 22:56:27,608 DEBUG    MQTT       Publishing: emon/emonTx3cm15/T2 300
2026-06-28 22:56:27,609 DEBUG    MQTT       Publishing: emon/emonTx3cm15/T3 300
2026-06-28 22:56:27,610 DEBUG    MQTT       Publishing: emon/emonTx3cm15/T4 300
2026-06-28 22:56:27,610 DEBUG    MQTT       Publishing: emon/emonTx3cm15/pulse 0
2026-06-28 22:56:27,611 DEBUG    MQTT       Publishing: emon/emonTx3cm15/error 0
2026-06-28 22:56:27,611 DEBUG    MQTT       Publishing: emon/emonTx3cm15/missed 0
2026-06-28 22:56:27,611 DEBUG    MQTT       Publishing: emon/emonTx3cm15/missedprc 0.0
2026-06-28 22:56:27,612 DEBUG    MQTT       Publishing: emon/emonTx3cm15/rssi -45

And it’s made it into emonCMS and onto the Inputs page too…

image
image662×806 31.7 KB

I’ve only got the a.c. adapter connected for now.

I replaced one of the # comment deliminators with your // and it all blew up…

2026-06-28 23:10:54,350 INFO     SPI        Packet received 53 bytes
2026-06-28 23:10:54,350 DEBUG    SPI        8 NEW FRAME : 
2026-06-28 23:10:54,351 WARNING  SPI        8 RX data length: 53 is not valid for datacodes ['L', 'h', 'h', 'h', 'h', 'h', 'h', 'l', 'l', 'l', 'l', 'h', 'h', 'h', 'h', 'h', 'h', 'h', 'h', 'L', 'b                                                   // V2.4.0.J Line Frequency data code added (h)', 'power facors data codes added (h)', 'T4 datacode added (h)']

So I think that was your problem - and if you’d looked in the emonhub log you’d have seen another 3 lines for the other 3 illegal comments.

Here’s your valid Node definition out of my emonhub.conf

[[15]]
  nodename = emonTx3cm15
  [[[rx]]]
    names = MSG, Vrms, F, P1, P2, P3, P4, E1, E2, E3, E4, pf1, pf2, pf3, pf4, T1, T2, T3, T4, pulse, error  # V2.4.0.J Line Frequency name added (F),  power factors added (pf1, pf2, pf3, pf4), T4 added
    datacodes = L,h,h,h,h,h,h,l,l,l,l,h,h,h,h,h,h,h,h,L,b                                                   # V2.4.0.J Line Frequency data code added (h), power facors data codes added (h), T4 datacode added (h) 
    scales = 1,0.01,0.01,1,1,1,1,1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1,1                       # V2.4.0.J Line Frequency scale added (0.01), power factors scales added (0.01), T4 scale added (0.01) 
    units = n,V,Hz,W,W,W,W,Wh,Wh,Wh,Wh,n,n,n,n,C,C,C,C,p,b                                                  # V2.4.0.J Line Frequency unit added (Hz), power factors units added (n), T4 unit added (C)

The small matter of your illegal frequency remains, so let me know what you want to do about that.