Update EmonTX firmware

borpin · 2018-03-23T21:18:57.431Z

Robert.Wall:

The ‘discretesampling’ sends 4 powers, voltage, 6 temperatures and a pulse count;

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?

pb66 · 2018-03-23T21:42:52.810Z

borpin:

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”)

github.com

openenergymonitor/emonTxFirmware/blob/master/emonTxV3/RFM/emonTxV3.2/emonTxV3_2_DiscreteSampling/emonTxV3_2_DiscreteSampling.ino#L73


      
          
          const float Vcal=                 276.9;                                // (230V x 13) / (9V x 1.2) = 276.9
          
          const float phase_shift=          1.7;
          const int no_of_samples=          1480; 
          const int no_of_half_wavelengths= 20;
          const int timeout=                2000;                               //emonLib timeout 
          const int ACAC_DETECTION_LEVEL=   3000;
          const byte min_pulsewidth= 110;                                // minimum width of interrupt pulse (default pulse output meters = 100ms)
          const int TEMPERATURE_PRECISION=  11;                 //9 (93.8ms),10 (187.5ms) ,11 (375ms) or 12 (750ms) bits equal to resplution of 0.5C, 0.25C, 0.125C and 0.0625C
          const byte MaxOnewire=             6;                            // +1 since arrya starts at 0. maximum number of DS18B20 one wire sensors
          //#define FILTERSETTLETIME          25000                     // Time (ms) to allow the filters to settle before sending data
          #define ASYNC_DELAY 375                                          // DS18B20 conversion delay - 9bit requres 95ms, 10bit 187ms, 11bit 375ms and 12bit resolution takes 750ms
          //-------------------------------------------------------------------------------------------------------------------------------------------
          //-------------------------------------------------------------------------------------------------------------------------------------------
          
          
          //----------------------------emonTx V3 hard-wired connections--------------------------------------------------------------------------------------------------------------- 
          const byte LEDpin=                6;                              // emonTx V3 LED
          const byte DS18B20_PWR=           19;                              // DS18B20 Power
          const byte pulse_countINT=         0;                              // Terminal Block Pulse counting pin(emonTx V3.4) - (INT0 / Dig2 emonTx V3.2)

borpin · 2018-03-23T21:46:13.281Z

Thanks. I’d picked out numSensors

github.com

openenergymonitor/emonTxFirmware/blob/adae16a2df8d50e09a06b46393c12072bdc7bef9/emonTxV3/RFM/emonTxV3.2/emonTxV3_2_DiscreteSampling/emonTxV3_2_DiscreteSampling.ino#L92

    
      
          const byte DS18B20_PWR=           19;                              // DS18B20 Power
          const byte pulse_countINT=         0;                              // Terminal Block Pulse counting pin(emonTx V3.4) - (INT0 / Dig2 emonTx V3.2)
          const byte pulse_count_pin=        2;                              // Terminal Block Pulse counting pin(emonTx V3.4) - (INT0 / Dig2 emonTx V3.2)
          #define ONE_WIRE_BUS              5                              // DS18B20 Data                     
          //-------------------------------------------------------------------------------------------------------------------------------------------
          
          
//Setup DS128B20
          OneWire oneWire(ONE_WIRE_BUS);
          DallasTemperature sensors(&oneWire);
          byte allAddress [MaxOnewire][8];  // 8 bytes per address
          byte numSensors;
          
          
//-------------------------------------------------------------------------------------------------------------------------------------------
          
          
//-----------------------RFM12B SETTINGS----------------------------------------------------------------------------------------------------
          #define RF_freq RF12_433MHZ                                              // Frequency of RF12B module can be RF12_433MHZ, RF12_868MHZ or RF12_915MHZ. You should use the one matching the module you have.
          const byte nodeID = 10;                                                // emonTx RFM12B node ID
          const int networkGroup = 210;
          typedef struct { 
          int power1, power2, power3, power4, Vrms, temp[MaxOnewire]; 
          int pulseCount;

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

pb66 · 2018-03-23T21:50:40.245Z

borpin:

I’d picked out numSensors

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

borpin:

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

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

Robert.Wall · 2018-03-23T23:26:06.597Z

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.

glyn.hudson · 2018-03-24T00:53:34.761Z

borpin:

I followed the link to the firmware on github from Using PlatformIO — OpenEnergyMonitor 0.0.1 documentation (paragraph 2) but that is a 404 and I also seem to remember that there was some discussion about updated firmware for some versions of the EmonTX.

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.

borpin · 2019-11-01T16:48:43.189Z

@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?

Robert.Wall · 2019-11-01T17:18:36.489Z

borpin:

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.)

borpin · 2019-11-01T17:50:16.111Z

Robert.Wall:

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

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.

Stefano_Truzzi · 2019-11-21T22:44:29.904Z

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?

Robert.Wall · 2019-11-22T00:45:00.322Z

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

Stefano_Truzzi · 2019-11-22T09:14:36.429Z

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

Stefano_Truzzi · 2019-11-22T10:37:45.862Z

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

Klaus_Riedmuller · 2020-01-02T22:43:54.811Z

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.

Robert.Wall · 2020-01-02T23:59:43.864Z

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.

Klaus_Riedmuller · 2020-01-15T20:00:15.456Z

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!

Robert.Wall · 2020-01-15T20:25:59.503Z

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.

Robert.Wall · 2020-01-18T20:46:57.746Z

@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.

Klaus_Riedmuller · 2020-01-20T07:15:40.859Z

Robert.Wall:

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

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]

Robert.Wall:

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

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.

Robert.Wall · 2020-01-20T12:13:10.142Z

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