thanks @borbin that’s helpful. I’ll scrap this idea then and look into a different method.
Perhaps combination of Sonoff-MQTT meters for large appliances and Modbus/CT’s to cover several circuits in the CU.
Thanks for that Robert. Will see if I can build a new version of Firmware with this line added.
I was just waiting for the “You don’t wanna do that” comment about the antennas 
. I have externally mounted aerials that I will space at least a wavelength apart. As you can see from the photo, the lid wouldn’t go on the enclosure with those poking out.
I don’t have voltage references for the other phases, so dedicating a Tx for each phase would involve getting an electrician to install new sockets on the two other phases. We had this conversation in a previous thread.
If you recall, I mounted three Tx’s in an enclosure and utilised a common voltage reference and separate 5V DC power. That installation used WiFi boards so avoided the RF issue. It’s all working well monitoring 10 circuits.
I’ve used the TP-Link KP115 Energy Monitoring smartplug with Node-Red feeding into emonCMS over MQTT for picking up loads from domestic appliances.
There is a Node-Red contribution that links directly to the Kasa API for reading meter info
oh wow, i’m all those TP Link devices. More inclined to trust TP-Link with higher loads too. I’ve ordered one and very intrigued by your Node-red implementation @AntiGrav , i will need to get my head around this over the next couple of weeks. Ta
Oh, c’mon. I read almost EVERY post that appears - you can’t expect me to remember even most of them. 
1 Like
To avoid the conflict on RF transmission, I edited the script for the firmware as per Robert’s sugestion above:
The addition of a delay factored by nodeID did not work. On closer inspection I noticed the variable nextTransmitTime is initialised earlier in setup() so maybe this was going to be the same for all nodes?
I modified this line from:
nextTransmitTime=millis()
to:
nextTransmitTime=millis() + (nodeID * 100);
I initially tried a 20ms increment, but this only worked for Nodes 11 and 14, so that could mean a separation of at least 60ms is required? I have a congested antenna array, so there may be better performance when these are separated…
Can anyone see anything wrong with this? The 4 x emonTxs powered up at the same time now no longer get into a deadlock with this modification.
Sorry - I forgot I’d moved that as well.
It doesn’t matter what the time between nodes is, as long as the last one does not catch the first on its second transmission. I didn’t have even 2 emonTx’s available, and so I hadn’t been able to test it. It should not take 40 ms to process the data once it’s received.
OK. I get it. Thanks for your help on this 
.
What I think was happening was that introducing the setup delay meant the first transmission worked, but because nextTransmissionTime was set to approximately the same value for all transmitters, they then immediately got into conflict.
I have initialised nextTransmissionTime in setup() with a one second delay between each of the four emonTxs. As the loop time between transmissions is five seconds, this should give them maximum separation.
Would another possible solution to multiple emonTx devices collocated with an emonPi be to use a USB hub and wiring a USB to serial UART programmer into the header on the board used by the WiFi module on each emonTx?
The Node config for emonHub would need to recognise the /dev/ttyUSBXX devices, but it may avoid all this wireless shenanigans for when they are in the same enclosure?
Absolutely yes!
I was reading through the tail end of this thread thinking “why?” and assumed this design decision had already been discarded earlier in the thread perhaps. Without a shadow of a doubt the best solution for multiple emonT’x in a box (or just clustered) is to use USB adapters to a Pi, not necessarily an emonPi, just a Pi b+ (needs a wifi dongle), Pi zero W (needs a USB hub) or Pi3 has everything you need but generates more heat if it’s going in a closed box (Pi 4 is a no no for putting in a box).
Easily done, if you search the forum I have repeated explained about using specifically “FTDI” usb adapters that have an onboard eeprom so it has a unique id. Users no longer have to source these themselves via ebay etc as the OEM shop now stocks “FTDI” usb adapters.
@Robert.Wall has documented much about the use of these
https://learn.openenergymonitor.org/electricity-monitoring/programmers/ftdi-programmer
although I’m not sure he has covered the eeprom utility or creating udev rules (yet?)
Alternatively, just edit the sketches to print a leading node id using the older space separated values payload format (which I believe Robert has optioned in the current CM sketch?) then it doesn’t matter which order they get addressed “/dev/ttyUSBXX” as long as you do not remove and reconnect any whilst running as they may get assigned a different higher address on reconnection.
I can perhaps help out there?
Yes please.
It was done in a rush over Christmas because the Shop was sending them out and there was no supporting information, other than “go to the FTDI Website”, and the pages in ‘Learn’ were still giving the details for downloading the wrong driver.
That’s in there - for Linux users. I don’t know if that or its equivalent exists in a Mac and Windows.
The first install we did, the emonPi was remote to the Tx ‘cluster’, and we used WiFi boards to connect them to the network. It was going to be the same for this one, with the Pi on the other side of a plant room and use of RF, but it has ended up they are now adjacent (if not in the same enclosure).
I have a couple of the FTDI programmers, but unfortunately am installing the monitoring on site tomorrow. Would like to see progress on this USB option and am willing to assist with testing if necessary.
I am familiar with setting up udev rules as I had to to it with video4linux cards to assign fixed dev names for use by TV tuners. Once you can set and identify a unique pattern to match against, it is relatively simple and gets around the ambiguous device paths.
This will be a nice option for future installs. Thanks again, for all the assistance. We live and learn 
Mine was the recent post with 3 emonTx’s clashing over RF. Proved this by power cycling them with a 1 second delay between them and all is good. I’ve now updated the firmware code with the delay change although I need to check the “next transmit time” mentioned here.
I’ve not seen any problems with drifting yet, but will likely move the pi nearby and switch to usb in due course.
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?
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
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.
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
@AntiGrav - did you edit this on all three Sketches (1 for each emonTx) or just on one of the sketches?
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