Archived Forum

@Eric, I too would like to know the answer. I am wanting to build a similar system. My meter is far away from any power points.

Did you wrote you own firmware for the emonTH? I can't find where to configure a emonTH to read pulses.

Hi,

I'm writting it. It's a pain to make it low-power but I'm doing some progress.

I will publish it as soon as it's ready and fully tested

Eric

Here is my sketch.

I'm not very happy with it because it's not simple but I failed to write a simple and low-power sketch. Here is the full story.

First, I tried the emonTH pulse counting sketch found on github. Between two sent, there is no power saving => battery lasts only 4 days ...

Then, I moved to a low power sketch where Emonth sleeps between two interrupts. Something like this one. The remaining question was : when should Emonth send data to emoncms ? Every times a pulse is counted ? No, because I want to be able to handle at least 10 pulses / seconds.

As EmonTh loses track of time when sleeping (like us ;),one can't make it send data every x seconds using time counters. I think it's imposible without using an external RTC.

So I envisaged first to make it send data every x pulses. It's not a good deal as it means that the update rate will vary a lot considering the pulse rate. In my case, I'm counting pulses from electric meter (1 pulse = 1 Wh). Power may vary from 100W (one pulse every 36 seconds)  to 36 kW (one pulse every 0.1 seconds). So, if x=100 pulses (emonth sends data every 100 pulses), the update rate may vary from 3600 s to 10 seconds ...

So I decided to add another  condition to send data to emoncms. Data will be send when x pulses have been counted from the last sent OR  when y ranges of short time without any pulses (z ms) have elapsed from the last sent.

In the attached sketch, x is PULSE_MAX_NUMBER, y is WDT_MAX_NUMBER, and z is WDT_PERIOD. Desired values for x, y and z must be choosen with the attached ods file according to your meter and the targeted update interval.

I'm only sendinf pulses (ie kWh) , so power must be calculated in emoncms using the kwh_to_power process.

Eric

I have just measured the current consumption of the new pulse sensor. It draws near zero current in between pulses and a transient 8mA when a pulse is detected so it should be able to be used with the emonTH for a decent time period on batteries. emonTH firmware will need to be modified. http://openenergymonitor.org/emon/buildingblocks/opticalpulsesensor

Hi,

Great news !

Unfortunately, a sensor based on a LDR is not very easy to setup. Mine works fine at low frequency, but I'm not sure it's ok with 10 pulses/seconds.  The value of the pull up resistor is also difficult to setup. A large value make the sensor miss pulses at high frequency (due to LDR latency). A low value drains batteries. For DIYer, it remains a cheap solutions (less than 1€/$).

You're talking about a decent time period on batteries. Could you please tell us more ? Several days, weeks or months ? What would be the battery life at high pulse rate ?  Let say one pulse every 0.5s 0.2s (18kW) ?

Eric

EDIT : if you can have a look on my sketch ... Comments will be appreciated.

Hi,

I read on here that the current consumption of the new pulse sensor is about 0mA in darkness but about 8mA for duration of pulse (standard meter 100ms).

8mA during 100ms, that's a lot ! With one pulse every 0,2 s (18kW), it means that EmonTH battery will only last 24 days. (according to this tool)

Glyn, could you please confirm your current measurement. ? ( 8mA for duration of pulse)

Thanks

Eric

Hi

Here is an idea that I haven't tested:

Connect the power wire from the sensor to screw terminal 5 on the EmonTH. This way you can control the power to the sensor.

Now in the interrupt routine in the sketch, turn off the power to the sensor, count the pulse and set flag for new pulse true.

In the main loop:
if flag for new pulse
  sleep for the minimum duration of the pulse (100 ms)
  Then turn the power to the sensor back on.
  Set flag for new pulse false

in setup change:
attachInterrupt(0, onPulse, FALLING) to 
attachInterrupt(0, onPulse, RISING);
 

Hi kirkholt,

Sorry for the late answer. Just back from long holidays.

Thank you for helping me. I tried your idea and it seems to work fine with the optical pulse sensor from the shop.

Unfortunately, I can't say if it really save the emonth battery. I guess I need an oscilloscope (and more knowledge !)

Please find attached the modified sketch.

Eric

Hello Eric, I see what you mean now regarding your pm and after struggling with this for a bit, can I add your example to the EmonTH github repo? with attribution to yourself of course. Thanks a lot for sharing it!

I tested the current draw when it sleeps and it does drop down to 0.06mA, the same as the main emonth firmware example without the pulse counting.

I've tried merging your code with the emonTH_DHT22_DS18B20_RFM69CW example and I think I have it working. I've uploaded it here: https://github.com/openenergymonitor/emonTH/blob/master/emonTH_DHT22_DS1...

