Yes. As you have no other Emon devices (correct?) then take a look in your emonhub.conf file and see if you have anything for an emonTx3. If you have 3 or more definition blocks with different Node IDs, then you use the third for your 3rd emonTx V3. If you haven’t, you will need to copy the existing block for the emonTx V3 and give it an unique Node ID - probably by deleting the block for something you don’t have and ‘stealing’ the ID. If you can connect a serial terminal program on your Mac either directly to the emonTx V3 or via the emonPi, then you can change the Node ID of the third emonTx V3 in EEPROM, and save it. The instructions are here: Configuration — OpenEnergyMonitor 0.0.1 documentation
I warned you that there had been changes - I think I read that someone else found this didn’t work.
I think I’ve answered this above before I read this far. As I wrote the EEPROM library, it will remain in EEPROM while you load “consistent” sketches, i.e. with identical use of the EEPROM. If you load a skech that uses it differently, it is erased. Again, all this might have been changed.
Don’t you mean the 5 V d.c? You only need the a.c. adapter on the emonPi if you are measuring power with it. If you’re not using one or both c.t’s, you don’t need it.
Do you mean the time between new values appearing in emonCMS. This can be set either in the sketch, or via the serial interface (if can be got working). If your sketch is this one https://github.com/openenergymonitor/emontx3/tree/master/firmware/emonTx34/emonTx34_CM
then you need to check that line 120 is:
float period = 9.85; // datalogging period - should be fractionally less than the PHPFINA database period in emonCMS
Looking at the changed code, it appears the “+++” unlock code has been disabled (but not removed) - you simply enter the commands. Unfortunately, without the ability to lock the serial input, it is possible to change the configuration and calibration by accident.
I can’t help you with Platfromio. It screwed my system up totally, so I refuse to have it on my machine.
This applies to pulse counting. Are you using the pulse input? If not, it does not affect you.
This is the voltage it uses to estimate apparent power when you don’t have the a.c. adapter.
Correct. The Node Definition is how emonHub knows how to convert a string of byte values
5 145 0 149 0 38 1 250 92 0 0 0 0 0 0 0 0 0 0 0 0 29 162 71 0 0 0 0 0 248 75 71 0 75 152 73 0
(those values are in decimal) into integers - 16 or 32-bit, signed or unsigned, to pass on to emonCMS.
You must have a valid Node ID definition for each (in your case) emonTx V3. There’s also one for the emonPi itself - Node 5.
Thank you 
“Whitening” is a kind of encoding that prevents a long string of zero values being transmitted when using JeeeLib (otherwise, the receiver loses lock and fails). It’s not needed with LPL, which encrypts the message and so avoids the problem in a different but similar way.
Is everything looking better now? If I’ve missed explaining any points, remind me - but I’m not likely to be able to answer for a couple of days.
