Multiple emonTX Serial connections

How do I configure 3 EMONTX to work with Serial?
I have 3 EMONTX

one is working

    [[SerialTx3e]]
         Type = EmonHubTx3eInterfacer
          [[[init_settings]]]
               # Un-comment line below if using RS485 adapter
               #com_port = /dev/ttyRS485-0
               # default com port if using USB to UART adapter
               com_port= /dev/ttyUSB0
               com_baud = 115200
          [[[runtimesettings]]]
               #nodeoffset = 1
               # nodeoffet can be used for multiple devices. it will change the nodeID as seen by emonCMS Inputs.
               pubchannels = ToEmonCMS,
              nodeoffset = 15

how to add /dev/ttyUSB1 and 2

I work on the premise that you have 3 USB TTL connectors.

Are these recent purchases?

Simply copy the settings, change the interfacer name, com_port and node offset. I use a nodename as well. This should work (never tried it though).

[[SerialTx0]]
     Type = EmonHubTx3eInterfacer
      [[[init_settings]]]
           com_port= /dev/ttyUSB0
           com_baud = 115200
      [[[runtimesettings]]]
           pubchannels = ToEmonCMS,

           nodeoffset = 0
           nodename = Serial_0

[[SerialTx1]]
     Type = EmonHubTx3eInterfacer
      [[[init_settings]]]
           com_port= /dev/ttyUSB1
           com_baud = 115200
      [[[runtimesettings]]]
           pubchannels = ToEmonCMS,

           nodeoffset = 1
           nodename = Serial_1

I think the nodename will only work if you are sending via MQTT. There are some changes proposed for the MQTT interfacer (which I am running), but I think this will work regardless.

If you are sending via the HTTP interfacer, you will need a different ‘nodeid’ setting I think.

This worked

[[SerialTx0]]
     Type = EmonHubTx3eInterfacer
      [[[init_settings]]]
           # Un-comment line below if using RS485 adapter
           #com_port = /dev/ttyRS485-0
           # default com port if using USB to UART adapter
           com_port= /dev/ttyUSB0
           com_baud = 115200
      [[[runtimesettings]]]
           #nodeoffset = 1
           # nodeoffet can be used for multiple devices. it will change the nodeID as seen by emonCMS Inputs.
           pubchannels = ToEmonCMS,
          nodeoffset = 15
[[SerialTx1]]
     Type = EmonHubTx3eInterfacer
      [[[init_settings]]]
           # Un-comment line below if using RS485 adapter
           #com_port = /dev/ttyRS485-0
           # default com port if using USB to UART adapter
           com_port= /dev/ttyUSB1
           com_baud = 115200
      [[[runtimesettings]]]
           #nodeoffset = 1
           # nodeoffet can be used for multiple devices. it will change the nodeID as seen by emonCMS Inputs.
           pubchannels = ToEmonCMS,
          nodeoffset = 16
[[SerialTx2]]
     Type = EmonHubTx3eInterfacer
      [[[init_settings]]]
           # Un-comment line below if using RS485 adapter
           #com_port = /dev/ttyRS485-0
           # default com port if using USB to UART adapter
           com_port= /dev/ttyUSB2
           com_baud = 115200
      [[[runtimesettings]]]
           #nodeoffset = 1
           # nodeoffet can be used for multiple devices. it will change the nodeID as seen by emonCMS Inputs.
           pubchannels = ToEmonCMS,
          nodeoffset = 17


[[15]]
    nodename = emontx3cm15
    [[[rx]]]
       names = MSG, Vrms, power1, power2, power3, power4
       #datacodes = L,h,h,h,h,h
       scales = 0,1,1,1,1,1
       units = n,V,W,W,W,W
       #whitening = 1

[[16]]
  nodename = emontx3cm16
    [[[rx]]]
       names = MSG, Vrms, power1, power2, power3, power4
       #datacodes = L,h,h,h,h,h
       scales = 0,1,1,1,1,1
       units = n,V,W,W,W,W
       #whitening = 1

[[17]]
  nodename = emontx3cm17
    [[[rx]]]
       names = MSG, Vrms, power1, power2, power3, power4
       #datacodes = L,h,h,h,h,h
       scales = 0,1,1,1,1,1
       units = n,V,W,W,W,W
       #whitening = 1

Thanks

1 Like

Indeed it would, HOWEVER!

Be aware that the /dev/ttyUSB* addresses are dynamically issued at boot up or as each device is connected/comes online, so there are no guarantees that the 3 devices will always use the same node id’s, it very much depends on who gets what address first.

The “problem” here is that because the emonESP output format is aimed solely at a close coupled emonESP that recieves input from that one emontx only, there is no node id passed in the frame of data.

You have 3 options

  1. Cross your fingers and hope that the devices always get allocated the same address.

  2. Change the emonTx FW’s to send a node id, using the original “serial-direct” space seperated values output eg nodeid val1 val2 val3 etc and use the original serial interfacer not the Tx3e interfacer in emonhub.

  3. Use serial to USB adaptors that can have a unique id set so that the emonBase can identify the device and allocate it the correct address regardless of connection/boot order.

I always opt for FTDI usb serial adaptors that have a programmable eeprom and udev rules to match so my emonTx’s are not addressed as /dev/ttyUSB* but as /dev/emonTx* instead.

Some further reading if you are interested

There is actually another method a “3a” if you like, where you use usb serial devices from 3 different vendors and use the vendor:product id’s and udev rules, Bill explain’s how in this thread

1 Like

I’d describe it as the serial data output as it is not just for the emonESP.

@Robert.Wall & Paul, Could a feature be added to (optionally, disabled by default) include the NodeID in the serial output?

There would, I think, need to be a bit of work on the emonhub side for the serial interfacer to use that in preference to anything else set. This would mean the physical USB port assigned would not matter.

Yes, but how would you like to switch it - preprocessor directive or by the serial input?

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.

Clarifying the point about the 3-phase PLL sketch:

There are four output modes.

1. RFM69CW - this is via the ISM band radio. It is out of scope for this discussion, I mention it only to avoid any misunderstanding.

2. SERIALPRINT - is a space-separated list of values, somewhat ‘human-friendly’, of voltage, currents, powers, frequency, power factors, pulse count and PLL status to aid commissioning. “DEBUGGING” adds some internal values that need not normally concern the user.

3. SERIALOUT - specified for “a wired serial connection”. The format is

<nodeID> <decimalValue1> <decimalValue2> <decimalValue3> [etc] <decimalValueN><newline>

(The numbers are integers.)

4. EMONESP - specified for an ESP WiFi module. The format is

<varName1>:<decimalValue1>,<varName2>:<decimalValue2>,<varName3>:<decimalValue3>,[etc]<varNameN>:<decimalValueN>,<newline>

Note there are no spaces between any of the elements. The numbers can be integers or floats.

Only one mode may be active at any time, with the exception that SERIALPRINT (with DEBUGGING) is permitted when the radio output is selected.