I put a millis() elapsed check in the sketch to count the awake time, it seems to be reporting that its always awake, or the timer for millis is not turned off as expected, but then the current consumption does drop to 0.06mA, Im getting the same result with your original example too.. Not sure whats happening there.

Edit: I also had to remove the use of the DS18B20 ADC or power pin to turn on and off the power to the optical pulse sensor as they may be used by a DS18B20 temperature sensor, I need to find an alternative method.

Check out Sleepy::loseSomeTime() at https://github.com/jcw/jeelib/blob/master/Ports.cpp#L1139.  After it wakes up  again (provided it was woken up by the watchdog)  it knows how long it was asleep  and fixes up the timers so you won't appear to have lost any time.  If it's woken up by your pulse, then it guesses a correction.

Unrelated to that,  you probably want to declare this guy as volatile:

boolean  p;

That's an interesting post, may be the 8ma are because of the onboard led of Optical Utility Meter LED Pulse Sensor. I did not find the schematics, are they open source ?

Hi Trystan,

I'm happy to see that you dived into that piece of code. Feel free to improve/publish it as you want. According to me, a battery-powered EmonTH being able to count pulses for month is a must feature ! In France, most of electric meters (about one over two) are not inside the house. All others monitoring solutions have it.

I have been testing my sketch for weeks and it works fine whatever the pulse rate is. From 0,1 pulse/sec to 10 pulse/sec. But I'm not very satisfied with that sketch because :

• The code is not easy to read/understand.
• Some constants must be set accordingly to the pulse rate and the pulse duration.
• The time between two sents is dependent from the pulse rate...

It looks like it is not possible to make the EmonTH count interrupts, sleep between interrupts and send data at a fixed rate using the current hardware. Can this be solved adding a cheap piece of hardware on the EmonTH ? I'm thinking about a low power counter or a low power RTC but I have no idea if it is possible.

Eric

Thanks dBC, that's really interesting, I missed that.

Thanks Eric, I've uploaded your example here replacing my initial attempt:
https://github.com/openenergymonitor/emonTH/blob/master/emonTH_pulse_low....

I've realised there is another issue with the LED on the optical pulse sensor in that it stays on constantly when no power is being used (red led on utility meter stays on when power consumption is 0). Which means my test emonth is down to 2.8v already...

The signal from a passive LDR sensor can also be detected by regular polling at any IO port.  Each pulse from my electricity meter is approx 38 ms in duration, so can be reliably detected by polling once per mains cycle.  If this source of timing is not available, a repetitive hardware timer could be used instead. 

If the LDR sensor is well shielded, it will only consume any power when the meter's LED is on.  In most situations, this will only be for a very small fraction of the time.

I think that varies a lot from meter to meter.  My revenue meter signals each Wh of consumption via its LED, but it appears to do it with a 50% duty cycle square wave on the LED.  In other words, every Wh consumed it turns the LED on but it doesn't turn it off until 0.5Wh later.   It's a toss of a coin whether my meter spends the entire day with the LED on, or off... depending on where it happened to be when the PV output started exceeding my consumption.

Hello,

Is your sketch working on emonth v1.4 ?

I've got one but impossible to make it working...

Thank's !

[Please DO NOT DOUBLE-POST. The duplicate has been deleted. Read 'Read this before posting' to know what happens. Moderator (RW)]

Hi

Many different sketch have been discussed in that post for months.

What sketch are you talking about ?

Eric

Thanks for your answer.

This one :

https://github.com/openenergymonitor/emonTH/tree/master/old/emonTH_pulse_lowpower

PS : C'est bidonnant deux français qui parlent en anglais... :D

Salut,

This sketch is intended to work on EmonTH 1.4.

No led activity is programmed in this low power sketch.

What sensor are you using with the EmonTH ?

How is it wired to the EmonTH ?

Eric

PS : Oui c'est dingue, d'autant que je ne suis pas sur que l'on se comprenne mieux en anglais ... mais pour les autres qui nous lisent, c'est mieux. Si c'est trop compliqué,  on discutera par message en francais.

Hello,

Thank you for your answer.

I will make another tests this evening.

This is a reed contact that i try to use. Wired between 5 and 4 and with pull-down resistor between 4 and ground.

A+

Hi Patrice,

I got it !  In the discussed sketch, there a mistake ...

Replace "attachInterrupt(1, onPulse, RISING);" with "attachInterrupt(0, onPulse, RISING);" to make it work on EmonTh V1.4

Eric

Hello,

Thank you for your answer.

I test it as soon as possible.