You can describe it as you wish, but I’ll stick to the facts. There was already a “serial output” format established prior to the emonESP format. That original “serial output” is still going strong on the emonPi and the RFM2Pi’s, it is also still an option on some emonTx FW’s (or maybe was until very recently, I haven’t looked for a while).
The decision to use a different serial output was made specifically to work seamlessly with the emonESP, therefore to differentiate between 2 serial outputs, one of which was specifically designed for the emonESP, would be to call that one the “emonESP” serial output format.
Only the emonESP understands that format, yes emonhub has a new(er) interfacer that can use the emonESP formatted serial output, but it ignores exactly 50% of the data passed as the labels are discarded. The “emonESP format” is peculiar to the emonESP in that any device that outputs data in that format could work with an emonESP, whilst no other device can truly interpret the output of an emonTx without modification of some degree.
Had I designed the “Tx3e” interfacer, it would have utilised the hardcoded labels provided by the emonTx to pass on user defined labels in place of the hardcoded label by cross referencing them, scales and units could be applied if desired too.
In fact, way back when the emonESP FW was being written and the emonTx FW modified to suit, I specifically pleaded the case to include the node id at that time, but I was told “No, the emonESP doesn’t need it” so use with alternative devices was entirely off the menu at that time.
Yes it could, it’s been previously discussed in-depth to no avail. Although the easiest method would of course be to always include the node id and alter the emonESP FW to simply ignore it.
When this was discussed previously I floated the idea that a simple removable link on an unused emonESP IO pin could trigger a “switch on node id” serial request from the esp to the tx, but I would think this is more resource hungry than ignoring the node id when not needed and we also have the issue where many (all?) emonESP connectors (including the newer emonTx’s on-board “emonESP” dedicated connector) do not have the connection needed to write to the emonTx from the emonESP, so it would have to be an emonTX FW update or at least a USB serial and serial term settable option rather than a simple “auto” option.
Well yes and no. In many instances that could work, it is indeed how I first used to connect 3 emonTx’s to a Pi for a 3ph monitor, but it is also the reason I had to look for a better solution (ie udev rules) because if you disconnect any one of the emonTx’s from the Pi, it will be assigned a new address. eg using /dev/ttyUSB{0,1,2} remove /dev/ttyUSB1 and reconnect it, you now have /dev/ttyUSB{0,2,3}. So only 2 emonTx’s work until you reboot the Pi.
You also may need 3 or more node id’s from a device that only has a switch to provide a choice of 2 node ids, so even that makes any “out of the box solution” harder. Especially with backward compatibility.
Using FTDI adaptors which come with unique id’s (genuine ones do, copies have repeated ids but good copies allow you to over write the id, as do genuine), with udev rules in play every emonTx (or other device connected via an FTDI) using either the original or emonESP serial formats can be uniquely addressed regardless of how many devices are connected and/or how many times it is unplugged and reconnected.
I’m sure someone will throw something together, but this will always be a bit of a hack, trying to get emonHub working with something exclusively designed for the emonESP with no regard for other devices, will never be perfect, a wider view needs to be taken when making these big decisions.
BTW, it is not the “serial interfacer” we are discussing, it is the “Tx3e” interfacer, so called as only the emonTx v3.4 with FW > V?.? uses the “emonESP serial format”. The “serial” interfacer does use node id, or not, as decided by the user/device. It uses all the data passed from a serially connected device using a simple space separated list of values, this being the basis on which the “Jee” interfacer is built and it works just as you (Brian) mention with a simple “node id pass through” so multiple devices can connect in any order, this did/(does?) work flawlessly “out of the box” (except for when devices get unplugged) and is(was?) also sometimes referred to as the “serial-direct” method of connecting when used specifically via the GPIO (something you are now familiar with), but it works exactly the same via a usb adapter (and yes as you know, you can indeed physically connect “serial-directly” whilst using the “emonESP output” into an “Tx3e” interfacer, as has become the norm since the emonESP launched and the emonTx FW changed to accommodate it)
IIRC @Robert.Wall’s 3ph sketch for the emonTx still has the ability to be complied with the “original serial output” option set, and three (or more) of those could easily be connected to emonHub using the “serial” interfacer, and IIRC it also has the ability to have an “emonESP” output selected, but sadly only one of those should be connected due to the potential addressing issue.
A very long post I know, but it is better that you are armed with all the details when working towards a fix. Hasty localised fixes is how we got here.