emonTx4, emonPi2, emonTx5 14th May 2024 firmware release

rupert · 2024-05-16T17:17:19.962Z

Thanks for the answer

borpin · 2024-05-17T06:13:30.644Z

TrystanLea:

When used with the latest firmware loaded to the device

Is the serial config tool backward compatible? Can you fully define ‘latest’ - release date/version? Does this just add UI functionality that was previously available via the CLI?

TrystanLea:

To change CT sensor or voltage sensor calibration if you have recently updated emoncms, the new interface requires updated firmware.

Ah, that isn’t good IMHO.

TrystanLea · 2024-05-17T07:44:43.638Z

borpin:

Ah, that isn’t good IMHO.

The alternative is a whole load of messy code unfortunately. My rationale here was that folk who have already setup their systems on a particular firmware won’t need to use this tool. The times this tool is used is during significant reconfiguration and these points are a good time to update firmware.

The tool still allows fallback to written command configuration, which is also documented.

TrystanLea · 2024-05-17T07:47:09.010Z

The command format is mostly the same, there are just a few small differences in what is printed, il post and example shortly

borpin · 2024-05-17T08:11:25.798Z

TrystanLea:

The alternative is a whole load of messy code unfortunately.

I think this should be very clearly stated at the top of the page, that the UI tool only works with Firmware and Hardware X otherwise the CLI interface must be used.

TrystanLea · 2024-05-17T08:47:25.715Z

Ah I did think about this, the tool detects older firmware and gives a clear warning message and instructions to start the command line process if required:

image1444×543 84 KB

TrystanLea · 2024-05-17T08:57:22.928Z

For reference this is an example print out from the original EmonTx4 firmware v1.5.7:

emonTx V4 CM Continuous Monitoring V1.5.7

OpenEnergyMonitor.org
No EEPROM config
Settings:
Band 433 MHz, Group 210, Node 17, 7 dBm
Calibration:
vCal = 807.86
assumedV = 240.00
i1Cal = 300.30
i1Lead = 3.20
i2Cal = 150.15
i2Lead = 3.20
i3Cal = 150.15
i3Lead = 3.20
i4Cal = 60.06
i4Lead = 3.20
i5Cal = 60.06
i5Lead = 3.20
i6Cal = 60.06
i6Lead = 3.20
datalog = 9.80
pulses = 1
pulse period = 100
RF on
temp_enable = 1
JSON Format Off
RFM69CW  Freq: 433MHz Group: 210 Node: 17 
RadioFormat: LowPowerLabs
Reference voltage calibration: 1.0265
Temperature Sensors found = 0 of 3
Temperature measurement is enabled.

No temperature sensors detected, disabling temperature
AC missing - Apparent Power calc enabled, assuming 240.00 V
MSG:1,Vrms:240.00,P1:433,P2:217,P3:217,P4:87,P5:87,P6:87,E1:0,E2:-1,E3:1,E4:0,E5:0,E6:0,pulse:0
MSG:2,Vrms:240.00,P1:11,P2:6,P3:6,P4:2,P5:2,P6:2,E1:0,E2:-1,E3:1,E4:0,E5:0,E6:0,pulse:0

and then the new emonTx4_CM_temperature firmware v1.6.0:

firmware = emon_CM_6CT_temperature
version = 1.6.0
hardware = emonTx4
voltage = 1phase
No EEPROM config
vCal = 101.10
assumedV = 240.00
iCal1 = 100.00, iLead1 = 3.20
iCal2 = 50.00, iLead2 = 3.20
iCal3 = 50.00, iLead3 = 3.20
iCal4 = 20.00, iLead4 = 3.20
iCal5 = 20.00, iLead5 = 3.20
iCal6 = 20.00, iLead6 = 3.20
pulse = 3, pulsePeriod = 100ms
RF = on, rfBand = 433 MHz, rfGroup = 210, rfNode = 17, rfPower = 25, rfFormat = LowPowerLabs
datalog = 9.80
json = off
vrefa = 1.0264
Temperature Sensors found = 0 of 3
Temperature measurement is enabled.

No temperature sensors detected, disabling temperature
temp_enable = 0
AC missing - Apparent Power calc enabled, assuming 240.00 V
MSG:1,Vrms:240.00,P1:432,P2:217,P3:217,P4:87,P5:87,P6:87,E1:0,E2:-1,E3:1,E4:0,E5:0,E6:0,pulse:0

There is now a bit more consistency in the format of the printed settings, including printed firmware and hardware details. Settings or configuration to be picked up by the tool needs to follow the format:

key = value

This is to distinguish from data that is passed through, which follows either:

key: value,

or json:

{"key":value}

The actual serial commands are all the same, the change is only in the way the configuration are printed back from the device.

TrystanLea · 2024-05-17T10:03:58.072Z

rupert:

Thanks for the answer

12 CT firmware with serial config on the way! Compiled firmwares are uploaded and I’ve made a small update to the emoncms serial config module. Just need to update the documentation now.

rupert · 2024-05-17T12:48:58.125Z

Wow that was quick! Thanks for the update.

I think the inclusion of the information below

firmware = emon_CM_6CT_temperature
version = 1.6.0
hardware = emonTx4
voltage = 1phase
RF = on, rfBand = 433 MHz, rfGroup = 210, rfNode = 17, rfPower = 25, rfFormat = LowPowerLabs

