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…
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?
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)?
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
use a “kwh to kwh/d” process to create a “daily” feedtype.
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.