Wh Accumulator always at zero

Emoncms
1

Hi,

I’m having trouble configuring a “Wh Accumulator” feed, from a cumulative Wh input.

My inputs and feeds are setup like this:

image
image1849×468 25 KB

The problem is that the value of Wh accumalator is always zero.

I have the redis server installed and running. Server details:

Ubuntu 14.04LTS
Redis 2.2.7
Php-redis 2.2.7 (using pecl) (also tried with 2.2.4 (default from Ubuntu), and 4.1.1 (using pecl))
Php: 5.5.9
Nginx 1.4.6
OpenEnergyMonitor.org | 9.8.31 | 2018.06.21

Can anyone figure out a solution for ths?

Thanks,

2

Hello @xgon is your source feed increasing over time ok, and recording the result in the feed attached to the log_to_feed process? the wh_accumulator always starts from zero.

3

@TrystanLea

Yes the feed is increasing over time. From the CSV export:

1st record: 16/10/2018 15:53:40,39692892.00
last record: 16/10/2018 20:27:30,39699672.00

Yes I’m aware the Wh accumulator starts from zero. The idea is to make KWh/d…

Thanks.

4

Thanks @xgon, Have you enabled redis in settings.php? and can you see any redis entries if you connect to redis with cli:

$ redis-cli 
$ keys *

no need to print whats there here, it would just be good to know if there are emoncms input and feed entries.

5

@TrystanLea

Yes I did, and yes there are. Redis server is being used by another application. Is that an issue?

6

Hi @TrystanLea,

I did some investigation:

In file Modules/process/process_processlist.php line 684, we have:

if ($redis->exists("process:whaccumulator:$feedid")) {

            $last_input = $redis->hmget("process:whaccumulator:$feedid",array('time','value'));

            $last_feed  = $this->feed->get_timevalue($feedid);
            $totalwh = $last_feed['value'];

            $time_diff = $time - $last_feed['time'];
            $val_diff = $value - $last_input['value'];

            if ($time_diff>0) {

                $power = ($val_diff * 3600) / $time_diff;

                if ($val_diff>0 && $power<$max_power) $totalwh += $val_diff;

            }

The reason why the feed is not updated is because $power>$max_power. But it turns that power is not correctly calculated, since you are using the $time_diff between now and the last value. We have to use the time of last different value!

Hope this helps. At the moment I’m increasing the max_power value…

Thanks

7

Hello Alexandre,

I’m not quite following you.

What is it we have to the time of last different value?
Use it? Change it? Delete it?

8

Hi @Bill.Thomson

There was a word missing in my sentence… Corrected meanwhile.

The point is we can’t do $power = ($val_diff * 3600) / $time_diff; with $time_diff = $time - $last_feed['time'];

Let’s say you are uploading values in a 5s basis, and the input has these values:

99(t=0), 100(t=5), 100(t=10), 100(t=15), 100(t=20), 120(t=25), …

When the 120 arrives, we are calculating $power=(120-100)*3600/5=14400. However the correct calculation would be: $power=(120-100)*3600/(25-5)=3600

See my point?

Thanks.

9

Who is “we” in this? Are you refering to “we” the emoncms community (refering to the emoncms code) or “we” a group of users that are doing something in particular with emoncms?

I don’t follow how your correction can be correct, it 5 secs ago it was confirmed there was no recorded change in the value (ie prior to 5s ago there was no consumption) and now there is a 20Wh increase recorded, the the former equation in your post (from the original code) is correct as the whole 20Wh consumption can only have occurred in the last 5s.

if in actual fact the correct source data should be more like

99(t=0), 100(t=5), 120(t=25), …

emoncms cannot possibly know that from the data supplied. the data will need to be sent a different way. What is the source?

10

Sorry if the we ofended you. Not my intention.

I agree that the example is a good practice, but that’s how I found the issue. In other words:

Whoever wrote the code, is controlling if power (the 25000 limit). Since the power is calculated between 2 consecutive samples, when the difference occurs, you have a wrong value for the power.

What has to be done is to use the time stamp of the first time that last change took place. See my example again.

The problem is that the feed is updated whether there was a change or not in this line: $this->feed->insert_data($feedid, $time, $time, $totalwh, $padding_mode);

Hope this helps to explain my point. Consider it if you want.

11

No, nobody is offended, I was just trying to get a handle on what you were saying.

No this is the intended action. That line does indeed update if there is no change confirmed because the line is only called when an input is updated, if an input is updated with a later time but the same value, it is confirming there was no change, you cannot then say there was a change (in that same 5s period) 15s later. (see my last post)

The 25000 limit isn’t ideal but it is rare that you would see 25kW’s of power “correctly” on a single phase of most of the domestic and smaller commercial setups. That is why it is there! Because if it see’s 83.3kWh of consumption in 10s (ie 30kW) it’s most likely wrong and that is most likely because the sent data is wrong and 83.3kWh is actually the consumption over a much larger time period.

The maths in the code is correct for the intended purpose, if it’s not working for you we can try and help you but the example you give is not accurate, the former is correct, not the latter.

This isn’t my code so I’m fairly impartial, I personally do not like the hardcoded 25kW limit, but if used correctly and the real power is less that 25kW, it doesn’t cause any issue, in fact if it was user definable it could be used for more accurate filtering, eg there is no point having a 25kW limit for a 4kW PV CT, many more errors could be caught by lowering it to 4kW in that instance. But since it is not configurable it must be high enough to avoid capping valid values without being so high it has no effect.

Are you genuinely measuring valid values over 25000W (power)?

12

In my setup I have smart meters that give me, over Modbus, the total Energy, since ever.

The final goal is to have a KWh/d feed.

At this very moment I’m working on a Python script to just send when any values change, and for energy only the diffs. This way, I think, all my issues go away.

13

You don’t need the whaccumulator then, that is designed for things like pulsecounters that can reset to zero. Think of the whaccumulator as a “ratchet”, if the incoming value drops to zero (eg emontx rebooting), the new difference is still added to the running total, the total doesn’t zero with the input.

Is the “total Energy, since ever” in Wh or kWh?

If it’s Wh, you should scale the input by *0.001 to get kWh then

To record the “total ever” just use a “log to feed” process, you can use a graph or feed api to get the daily delta from the ever increasing total

and/or

use a “kwh to kwh/d” process to create a “daily” feedtype.

Job done!

There is then no need to only send on a change or just the diff, these actions could complicate things.

The only issue you might run into is IF you are recording large magnitude energy readings, because the 32bit feed types will cause some loss of accuracy beyond 9999.999kWh but whole kWh accuracy is retained upto 9999999kWh. If you are using large numbers just introduce an offset, eg subtract 9000kWh from the kWh readings before sending as it’s only the change you are interested in, not the final value.

1 Like
14

@pb66

Thanks for the clarification.

I was following Calculating Daily kWh - Guide | OpenEnergyMonitor , 1b)

Thanks.

15

No problem :slight_smile:

There is a clear need for better in-depth documentation of the input processes.

1 Like
16

The “kwh to kwh/d” can be used to display daily energy in the app?

17

No, the app works on delta’s so an ever increasing total is required, the “log to feed” in your case using my suggestions above.