Using 3 No. EmonTX with EmonBase

Hardware emonTx
24

Just playing around with this to try and get udev rules straight. Maybe @pb66 can assist?

running lsusb I get:
Bus 001 Device 004: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)

So I built the following udev rule:
SUBSYSTEMS==“usb”, ATTRS{idProduct}==“6015”, ATTRS{idVendor}==“0403”, SYMLINK+=“emonTX-$attr{serial}”

But when udev runs is generates the following symbolic link:
lrwxrwxrwx 1 root root 9 Feb 14 18:33 /dev/emonTX-FT43UER9 → gpiochip2

Shouldn’t this be linking to a ttyUSBX device?

25

Try swapping out SUBSYSTEMS==“usb” for SUBSYSTEM==“tty” (note the singular “SUBSYSTEM” not plural) and activate using

sudo udevadm control --reload-rules && sudo udevadm trigger
1 Like
26

Worked. Ta. Will need to get a couple more emonTxs to test multiples, but happy this gives clean serial connection option without random tty devices spoiling the party.

Does this now mean a separate Interfacers section for each tty device? This is what I am currently using and the data appears on NodeID=1. I don’t get the nodeoffset setting. How to you bind the tty device to a particular NodeID?

[[SerialTx3e]]
     Type = EmonHubTx3eInterfacer
      [[[init_settings]]]
           com_port= /dev/emonTX-FT43UER9
           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,

I would like to power the emonTx through serial header by removing JP2. It would be easier to use a common AC Voltage reference and power the Txs via USB from the pi. Just need to ensure there is adequate power supply to the pi.

27

Yup.

Originally nodeoffset was just that, if a user had (for example) multiple rfm networks, each reporting to a different emonhub, then on to a single emoncms. nodes 1-30 could be “offset” by adding (say) a nodeoffset of 32 so that the second network of 1-30 reported as nodes 33-62 and didn’t clash with the first network.

For reasons I won’t go into again here, the emonTx using (emonESP format) serial output doesn’t send a node id and that’s why we’re having to do all this with udev and ftdi serial numbers. So when the emonhub interfacer was written for that emonESP format serial output with no node id (aka node id is None) we could use the nodeoffset to add a “offset” to that absent node id ie your node is currently 0 offset by 1 = 1. So using nodeoffset is how you define the node id for each emonTx using the (emonesp format) serial output.

Yes that would be the norm rather than an ac for each emonTx providing they are all on the same phase. The emonTx draws so little current it should not be difficult to cope with the additional load of the emonTx’s. The Pi will dwarf the emonTx’s consumption.

1 Like
28

@AntiGrav - did you edit this on all three Sketches (1 for each emonTx) or just on one of the sketches?

29

You would need to do this on all additional emonTx devices you want to power on together. You could leave one with default if you liked, as the others would all have a different start delay.

1 Like