How to get correct kWh/W values from Pulse

Still getting some weird values but I noticed on the “wh accumulator” description that I should use the “emonTxV3_4_continuous_kwhtotals” firmware however I’m running the “emonTxV3_4_DiscreteSampling” because I’m also doing CT measurements…

What should I use?

That sounds like a “pre pulse counting era” piece of info,

emoncms has no way of telling where an accumulating Wh counter is coming from, whether it be a pulse counter, a direct meter reading or a calculation from power, the latter is how the “emonTxV3_4_continuous_kwhtotals” firmware works and I’m not sure that firmware is currently used.

Any OEM firmware with a pulse count in it’s output should be suitable for use with the WhAccumulator so the sketch you have should work.

I understood from your wording that the first part or the processing worked fine and just the kWh and kWh/d were incorrect which made sense given the processes you were using. Are you saying the initial WhAccumulator is incorrect too?

Aha, I see. The wh accumulator looks correct but the kWh/d and “power” (kWh to power) output seems to just count upwards indefinitely ?

Inputs & feeds:

Thanks for helping :slight_smile:

I’m reasonably sure it gives wrong values in certain circumstances, so it should definitely be avoided. I’m still working on it.

Ahh! Yes (I forgot, again!) the WhAcumulator doesn’t pass the increment on for further processing, it passes the ever increasing total. I don’t use the WhAccumulatot myself, you could try something like

  1. log to feed (optional as the next process also records each raw value)
  2. total pulsecount to pulse increment (records the raw value for use next time and passes the calculated increment to the next processor)
  3. x0.001 (scale to kWh from Wh)
  4. kwh to power (power in watts)
  5. kwh to kwh/d (daily_kWh)
  6. Accumulator (total_kWh)
1 Like

Ah! I think the kWh/d is reporting correctly now! :grinning:
But the “kwh to power” value seems too low for some reason. It’s reporting between 2500W to 3600W, and I roughly estimate my usage around 4-5000W…at that time.

I just looked at the code for the power to kWh process and it looks like that does take an accumulating total as an input. Try moving the “kWh to power” down to below the Accumulator eg

  1. log to feed (optional as the next process also records each raw value)
  2. total pulsecount to pulse increment (records the raw value for use next time and passes the calculated increment to 3. the next processor)
  3. x0.001 (scale to kWh from Wh)
  4. kwh to kwh/d (daily_kWh)
  5. Accumulator (total_kWh)
  6. kwh to power (power in watts, calculated from the increasing total)


Just wanted to give an update on my experience so far, I had to change a little on the sequence as the kwh to kwh/d seems to pass on its own result (not pass the previous value).
The kWh/d seems to be correct but the “kwh to power” just doesn’t seem right, it’s always too low. I’ve seen my total usage be estimated (based on how many heat sources active in the house) around 4kw+ and it reports it as 2.5kw.

UPDATE: Seems the kwh to power might be right after all, after some investigation it seems my house previous owner have been creative and wired some circuits outside the meter :imp:

Id be interested to see you crack this, I would like to implement a rough cost per hour for electric, gas and water, would like to try and encourage people to realise how much things cost.


Hi guys,
Complete newbie here and have just bought the EmonPi so creeping up the learning curve.
I am trying to plot Power (kW) from optical pulses, but have only managed to setup an accumulated graph of pulses so far. I think I need the ‘total pulsecount to pulse increment’ but don’t see this as an option in the process drop-down list.
Any ideas?

Am I correct in thinking you have to use MongoDB rather than mySQL to be able to do this conversion?

AFAIK there is no dependency on MongoDB in emoncms, I’m not even sure it can be used directly with emoncms. There are several processes that depend on Redis for additional processing data, predominantly anything that uses a “previous” value to determine the current value eg WhAccumulators and pulse counting etc.

in case you are still struggling or anyone else comes across this - i struggled for days with the schedule and although i got close i found that the cron method elsewhere was much easier to get working and much more accurate.

Hi Daniel! Can you point me toward the cron method? I am curious about the accuracy and how it works. Thank you!

all credit goes to pb66 and BMJ on a thread I found, but it works brilliantly
the previous thread - Dual electricity rate in emonCMS - #5 by pb66

ive written out the combined steps from the previous post that I went through (hope it makes sense);

