EmonTX v3 packets not being decoded on fresh EmonCMS SD install

I’m wiping and re-deploying an old RaspberryPi EmonBASE with a fresh emonSD 2021 Jul 21 image. While my EmonTH sensors were discovered just fine, my equally old EmonTX v3 (circa 2015), currently with just a temp sensor attached and no CT sensors, is failing to be decoded with:

2022-07-18 00:38:20,436 DEBUG    RFM2Pi     160 NEW FRAME : OK 10 0 0 0 0 0 0 0 0 14 45 193 0 0 0 0 0 0 0 0 0 0 0 0 0 (-44)
2022-07-18 00:38:20,437 WARNING  RFM2Pi     160 RX data length: 24 is not valid for datacodes ['h', 'h', 'h', 'h', 'h', 'h', 'h', 'h', 'h', 'h', 'h', 'L']

My emonhub.conf for this node ID is stock and looks like:

[[10]]
    nodename = emontx1
    [[[rx]]]
       names = power1, power2, power3, power4, vrms, temp1, temp2, temp3, temp4, temp5, temp6, pulse
       datacodes = h,h,h,h,h,h,h,h,h,h,h,L
       scales = 1,1,1,1,0.01,0.01,0.01,0.01,0.01,0.01,0.01,1
       units = W,W,W,W,V,C,C,C,C,C,C,p

Any assistance in troubleshooting and getting this system back in operation would be much appreciated!

My crib sheet says your emonTx V3.4 sends 24 bytes (and your emonHub agrees!) and the data is:

int power1,
power2,
power3,
power4,
Vrms,
temp[MaxOnewire];
unsigned long pulseCount;

There are 5 temperatures, so all you need to do is remove temp6 and the corresponding h, 0.01 & C in “names”, “datacodes”, “scales”, & “units” in the config.

[Explanation: an “int” is 2 bytes - code h, a long is 4 bytes, code L. “names”, “datacodes”, “scales”, & “units” match 1:1 left - right.

1 Like

Ah ha! That did it. Thanks for the super speedy response, Robert!

Was this a problem as my sketch for the EmonTX is so old? If I had been running a more current sketch, would this have worked out of the box? I’ve missed a number of developments in the space and see the CM versions. That looks quite interesting!

Basically, yes.

Whilst we try to maintain backwards compatibility, sometimes the crystal ball fails and it’s desirable to increase the capabilities, which means we run out of NodeIDs to differentiate between versions, then this happens. That’s ultimately why I compiled a spreadsheet giving all the sketch versions for everything I could find, along with the size of the payload and its components. So knowing it was an emonTx sending 24 bytes, the answer was very quick to find.

It shouldn’t be necessary to swap to the CM version unless you have rapidly switching loads (like an induction hob or a Solar diverter), but it does work more like your meter than the discrete sample version.

1 Like