2

The way to solve your problem is to look at the sketch that is loaded into your emonTx’s. If you purchased them after 18th October, 2019, then they will have a sketch that uses the new Continuous Monitoring library: GitHub - openenergymonitor/EmonTxV3CM: EmonTxV3 Continuous Monitoring Firmware (Default shipped EmonTxV3 firmware)

If you look at the source file there, near the top you’ll find the entry that you must have in emonhub.conf to decode the message:

[[15]]
  nodename = EmonTxV3CM_15
  [[[rx]]]
    names = MSG, Vrms, P1, P2, P3, P4, E1, E2, E3, E4, T1, T2, T3, pulse
    datacodes = L,h,h,h,h,h,L,L,L,L,h,h,h,L
    scales = 1,0.01,1,1,1,1,1,1,1,1,0.01,0.01,0.01,1
    units = n,V,W,W,W,W,Wh,Wh,Wh,Wh,C,C,C,p
    whitening = 1

If you count the bytes in there, there are 40 so it seems very likely that this is what you have.
(Someone a little while ago was confused here: P=Power and E=Energy, T=Temperature)

Obviously, as you have 7 emonTx’s and all use the same radio frequency, you must give each one its own unique NodeID - that’s the [[15]] in this example, and you must change line 51:
byte nodeID = 15;
to suit in each emonTx and reload the sketch. (Actually, you only need to change 5, because all will probably be Node 15, 1 can remain and a second can be changed to Node 16 using the DIP switch. Don’t go past NodeID=30.
(And note, the comment at line 18 mentioning nodes 8 & 9 is wrong.)

In emonhub.conf, you must delete (or comment out) the “old” definitions for Nodes that you allocate to the emonTx’s that use the new sketch. You only need the NodeIDs in emonhub.conf that you allocate to that emonBase.

Note that the byte value 8510 is 0x55 - the data is XOR’d with this to avoid the difficulty where the radio receiver loses lock when a long bit string of zeros or of ones is received. The latest emonHub will recognise whitening = 1 and convert the data back again. This is enabled in the sketch by defining “RF_WHITENING” (the default is defined).