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!
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.
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.
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.
@Robert.Wall@rupert@awjlogan would one of you be able to tell me how to flash new firmware to a TX4 when the serial config tool/emoncms is not available.
I am just connecting via USB to the TX4 from a Pi.
git clone https://github.com/openenergymonitor/EmonScripts
./EmonScripts/emonupload2.py
Traceback (most recent call last):
File "/home/pi/./EmonScripts/emonupload2.py", line 13, in <module>
with open("firmware_available.json") as jsonFile:
~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: 'firmware_available.json'
As an ex - mainly hardware engineer, itās getting beyond my pay grade now! Perhaps the stuff you need need isnāt on git hub or isnāt where the docs say it should be?
I have never used a Pi, only a laptop with the Arduino IDE plus DxCore installed.
All you need then is a USB lead, download the two ā.inoā files, compile and upload. No other scripts or tools required. And you donāt need Git to download the files (just copy the ārawā version).
