Community
OpenEnergyMonitor

Community

How to get correct kWh/W values from Pulse

Tags: #<Tag:0x00007fc928699490> #<Tag:0x00007fc928699378>

Hi,

I’m trying to get a kWh/d, kWh (counting) and a Watt/power value from my feeds (I’m fetching this data for openHAB via the API).
However, I’m not sure I’m doing this right, :

The values seems either too high (power to kwh) or too low (kwh to power)…

I’m using emonPI, an optical pulse sensor reader (kWh meter = 1000/kWh pulses) and the latest SW (emonSD-07Nov16).

those last 3 lines don’t look right to me, You are already working with energy (Wh) and line 4 is converting a power to energy, then line 6 is going energy to power.

you could try something like

  1. log to feed
  2. Wh Accumulator
  3. Wh increments to kWh/d
  4. x 0.001
  5. Accumulator (total kWh’s)
  6. kWh to power (power)
1 Like

thanks, I’ll try that :slight_smile:

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)
3 Likes

Hi,

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.

Regards
Dave

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?
Thanks!
Matt

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

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:

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

 
add this to the nodes section

[[14]]
nodename = cron_TOU
[[[rx]]]
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'
rpi-ro 

(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:

###overview
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

###Graphing
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
delta
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)

###Steps
overview
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

[[99]]
nodename = cron_RESET
[[[rx]]]
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
save

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?

```text
[your code here]
[or your config change]

```

of course not - just hope its helpful!