in the web interface add the virtual device (login → emonhub → edit config as below → save

add this to interfaces section:

        Type = EmonHubSocketInterfacer
            port_nb = 50011      # sets the port to listen on, cron must point to this port.
            pubchannels = ToEmonCMS,      # only required in the emonpi variant of emonhub

add this to the nodes section

nodename = cron_TOU
names = cost,peak, off-peak
datacode = 0
scales = 1,1,1

log on via ssh (e.g. via putty to the ip of the pi

User: "pi" | Password: "emonpi2016"

rpi-rw (changes the pi to read write mode so you can write the cron)

sudo crontab -u root -e

create a crontab
mine are 00:00-05:00, 13:00-16:00, 20:00-22:00
my off-peak rate is 7.83p, and peak is 16.04p
basically multiples of the two lines below
1st line sets current cost to 7.83p, the second line returns it to 16.04
obviously you need to find out your tarrifs and times (ideally test by checking meter at changeover times)

00 0 * * * /bin/bash -c 'echo -e "14 7.83 0 1\r" > /dev/tcp/localhost/50011'
00 5 * * * /bin/bash -c 'echo -e "14 16.04 1 0\r" > /dev/tcp/localhost/50011'

00 13 * * * /bin/bash -c 'echo -e "14 7.83 0 1\r" > /dev/tcp/localhost/50011'
00 16 * * * /bin/bash -c 'echo -e "14 16.04 1 0\r" > /dev/tcp/localhost/50011'

00 20 * * * /bin/bash -c 'echo -e "14 7.83 0 1\r" > /dev/tcp/localhost/50011'
00 22 * * * /bin/bash -c 'echo -e "14 16.04 1 0\r" > /dev/tcp/localhost/50011'

in order to test you can just initiate one of the commands from the cli, which will populate a current value immediately

/bin/bash -c 'echo -e "14 16.04 1 0\r" > /dev/tcp/localhost/50011'

(coverts back to read-only mode)

you should see a new input called “cron_TOU” in the inputs section
if you are missing the inputs on the device then reboot the pi

sudo reboot

mine looks something like this:

cron basically creates a virtual input on device 14 and sets/updates current cost as an input
the nodes section gives this on the virtual device cron_TOU
then configure the pulsecount interface (i used as per below):

##first a total cost accumulator
reset to original - (if doing something already e.g. logging raw pulses, kwh, etc)
total pulse to pulse increment “total pulse” (pulses since last update)
x input “cron_TOU:cost” - (multiply by cost)
x “0.001” - (convert to kW)
log to feed “pulse total cost” - (log the incremental cost increase)
accumulator “total cost accumulator” - (accumulates a total ever-increasing cost)

##then a peak cost accumulator
reset to original
Total pulse count to pulse increment “peak pulse” - (find the incremental number of pulses)
x input “cron_TOU:peak” - (multiply by zero when off-peak - i.e. total cost increment is zero’d out when off-peak)
x input “cron_TOU:cost” - (multiply by the current cost to calculate current incremental cost)
x “0.001” (convert from pulses to kw - my meter is 1000 pulses per kw)
accumulator "peak cost accumulator) - logs an accumulating current cost

##then an off-peak cost accumulator
reset to original
total pulse count to pulse increment " off-peak ulse"
x input “cron_TOU:off-peak” - (multiply by zero when peak - i.e. total cost increment is zero’d when peak)
x input “cron_TOU:cost” - (multiply by the current cost to calculate current incremental cost)
x “0.001” (convert from pulses to kw - my meter is 1000 pulses per kw)
accumulator "off-peak cost accumulator) - logs an accumulating current cost
it should look something like below

viewable via the eye icon in feeds and then add the others (ill try and upload an example) - in my example I used the following feeds:
total cost accumulator
peak cost accumulator
off-peak cost accumulator

you should see flatlines for the times when tariff not applicable
the total cost accumulator should be the sum of both peak and offpeak (i.e. no flatlines)

After 24hrs you should be able to view cumulatively
in graph select
time period 1 day
set the type to barchart in the drop-down

in an ideal world another cron would exist to reset the accumulator at midnight and you could then view todays cost as well as previous days (i.e. without deltas

lo and behold pb66 has delivered again - my thanks again (previous thread)

###resetting the graph at midnight (to avoid using delta
this allows for a graph of the current daily accumulating cost
please note i think probably best to log two graphs. One which resets and one which doesn’t. This Then means you can use deltas on the one which doesnt reset to show e.g. cost last week, cost last month, cost last year simply via deltas.
unfortunately you can’t just add the non-resetting accumulator below the resetting one as it will receive the input of the accumulation (i.e. reset to original and create a section just for the cumulating one)

create a new input that is logged to the accumulator feeds at midnight setting a value of zero.

[optionally create the interface names] - this will add friendly names to the inputs

nodename = cron_RESET
names = reset
datacode = 0
scales = 1

(for some reason my input shows as r instead of reset - not sure why but never mind)

login as ssh
rpi-rw (changes the pi to read write mode so you can write the cron)

sudo crontab -u root -e

add a line to crontab (this will send a reset to the new feed at midnight)

00 00 * * * /bin/bash -c 'echo -e "99 0\r" > /dev/tcp/localhost/50011'

save this.

then trigger the new input via cli:

/bin/bash -c 'echo -e "99 0\r" > /dev/tcp/localhost/50011'

node will appear in inputs but only show rssi
reboot pi

sudo reboot

in inputs edit the new input [spanner icon]
add a “log to feed” for each of the accumulators [specifically choose the existing feeds rather than creating new ones!)
total cost accumulator
peak cost accumulator
off-peak cost accumulator

it should look something like below:

wait till midnight and the graph should look something like below:

###Further improvements
one thing i noticed when rebooting the pi completely (e.g. power cut) is that the input of the current cost is lost
thanks again to pb66 who had an immediate answer to my shoolboy error.
i needed to record the input to a feed so it would be maintained following reboot

so here are the changes i have just made to fix this:

  1. In the inputs (in my case cron_TOU), for the individual inputs of cost, peak, off-peak, add an input to each of “log to feed”, “create new”, name (I used the names - “current cost”, “is_peak” and “is_offpeak”), type: phptimeseries.

  2. manually triggered a value to be set (and therefore logged to the new starting value)

  3. go back to the pulsecount and replace each “x input” with the relevant “* feed”

  4. i copied the first total cost section to create a new accumulator (not to be reset at midnight) for use with deltas (i.e. cost last month, cost last week etc

leaving a process list that looks like this:

1 Like

Thank you! I do need to read thru this, and the other topic, a few more times.

Do you mind if I place some of the above into code blocks?

[your code here]
[or your config change]


of course not - just hope its helpful!

Your post is very helpful!

(if you’re referring to the code blocks - I changed a couple of areas. Look OK?)

it does look much better. I have added a bit more info and some pics to make it easier to work with

the scheduler looks like a neat way, but I hit quite a few issues - specifically in case it helps anyone get that working (to help them save the days of pain I went through!)

  1. schedulers not supported by the cloud version (I think you can replicate the input for this cron method from the emonpi to the cloud which is an advantage)
  2. overlap of schedules;initially I setup two schedules peak and offpeak, but there was an overlap on the hour and both sections of processing resulted in a doubling up (vertical line).
  3. Then I changed the schedules to end one minute before, but it misses some data (only one minute, but I didn’t like it)
  4. then I changed to a combination of if schedule zero and if !schedule zero - this was a headache to work with and only worked with one type of schedule (e.g. peak or offpeak) so very complicated for extra schedules
  5. at that point I had two feeds - combining them was a nightmare - I tried virtual feeds but it completely failed (hundreds of errors when attempting to graph)
  6. then I added a bit of logic to at the end of each schedule/!schedule to add the other current running total and log to a combined cost graph. first this added the incremental so I had to add an accumulator- this still resulted in vertical lines at crossover so i abandoned and searched for a better way.
  7. then I tried the cron method which is elegant in its simplicity in providing a feed with the current cost and a method of filtering on/off-peak and it worked first time pb66 is a genius! what I particularly like is that there is no need to add together two feeds as all three are calculated separately and so can be used (if started at the same time) to verify that its working as off-peak + peak should equal the combined peak graph which you can see from the uploaded graph/image.
1 Like

Thx for the write-up. One thing threw me off though. I got an error when rebooting the device and after a closer look at this bit of code… there is a space before “off-peak” which shouldn’t be there :wink:

1 Like