in the serial start up will be really useful, especially during troubleshooting. When trying to help troubleshoot user’s problems on the forum, it is sometimes difficult to determine what hardware and firmware they are using. For example, what is thought to be an emonPi may turn out to be an emonBase!

In particular the rfFormat information will be useful as OEM transitions from Jeelib to LPL.

I wonder if this could be added to older products as and if / when new firmware is introduced for them?

TrystanLea · 2024-05-17T13:18:53.607Z

rupert:

Wow that was quick! Thanks for the update.

Thanks! yes good idea to introduce this on older firmware as and when they are updated.

Robert.Wall · 2024-05-17T14:08:24.215Z

rupert:

what is thought to be an emonPi may turn out to be an emonBase!

And worse, some users don’t know the two are different.

rupert:

In particular the rfFormat information will be useful as OEM transitions from Jeelib to LPL.

Allied to this, please can we have a readily accessible list of dates when the first of anything “new” (hardware or software) was shipped or otherwise became available – or for that matter became unavailable.
Given that, it would reduce the guessing game a bit more still - especially for the older items.

rupert · 2024-05-17T14:28:34.151Z

@Robert.Wall

The topic

Timeline of OEM devices? Getting Started

Hi! Would anyone be able to draft timeline of OEM devices and system configurations? I’m curious to understand how it has evolved, seems like emonPi was before emonTx4 but then emonPi2 was released last year? [image] // https://playground.diagram.codes/d/timeline width=800 "Nov 2023": "EmonVS + EmonPi2" "????": "EmonVS + EmonTx4 + EmonBase" "???": "???" "2016": "EmonPi?" Thanks

provides some good information on the hardware …

Robert.Wall · 2024-05-17T18:16:47.791Z

Yes, that’s only part of the story.

If you look, I wrote the first response to that topic.

RichardinCancale · 2024-05-18T09:14:30.620Z

Hi Trystan, For the pulse input I presume the period is in milliseconds? Can you indicate how one should use this value for a given pulse length - is it just the same value ? e.g. For my Linky meter the pulses are nice square 20ms duration, so value to enter is just 20? For the UK I guess the default is 100ms? Thanks

Robert.Wall · 2024-05-18T13:01:48.591Z

RichardinCancale:

For the pulse input I presume the period is in milliseconds? Can you indicate how one should use this value for a given pulse length - is it just the same value ?

Do you mean the pulse minimum period in EmonLibDB_setPulseMinPeriod(uint8_t channel, uint16_t _period, [uint8_t _edge=FALLING]) ?

In short, NO! The full explanation of how the library uses the pulse minimum period value is in the emonLibCM or emonLibDB documentation (look at the library that your sketch uses). If you have an “electronic” output, which will of course not suffer contact bounce, you should use ZERO for the period.

rupert · 2024-05-18T13:59:27.524Z

Yes - thank you for adding your knowledge.

Robert.Wall:

Allied to this, please can we have a readily accessible list of dates when the first of anything “new” (hardware or software) was shipped or otherwise became available – or for that matter became unavailable.

I think that producing a detailed OEM hardware and firmware/software history may require quite a lot of research. The topic mentioned could provide an initial framework, then a detailed search of the openenergymonitor github site and the forums can be used to fill in some details. This would probably need someone with a better knowledge of github than I have! And a lot of detail will still be missing unfortunately, for example obsoletion dates, which may require searching the forums.

For example, for the emonTx3 hardware, the openenergymonitor/emontx3/hardware repository lists seven different versions with rough dates, but I think(?) only V3.2.x and 3.4.x were shipped.

For the firmware, openenergymonitor/emontx3/releases lists 10 versions with dates, but again I don’t know which versions were ‘shipped’.

Then all the present and past OEM products would need to be looked at …

So I think the OEM hardware and firmware/software history might need a volunteer OEM Historian!

RichardinCancale · 2024-05-18T16:53:30.075Z

Hi Robert - I was referring to the post by Trystan of the new functionality in the Serial Config Monitor where there’s a parameter called Pulse Period. Surely related but not sure it’s the same thing.

Robert.Wall · 2024-05-18T18:24:42.314Z

Without tracing through the sketch you’re using and emonCMS, I don’t know, but I think it’s a reasonable assumption and he’s shortened the name for brevity - but in the process made it less clear what it is.

The original algorithm didn’t always work as required, so emonLibCM was changed in August 2018 to the present definition: as implied by the name, it is the minimum period that a stable pulse must exist in order to be counted. Its purpose, as I alluded to above, is to prevent contact bounce being counted as separate pulses - which does happen with any sort of mechanical switch, reed relays included.

The library treats a period of zero as a special case and disables the timers completely, so if you have a ‘bounce-free’ output - e.g. from the optical sensor or a transistor or opto-isolator in a meter, then you should set the period to zero and it will count on the transition of either the leading or trailing edge of the pulse, (almost) irrespective of the pulse duration, according to how you set it up with the API call.

Robert.Wall · 2024-05-18T18:33:23.628Z

rupert:

I think that producing a detailed OEM hardware and firmware/software history may require quite a lot of research.

Yes, I appreciate this, but it’s a one-off effort. The alternative is, each time there’s a query that necessitates knowing which version of hardware or software is in use, a small but often non-trivial set of information has to be tracked down and searched to find the relevant bit(s).

It was some time after I joined OEM that I managed to persuade people to include version numbers and dates in the ‘standard’ sketches - something that’s common in industry.

glyn.hudson · 2024-08-21T22:51:22.905Z