Hi all, can anyone point me in the right direction for a guide to use 3No. EmonTX units with a EmonBASE unit. I am already using 2No. units in a number of setups but would like to use 3No. EmonTX’s in a particular install.
Ryan
Do you mean a quantity of three?
If yes, it’s no different to 2, except that you must edit the sketch or use the on-line calibration to allocate an appropriate NodeID (one you’re not already using). You then need to edit emonhub.conf to delete the existing description for the NodeID you’ve chosen, and replace it with a copy of that for Node15 - changing the NodeID itself of course.
Is there a practical limit to the number of emonTx that can be used within a domestic install? I may need 4-5 emonTx’s to monitor heavier appliances in different rooms (likely back to emonPI).
I see there’s room for three in emonCMS but wasn’t sure if more could be added.
Newbee here, I did search but apologies if I missed in an earlier thread. Thanks.
There was a thread recently that pointed to a potential issue with RFM clashes. The user had 3 EmonTX IIRC.
Funnily enough. I encountered this exact issue yesterday. I have built 4 x emonTx into an enclosure all powered from the same power strip. If you power them on simultaneously they clash. In the thread mentioned above there was a comment:
One relatively simple firmware change that could reduce the change of collisions for multiple EmonTx units would be to include a small randomised delay at initial startup, so that after power cuts where all units come on at the same time, they start transmitting at slightly different times.
As I have compiled the 3phase script already to build these units, perhaps someone might suggest a code patch to achieve this? Or is there something they could be scripted to do at at startup that would cause a delay?
I was able to work around the issue by plugging in each unit sequentially, but a power cut would cause the units to fail.
1 Like
It’s a bad idea to have antennas so close to each other in any case, you must not expect the best performance.
What I suggest is a delay of 20 ms per NodeID number somewhere in the startup procedure. I’ve put this in the next update for your sketch, just before it sets up the ADC near the end of setup( ):
delay(nodeID * 20);
The longest message we use is transmitted in less than 20 ms, so that gives the Base a little time to process the message before the next is transmitted. It is by no means guaranteed, because they will drift over time and come together again at some point, but it should help when you first power everything up at the same instant.
As you mention that you have a 3-phase installation, you would probably get better accuracy by running the standard single-phase sketch on 3 emonTx’s and dedicating one emonTx to each phase - that way you measure and use the actual voltage for the phase, rather than assuming the 3 phase voltages track each other.
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.