EmonTxV3 Continuous Monitoring Firmware (v1.0-beta)

Dave, as a new user, it might be worth you updating the readme.md file to expalin what is needed when starting from scratch. It is often difficult for those using it all the time to know what is needed for new users.

Yes, that sounds sensible. I’ll be happy to do that once I actually get it to compile!


6 posts were split to a new topic: 3-phase in Austria

Hi Dave,

I have the same issue, did you get to the bottom of it?

Best Regards


Not yet. I believe we’re waiting for @Robert.Wall to update emonCM lib.

Ah OK, Thankyou!

edit, thanks to your hint, i now have this compiling. the 2 problems were i was using version 1 continuos sampling, not version 2.got it here.EmonLibCM - Version 2.2.1 (Released 30/10/2021)

The compiler was also using the wrong one wire librarys.

Hope this helps!

Best Regards,


Hi trystan,

After I uploaded the sketch, I loaded default calibration to eeprom (entering config mode) but sketch does not detect any power consumption.
> Calibration:
> vCal = 268.97
> i1Cal = 90.90
> i1Lead = 4.20
> i2Cal = 90.90
> i2Lead = 4.20
> i3Cal = 90.90
> i3Lead = 4.20
> i4Cal = 16.67
> i4Lead = 1.00
> Temperature Sensors found = 0 of 1
> Temperature measurement is NOT enabled.
values printed:

CT1 detected, i1Cal:90.90
AC missing

Is something I’ve missed?

Note: with sketch emonTxV3.4 Discrete Sampling it does show values of consumption:

That’s your problem. You can’t calculate power without knowing the voltage.

Trystan’s sketch (or more precisely, the version I’m looking at) doesn’t allow the possibility of using a nominal assumed voltage to show an estimate of apparent power, which might be what your DS sketch is doing.

(Should I be guessing that your emonTx is running on battery power? If so, you cannot expect the battery to last very long using the CM sketch, because - like the name suggests - it’s working continuously, not for just 200 ms every 10 s as the DS sketch does.)

It seems to me that the EU voltage adapter calibration value is missing from the sketch. Is it the same as for the non-CM version, maybe?

The CM library default calibration constants are as detailed in the accompanying documentation.

The nominal calibration values are the same, because the hardware is the same.

The sketch can override those starting values, if necessary. I didn’t create that sketch, I’m not sure what the values incorporated in it are. I believe it does include the on-line serial calibration, but not all the possible variables are catered for.

As they don’t fit my needs, I asked for clarification. The non-CM version shows the 3 nominal values for UK, EU and US.

Thanks, that actually answers my question.

One more thing I was wondering about this beta sketch which I am now pondering to use instead of the regular discrete sampling one. There are lines in it similar to the following:

if (analogRead(1) > 0) {CT1 = 1; CT_count++;} else CT1=0; // check to see if CT is connected to CT1 input, if so enable that channel

How does it reliably detect that there are CTs connected? I had the impression that the inputs are aligned to the center of the power rail using a resistor divider, so in effect the readout should be around 512, in other words, never zero. I admit I haven’t tested it yet as my EmonTX has its normal daily duty that I don’t want to interrupt (yet).

Look at the circuit diagram!

The socket has two “inner” connections that make contact with the tip and ring contacts only when a plug is not inserted. One of these is grounded, so when no plug is present (note: not quite the same as no c.t. is present), there’s a solid 0 V input to the ADC. It is that which is detected.

Those lines in the sketch are rather pointless anyway, in my opinion there’s no real need to disable scanning of unused channels - even when simultaneously handling 4 c.t’s, it runs at 1923 samples per channel per second, compared to about 2600 for the DS library. That’s only about 30% less samples per second than the DS library measuring just one c.t. And in any case, the library checks on every sample to see if the input is grounded, and if so, doesn’t process that channel, though this doesn’t affect the sample rate.

(1900 samples per second equates to the 19th harmonic of 50 Hz mains, and there should be very little energy at that frequency, according to the rules for harmonic injection into the supply.)

Indeed, I haven’t done my homework this time, sorry.

It’s cosmetic, I think. Having inputs in the system doing nothing and always showing zero (that also should have been a hint for me), pushing excess messages around the system just creates clutter.

Indeed - the “fixed in stone” data packet that always includes all powers, 6 temperature measurements and a pulse count is an example. I can see that this approach should work for everybody, but in the olden days before OEM became “plug and play”, everybody customised everything to their own needs - and it seemed to work.

For some reason I missed that you had updated the EmonLibCM library @Robert.Wall. I’ve now updated the version on github and the EmonTxV3 firmware above is now working great! Thanks a lot @Robert.Wall for your work on the update.

Should be ready for you to test now @djh @electrojim unless you beat me to it?

Note: I had to update my copy of the OneWire library as it have an error about a missing onewire.begin function

1 Like

Hi @TrystanLea, @bazscuba1 and I have both been running for a while, looks to be working well, even down to 0.5 seconds update rate for our crazy solar energy diversion/control projects.

Thanks for the heads up though!

Best regards,



Great to hear @James_Hill!

I’ve changed the default nodeid to 15 so that EmonTxCM units do not conflict with existing emonhub node decoders. change default node to 15 · openenergymonitor/[email protected] · GitHub

Running emonpi update on emonSD systems will also install the node decoder automatically on update.

Troubleshooting: If after uploading the latest firmware the node does not appear under the expected node 15 id, check that the nodeid has not been set manually in the EmonTx EEPROM, see +++ [enter] at startup.

I’m happy to announce that we are now shipping the EmonTxV3CM continuous monitoring firmware as the default firmware on EmonTx units from our shop.

I have updated the EmonTx product page here accordingly:
emonTx - Energy Monitor Transmitter - Shop | OpenEnergyMonitor

and added a note to the top of the discreet sampling firmware repository here:
emontx3/README.md at master · openenergymonitor/emontx3 · GitHub

If the 3x AA battery holder option is selected when ordering an EmonTx through the shop we upload the discreet firmware rather than the continuous monitoring firmware (which is not compatible with battery powered operation as the EmonTx does not go to sleep). I’ve added a note to the EmonTx product page to explain this.

Thankyou again to @Robert.Wall for all of your hard work on EmonLibCM.

1 Like