Community
OpenEnergyMonitor

Community

New emonTX generating a 40-bytes length data frame

Tags: #<Tag:0x00007f78e5ade8b8>

I have search your forums and google without finding reference to a 40 length data frame so I was hoping to get help here.
I have just purchased 7 new emonTx units and two basePis to talk to. This is the fourth set of these and in the past the input frames were discovered and populated automatically as the instruction say. This new set are generating an invalid dataset:

2019-12-05 20:26:19,209 DEBUG    RFM2Pi     3588 NEW FRAME : OK 22 1 85 85 85 247 127 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85 101 32 101 32 101 32 84 85 85 85 (-27)

Generating the error:

2019-12-05 20:26:19,211 WARNING  RFM2Pi     3588 RX data length: 40 is not valid for datacodes ['h', 'h', 'h', 'h', 'h', 'h', 'h', 'h', 'h', 'h', 'h', 'L']

I can get data to save to an input by setting datacode=h but the data is of no use. The output for the CTs is numerical value of 20000 to 30000 and does not vary based on load. The unit behaves the same whether powered by AC or DC. If someone has seen this before and can clue me in I would be forever grateful.

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: https://github.com/openenergymonitor/EmonTxV3CM

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).

Thanks for the quick solution. I love your stuff. I got confused about the because I re-ID’d these nodes as soon as I got them so I hadn’t noticed if the new firmware was defaulting to 15. I also got units with the onboard battery pack so I didn’t believe I was running the constant sampling version, as noted in documentation.
I have edited emonHub and the data formatting look good. But I still am not getting any change in value on load. I have three setup for testing attached to a series of laundry room dryers and I am reading 0s on P1-4 and E1-4 whether the dryer are running on not. I reused the CTs from a previous installation of your emonTX units from 2014. That can’t be an issue can it?

Hi Mat,

By chance did you plug in your CTs after you powered on your emonTx?
If so, power it off, then on again.

The Tx recognizes CTs only at power-up.
If they’re connected after power is applied, it won’t harm anything, but the Tx won’t “know”
any CTs have been attached to it.

No. I attached the CTs before power up. I have also gone over there and cycled each device just to be sure.

But it sounds as if you still have a problem.

A stupid question, hopefully, especially as you’ve used an emonTx before: Are you measuring the correct wire? A single core, not both “hot” legs of the supply - I assume it’s a 240 V drier?

And you are using the a.c. adapter? Because no voltage = no power = no energy
Batteries won’t last long when you’re running the processor nearly flat out continuously.

Have you looked at the serial output of the emonTx using the Arduino IDE?

Do you have two blocks in emonhub.conf for the same NodeID? That’s wrong if you do (but I can’t recall off hand which takes precedence).

I have flashed them back to discrete sampling v3.2 and they appear to be working. I did notice that if I powered them up with the AC adapter I could get data on the CTs when running the continuing monitoring sketch but when powered via USB, I got no data. You were out of stock on the AC version of the emonTX when I ordered so I only have 4 power supplies for the 7 units. Hence the need for powering them via USB. All of the units can with the battery pack for the record.

Actually, you were getting the data, and it was correct! It was reading the voltage as zero because it had no a.c. voltage input to measure, therefore the power was zero.

If all are relatively close, and you have the standard US split-phase supply, you can still power the emonTx’s via USB and feed them all with a voltage for measurement from a single a.c. adapter, provided that all are connected exactly the same way (all barrels connected together and all inners connected together). Unfortunately, powering all from one a.c. adapter will put a large dent in the waveform and spoil the accuracy of the voltage measurement.

Is this a typo?

Sorry. Yes it was a typo. Should have read “Came with the battery pack”.
Thanks for all the help. I think my issues have all been related to the new image and the changes it brought to the output. I am happy running the discrete sampling sketch since it makes integration with the other 11 units easier.
Thanks again.