Hi Paul, I think what you are seeing there is a couple of “quirks” of the system, as a matter of fact I was going to mention these “quirks” yesterday in the Wired as Type 1 but will set up only as Type 2 thread but didn’t want to confuse that issue further or appear to be “nit picking”, but since you mention it . . .
Firstly, when you look at the first line of your power1 process list
- add power2 to power1 (usage)
what I believe you actually have there is
- add current power2 to previous power1 (usage)
because even if your inputs update with absolute precision and reliability, input2 comes after input1 so all thing being equal, when the first input arrives, the second input has not yet arrived!
So in this instance if your previous PV power2 value happened to be 2496 at the time the power1 processing was performed, then 2496 + -2500 = -4.
It might be better had the CT1 and CT2 been swapped so that solar was power1 and grid was power2 OR you could just have all the processing in the second input eg
- add power1
- log use
- log use kwh
- subtract power2
- apply >0 filter
- log import
At least when the 2nd input updates you have all the latest values . . or do you?
Once upon a time all these inputs would have arrived as a single payload, they start out as a single payload from the emontx and when sent to emoncms via http, they remain as a single payload. On the emonSD images, emonhub splits this payload up into individual mqtt topics, so they are then handled individually and ordinarily, they all arrive in the same order they are published, but that is not guaranteed, at all. So ordinarily what I’ve said above stands, but the inputs can occasionally arrive out of order, thankfully it’s rare as far as we know.
As far as I’m aware, the only safe way to do cross input processing is to get the updates via a single payload and to order your input processing so that a later input is never used in an earlier inputs process list. To do this you would need to revert to using either HTTP or the old “nodes module” version of mqtt payload.
If everything is updating regularly and without any issues, the data “anomalies” should only equate to a “10 second offset” hence why I thought I’d be accused of “nit-picking” but I’m afraid this is an inaccuracy I personally couldn’t tolerate just to “have mqtt”, there are other flaws too, eg lack of timestamp, but I do not think that is a factor with what you are seeing here.