Update EmonTX firmware

I suspect this may be what I am using but I have 8 temperature sensors attached.

@Robert.Wall - skipping through the code, it looks like it will just detect the number of sensors attached. Am I reading this correctly?

You will need to edit the max number to allow up to 8 sensors, the max is currently 7 (defined as “6” you need at least “7”)

Thanks. I’d picked out numSensors

All I’ve got to do now is work out how to load the Jeelib library (once I’ve found it).

numSensors is the number of sensors found/occupied up to a max of MaxOnewire

I think you have to use GitHub - openenergymonitor/RFu_jeelib: Modified version of the JeeLib RFM12B wireless radio driver for use with the Ciseco RFu 328 units V1.x with an RFM12B for the RFu328 based emonTx’s

1 Like

Yes, you must not change it from RFu_jeelib to ordinary Jeelib. The full instructions for doing it by hand - installing the the proven Arduino IDE and getting the libraries - are in Learn → Electricity Monitoring → Arduino IDE.

(If you get the ordinary JeeLib, it won’t use it unless you edit the sketch and specifically include it.)

If you have 8 sensors, MaxOnewire needs to be 8, they’re numbered 0 - 7 in the C language.

It’s now been fixed, and the guide has been updated to remove reference to setting the RF node ID as this can now be easily done via the serial config. Thanks for letting me know about the 404.

1 Like

@Robert.Wall, I am at last getting around to fixing the issues I have with my EmonTX (8 sensors overrun the 10s).

I’ve removed the temp sensors from the EmonTX completely so would now like to replace the firmware.

Is it possible to use the CM Library / Firmware on a V3.2 or should I just use the stock 3.2 firmware?

I don’t see why not, it’ll run - and I did a lot of the testing - on a V2 because that gave me access to a lot of DIO that I could hang a 'scope on to look at the timing.

But beware the sketch is really nothing like an emonLib(DS) sketch, your starting point should be one of my demo sketches. The timing was calculated for a maximum of 6 temperature sensors, I think you might be OK with 8 temperature sensors but I have only 3, so I haven’t proved it. If you find problems, I’ll look again at it.

(What happens is it anticipate when a report of all the values will happen, and just in time fires off a “Convert the temperatures” request at all the sensors. Then it fetches the temperatures from each sensor in turn after it’s processed the powers and pulse count - that is, it lets the sensors get on with the reading and converting part in their own time, rather than holding everything up while each does its thing, then it comes back for the answers. I did it that way so that the temperatures are the most recent available, they’re all read at the same instant, and it only marginally affects the other operations.)

I’ve taken them off the EmonTX completely and they are now hooked up to a WEMOS D1 and ESPHome (really easy to do).

All I want to use it for now is the power measurement. I’ve got an AC adapter for it.

Hello
I have a old Emontx V3.2.1 with emonTxV3_2_DiscreteSampling.ino flashed, id 8, RF 433 mhz, group 210.
I tried to connect a rasperry Pi but I can’t view it in imput page (no problem to reading 3 other emontxv3.4 and 2 emonth). No duplicated id.
Suggenstions?

Welcome back, Stefano.

Have you changed emonhub.conf? You need to, because the new definition for Node 8 is:
power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
Your emonTx V3.2 sends only
power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6
(There is no “pulse” count.)

What you need in emonHub.conf is:

[[8]]
    nodename = emontx_V3_2
    [[[rx]]]
       names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6
       datacodes = h,h,h,h,h,h,h,h,h,h,h
       scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1
       units =W,W,W,W,V,C,C,C,C,C,C

Defnition i emonhub changed, but still not visible the old emontx, maybe problem with rf?

Solved!

[[8]]
    nodename = emontx_V3_2
    [[[rx]]]
       names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6
       datacode = h
       scales = 1,1,1,1,0.01,0.1,0.1, 0.1,0.1,0.1,0.1
       units =W,W,W,W,V,C,C,C,C,C,C

Hi … I’m running into similar issues like you - using “old” EmonTx v3.2 hardware with RFu328 and trying to update to GitHub - openenergymonitor/EmonTxV3CM: EmonTxV3 Continuous Monitoring Firmware (Default shipped EmonTxV3 firmware)[EmonTxV3 Continuous Monitoring Firmware]

Currently I changed the new sketch to compile using RFu_jeelib instead of Jeelib as propose by @Robert.Wall - and it starts up, but re-initialises RFM periodically after a few seconds. The node is displayed in emonHub, but just zeros are received. Serial config can be access via +++ command through Arduino console. Current clamps and AC signal are found and correctly displayed in the debug window (serial output to Arduino IDE).

The data format is aligned in emonHub and should fit to new firmware data format.
It seems that there are still issues between 2014 hardware and current EmonTX sketch to periodically send the data packets to emonHub.

Any adivse or did anyone else run through this already to run TX v3.2 with latest FW?

Thanks a lot for your support.
–Klaus.

Welcome, Klaus, to the OEM forum.

If it is resetting after a few seconds, do you have the watchdog enabled?

All my tests were done using sketches very close to the demonstration sketches that come with emonLibCM. Those do not have the watchdog, so I cannot say whether that might or might not be a problem.

I think there might be a problem with the present JeeLib, as yet that is not confirmed. However, the test sketches seem to be absolutely solid ( > 500000 messages without a fault) when “rfm.ino” from the 3-phase sketch is substituted for JeeLib.

Thanks @Robert.Wall

the watchdog is disabled in the sketch.

The sketch I am using is identical to the one that is available on GitHub for the current v3.4 emonTx hardware, just JeeLib.h was replaced by RFu_jeelib.h as proposed earlier in this post (GitHub - openenergymonitor/RFu_jeelib: Modified version of the JeeLib RFM12B wireless radio driver for use with the Ciseco RFu 328 units V1.x with an RFM12B) to be in line with v3.2 / RFu328 hardware.

Your suggestion is to use rfm.ino instead of JeeLib? Does this mean to remove reference to JeeLib.h/RFu_jeelib.h in the sketch and just add rfm.ino to the sketch folder?
Sorry for such a question, but I am not that familiar with Arduino so your I appreciate your support even more. Thanks!

If you are using RFu_jeelib, that was derived from JeeLib many years ago, in 2013, so it should not be having the same problems that new users are seeing.

So before I go any further, can I check what you want to do:

You want to use the continuous monitoring library on an emonTx V3.2 that’s fitted with the RFμ radio module. Is that correct?

I do have an emonTx V3.2, I am almost certain that I tested emonLibCM on it, but with the demonstration sketch that comes with the library, rather than with the GitHub “EmonTxV3CM” sketch. I shall go back to it and test again.

At the present time, I’m testing a V3.4 with a simplified version of that sketch and it has sent more than 875000 messages (at one per second) without a problem. If that runs on the V3.2, you might want to try that.

@Klaus_Riedmuller

I am now testing a simplified version of EmonTxV3CM using the RFM12B version of the ‘transmit only’ code from the 3-phase sketch.

So far, it has run for 1090 messages (3 hours) so I am hopeful that this will solve your problem.

Yes, exactly. However, I currently rolled back to the original firmware (discrete sampling) on my 3 ea emonTX v3.2 which works well so far. [emonTxV3_2_DiscreteSampling]

This looks promising! Can you share what needs to be re-configured to run it on my good old V3.2s?
If it’s too complicated I can still stay on the discrete sampling sketch, but if it’s just minor adaptions I would prefer to use the latest EmonTxV3CM sketch.

I am not yet two days into testing - it is too early yet to say that this is a cure.