Actually see the “Reset accumulator feed at midnight via API?” and “How to get correct kWh/W values from Pulse - #18 by danielpugh” threads, it has been done before.
Paul,
Excellent! I’ll look into those.
Something you mentioned a while back made me backtrack in the graphs to the when this problem first started, and compare that with the GenTot/ConTot data. Unsurprisingly they are connected.
When I added Generation & Consumption Totals to emoncms.org (as part of development to output to PVOutput.org) the Power1 readings started to flatline.
After much mucking about in the NodeRed code, I’ve finally found the cause of the issue. For reasons I don’t fully remember (but I suspect it was part of my original code written in Perl), I didn’t post contot/gentot values to emoncms.org when the value is zero. This doesn’t effect the graphs for them, but has the side effect of flattening the Power1 feed even though this is being (as far as I can tell) posted correctly. It also had this effect on the new Power1-debug feed.
So, in summary, while gentot/contot isn’t being posted every 10secs, the post for Power1 is being set to zero (same for Power1-debug). When the posting resumes, the Power1 acts as normal.
While I appreciate it’s easy for me to point the ‘blame’ at emoncms, rather than my own code, this does feel like an issue at the emoncms.org end to me, as there is so little code the talks to emoncms at my end. Why it affects those feeds I’m not sure, maybe they are the last ones edited? However, amending the NR code to post the contot/gentot values all the time causes the Power1 feed to resume correctly, instantly.
I’ll add that I’ve also had strange issues in emoncms.org before while tinkering with the feed processing, I left some processing at the end of the list (I think it zeroed out the feed, pulled in a value and multiplied it, but then did nothing else, so didn’t actually log it). This caused some weirdness in the feeds.
Can post some CSV from the Power1-debug feed from when it was faulting?
Refering to your screenshot (below) we can see the emontxgentot has not updated for 7hrs which fits with how you say the nodered script is intended to function and that the power1 and emontxcontot inputs have been updated some 6 seconds after the other inputs. This would suggest that whilst the generation is zero, the power1 value is being zeroed and as the contot is not zero that is being posted and appears to be dragging through the zeroed power1 with it.
Can you post some inputs page screenshots for a time before sun up? I suspect the crucial bit is that either your edit has stoped nodered zeroing the power1 value before forwarding it or your edit has stopped input1 being forwarded by nodered at all. I t would be interesting to see if input1 update times always match just the original node 10 or if they also match the emontxgentot and emontxcontot updates too.
If that is the case, it would be good to locate the issue. I am not an author of emoncms, nor I am not part of the OEM business team so I am quite impartial, I have no reason to defend emoncms, I only want to find the cause of the problem(s), but at this point I suspect very much that it is/was down to the nodered stuff alone. I’m happy to be proven wrong and happy to continue investigating, I will follow where ever the evidence leads.
What you are suggesting is that emoncms(.org) is fabricating a zero value input for power1 each time it receives a single input value for emontxgentot alone and that when it receives an update for both emontxgentot and emontxcontot it doesn’t fabricate a zero input for power1. Although not impossible I guess, this would be really quite odd.
If you were to simply change the node id in nodered so that it posted to an unused node id, say node 99 for example, this would be a safer place to do your daily zeroing and it would make it easier to debug. I believe that node 99 would have more than just the 2 inputs (emontxgentot & emontxcontot) and that node 10 would function correctly.