My Solar app calculation errors

Applications
,
1

I’m getting strange results in my feeds (and therefore My Solar app). I’ve been a long time user of this system who has just rebuilt a very old emonhub online instance to a new build running locally.

I seem to have everything setup correctly but I’m getting negative usage logged. See the following screenshot, it claims I’m exporting more than my solar PV is generating.

Any ideas, or have I stumbled onto a new scientific discovery?

01
011396×702 110 KB

My system is configured with power1 around meter tail (net import/export), and power2 on solarPV feed. Therefore logic is:

  • add power2 to power 1 (usage)
  • log use
  • log use kwh
  • subtract power2
  • apply >0 filter
  • log import

Solar feed is simply:

  • log power2
  • log power2 kwh

In the example above, how on earth is -4 getting logged to use when power1 + power 2 = 353!

Any ideas?

2

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

  • log power2 solar
  • log power2 solar_kwh
  • 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.

3

Thanks Paul, I think you’ve nailed it.
I suspected it might be ‘old’ values as the problem is most noticable when clouds pass over and the solar generation suddenly swings wildly.

That also explains perfectly why my very old ‘once upon a time’ emonhub setup had no issues.

Definitely not nit-picking. Its been driving me mad and personally I think its a pretty critical flaw that there’s no ‘TX/RX complete’ state from a particular node before feed processing starts.

Will try the workaround you suggest of moving processing into the second input, but that’s hardly ideal. Will let you know how it goes.

Thanks so much for the help!

4

Or you can just define a http interfacer in emonhub.conf that points to localhost rather than a remote emoncms.org and process those inputs rather than the mqtt ones. A few users have done this. It’s up to you whether you remove the mqtt interfacer, it doesn’t do any harm and may be useful for other stuff. These are user configs I’m talking about of course, not changes to any code.

But moving the processing to input2 is required which ever way you do it unless you swap your CT’s so that input1 is solar and input2 is grid (so they arrive in the right order whether it be individually or in a single payload). I don’t think it matters too much where the processing lives as long as all the values are current by the time that processing is called.