EmonTxV3 Continuous Monitoring Firmware (v1.0-beta)

I don’t really know what I’m doing but I’ve tried to follow the instructions above as far as the downloading. I then tried Verify

EmonLibCM-master/emonLibCM.cpp:44:21: fatal error: OneWire.h: No such file or directory

It seems I need a Onewire library. The Library Manager offers me v2.3.4 of a library called exactly that, so I presumed that’s what I need. But after adding it I see:

EmonLibCM-master/emonLibCM.cpp:45:159: fatal error: DallasTemperature.h: No such file or directory

So I suppose I need some other library?

edit: So I looked in the CM lib code and went to Dallas Temperature Control Library - Miles Burton - Innovative engineering for pretty much anything but that says to use github for download GitHub - milesburton/Arduino-Temperature-Control-Library: Arduino plug and go library for the Maxim (previously Dallas) DS18B20 (and similar) temperature ICs (and that has a version that was last updated 5 days ago) and to use a Onewire library from OneWire Arduino Library, connecting 1-wire devices (DS18S20, etc) to Teensy rather than the standard one, which in turn points to GitHub - PaulStoffregen/OneWire: Library for Dallas/Maxim 1-Wire Chips . That has a version of 2.3.4 set sometime last year and a latest update 19 days ago. So I’m even more concerned and confused now about what version of libraries I should be using?

Correct. You need both of them.

After you install the Onewire library via the Library Manager,
download the Temperature Control Library zip file from Miles Burton’s github page.
(You don’t need to unzip it)

https://github.com/milesburton/Arduino-Temperature-Control-Library/archive/master.zip

To install the library:

  • Start the Arduino IDE.
  • Pull down the Sketch menu
  • Select Include Library
  • From the sub-menu that pops up, select Add .ZIP Library
  • Select the zip file you downloaded

The Arduino IDE will need to be restarted in order to recognize the changes.

N.B. - the steps above are for the Arduino IDE running on Windows.

1 Like

FWIW, I didn’t need to restart the IDE; just including it from the menu seems to be enough. I’m on linux. I am a bit concerned about version control. I’ve essentially just got a random selection of versions.

So I’m not missing header files now, instead I get:

EmonTxV3CM/config.ino: In function ‘void getCalibration()’:
config:343:53: error: ‘EmonLibCM_ReCalibrate_VChannel’ was not declared in this scope
case 0 : EmonLibCM_ReCalibrate_VChannel(k2);
^
config:347:60: error: ‘EmonLibCM_ReCalibrate_IChannel’ was not declared in this scope
case 1 : EmonLibCM_ReCalibrate_IChannel(1, k2, k3);
^

1 Like

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!

2 Likes

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

James

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,

James

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
MSG:1,Vrms:2.01,P1:0,E1:0,T1:23.50,pulse:1
MSG:2,Vrms:0.00,P1:0,E1:0,T1:23.50,pulse:1
MSG:3,Vrms:0.00,P1:0,E1:0,T1:23.37,pulse:1
MSG:4,Vrms:0.00,P1:0,E1:0,T1:23.50,pulse:1

Is something I’ve missed?

Note: with sketch emonTxV3.4 Discrete Sampling it does show values of consumption:
ct1:73,ct2:0,ct3:0,ct4:0,vrms:536,pulse:0,t0:235
ct1:67,ct2:0,ct3:0,ct4:0,vrms:536,pulse:0,t0:235
ct1:65,ct2:0,ct3:0,ct4:0,vrms:536,pulse:0,t0:235
ct1:64,ct2:0,ct3:0,ct4:0,vrms:536,pulse:0,t0:235

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,

James.

3 Likes