emonTx4, emonPi2, emonTx5 14th May 2024 firmware release

[rupert]

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 (Richard)]

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]

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]

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