No such suggestion from me.
I have finally started my energy monitor renewal project and I am completing the PCB.
I recently discovered that the EmonLibCM library is also available, I’m starting to study it: really congratulations to all those who worked on it.
This library would be perfect for my log operations: with my current software I measure every 0.5 seconds with standard Emonlib and then send the average data to EmonCMS every minute, calculating the average of the various parameters in this period.
EmonLibCM_datalog_period(60) I would get just what I need.
In addition, the library already integrates the measurement from the temperature sensors: perfect!
My Arduino, however, also performs the task of signaling with a buzzer that I placed in the kitchen, if the (absorbed power - produced power) exceeds an adjustable threshold. This function is very useful when starting appliances in conditions that would lead to interruption of the power supply of the whole house.
I suppose it is not possible to access “instantaneous” measurement data or with another period shorter than the log period, for other types of functions (I think of those who want to implement load control-priority systems).
What could I do? Reduce the log period to what I need and then calculate the average of the quantities to send to EmonCMS as before?
thank you all for the wonderful work
That is correct - the “instantaneous” data does not exist in a form that is usable, because in order to be able to monitor continuously, much of the calculation that was done on each sample pair (in emonLib - the old discrete sample version) is now done when reporting the average values.
That is the real problem - OEM was never intended for control, only monitoring.
You could set the reporting period to 0.5 s. You can use the ½ second power values to actuate your buzzer. Then you need to send every 120th set of energy values to emonCMS. If you want power averaged over that period, you can do that in emonCMS or you can save the old energy value in the sketch and subtract it from the new value. That would be very easy to do.
You are likely to have problems with temperature measurements - the library commands the sensor to start “converting” the temperature at a time it calculates, based on the resolution you ask for, so that the reading will be ready when the power calculations are done. (This is so that, reporting every 1 minute, the temperatures are only 1 second old when they are reported.) It would be possible, but very hard, to command the start in the previous datalogging period and read the temperature in the next, but even then, data transfer from the sensor is very slow (it takes about 16ms per sensor) and that might cause more problems. It is not something I have looked into.
thanks for the answer, probably for the sampling time it would take me 2-3 seconds to command the buzzer (even now I managed a delay in exceeding the threshold), for the temperatures I go on studying the library
I’m slowly moving forward with my project (it’s not easy with a baby girl).
I made a slight modification to the V2.0.4 library, which I wanted to share, if @Robert.Wall deems it useful (and above all correct) he could integrate it in a future release.
For those who need quite fast clocks in electrical parameter measurements, but not for temperature measurements, I added a property:
temperatureSamplingRatio (default = 1)
to be considered as a multiplier of the “datalog_period”: if this property is not changed, the measurement clock will be the same as the electrical parameters (datalog_period_in_seconds) and the library behavior will be standard, otherwise the temperature data will be available every (datalog_period_in_seconds * temperatureSamplingRatio).
For example by setting datalog_period_in_seconds = 0.5 and temperatureSamplingRatio = 120, the temperatures from the sensors will be read every minute.
I then added the EmonLibCM_setTemperatureSamplingRatio(int) property-setter
and the return value of EmonLibCM_Ready() will no longer be a boolean, but a bitmask indicating the type of data available (only electrical or even temperatures).
I also removed the inclusion of the Wire and SPI libraries, as they don’t seem to be used in the library.
I’ve done some testing and everything seems to work, I haven’t tried in acPresent==false mode.
EmonLibCMmod.zip (15,6 KB)
What’s the benefit of doing this, versus just discarding the unwanted samples?
I see some advantages:
with clock less than 0.2 seconds the temperature measurement would not be possible, the library returns BAD_TEMPERATURE
with clock lower than a second the resolution is forced to the minimum (9 bit)
if I just need a temperature recording every minute, but I need to measure the electrical parameters every 0.5 seconds (see my example above) doesn’t seem like a good idea to invoke a temperature conversion on all sensors 120 times per minutes where 119 are done for nothing
I need to look into the timings in detail before commenting.
a question for my curiosity: in my Arduino project, as written in some previous posts, I command a buzzer to signal that power exceeds a settable threshold
the command is done using the tone() statement:
I noticed that, compared to the use of the discrete EmonLib library, with the CM the tone emitted by the buzzer is different, a lower frequency: this behavior derives from the use of interrupts?
I won’t investigate (as I’m too busy), but I would be almost certain that this is the case.
The solution of course is to use a self-contained sounder that needs only a d.c. signal to drive it, and turn on a digital output for the duration you want the sounder to sound, rather than driving a piezo element directly as you appear to be doing.
See also Tone
Be aware that the interference may well happen in both directions. It’s been a while but from memory AVR interrupts aren’t nestable - they’re all at the same priority. So just as the latency introduced by the ADC interrupt impacts on the tone’s timer interrupt, so too the tone’s timer interrupt might introduce enough latency to disturb the ADC work.
thank you so much for your help, it was just what I feared…
I will follow Robert’s advice and replace the buzzer
Continuing my (on and off) efforts to make emontx (and firmware EmonTxV3CM) work for me, I downloaded version 2.1 of the library from github and bumped into a compile error involving variable assumedVrms. Further digging around reveals that github no longer hosts the most recent version (2.2.1), which I downloaded as provided elsewhere in this forum. This version fixes the problem by renaming the variable, just as I did!
However, looking at the zip file I downloaded, I do not see the .h file for v2.2.1. Am I missing something?
I don’t know why you can’t see it. I have, only a few moments ago, downloaded it from
and both files are in there.
Hmmm…let me try again. Is this the zip you just downloaded:
If so, what I see in that file is a directory named emonlibCM within which is a .cpp and .h file containing comments indicating version 2.2.0. I also see at the root directory of that zip a .cpp file, but not a .h file, with comments indicating version 2.2.1. Is that what you see?
That clarifies the problem. The release seems to have got tangled up, the header file was always the correct one - it was unchanged, the cpp file just hadn’t got put into the sub-directory to replace the 14th Sept version. I’ve updated the release page with a new zip file, but not changed the version number as the code is unchanged.
Thanks for spotting it.
I have just experienced the same problem (“compile error involving variable assumedVrms”) and eventually solved it using the information above.
However, I think there is still an issue to be fixed, as GitHub - openenergymonitor/EmonTxV3CM: EmonTxV3 Continuous Monitoring Firmware (Default shipped EmonTxV3 firmware) refers to version 2.1, which gives the compile error. I got version 2.2.1 from https://community.openenergymonitor.org/uploads/short-url/tPz0uVfDxInGNWuPgvVhwchs6IG.zip. I couldn’t find version 2.2.1 on Github - maybe my ignorance but at any rate it wasn’t obvious.
Best wishes and thanks for all the software.
Sorry, but I have no control over Github.
At the head of the Topic announcing emonLibCM, it very clearly states
and that is indeed what has been happening.