Using query to get solar import and export

I have configured my IoTaWatt with 7 outputs but one of them cannot be accessed with the Query API. (It returns 0.)

This is a pared down example with only 3 outputs showing the troublesome Output (named “Imported”).

However, the “Imported” Output definitely exists and apparently can be accessed by Graph+.

“Imported” is shown with the red trace.

This is a view of the Output formulas FWIW. Latest firmware and good WiFi RSSI. Any help would be much appreciated; I’m out of ideas.

Output Formulas


Joe, what do you get if you delete ‘max 0’ from the ‘Imported’ output?

Please read the docs section about integrators here. Pay particular attention to the section about tracking solar import/export.

Your Graph+ plots Watts. I cant see the &end value, but it appears to be sometime later the same day. Apparently you have &group=all. That will yield the net imported Watts. Since your exports exceed the imports, the net is negative and your output makes that zero.

In the statistics tab of that plot, you might look at the Sum/Integral column for import and export. That will give you a preview of what the integrator will do.

1 Like

That was it! I deleted the "max 0) and Imported immediately showed a figure. Thank you, Steve.

However (isn’t there always a “however”? :slight_smile: ) now the Exported output is zero when queried. But the graph shows a non-zero plot for it (as well as the newly working Imported) . I guess I’ve learned that the Query API does not return values just because they appear on the graph – the graph is not a validation for the formulas.

I guess I really don’t understand how to assign two different Outputs to the inputs such that one Output shows the positive-signed energy and the other shows negative (mains with a solar system giving both imported and exported).

Back to the docs and more head scratching. Thanks again, Steve.

About to hit “reply” and noticed a reply by @overeasy so will digest that before I do too much head scratching.

Perfect! No “head scratching” necessary; the Solar inverter connects after mains (most common) example in the docs suited my situation and it became trivially easy to configure.

Thank you for that pointer and especially for implementing and documenting “Integrations”, Bob.

While I have your attention may I ask a couple more questions, please?

  1. As you probably surmised from my earlier Outputs configuration posting, Solar feeds a subpanel named Hangar before it joins the main panel. Since I’d like to monitor the Hangar subpanel, wouldn’t it also be a good candidate for a Integrator too?

  2. Are there any undocumented API calls for peak power and the time of first/last (solar) power of the day that would be more efficient than downloading a lot of 5-second interval data and processing it externally?

Thank you,

You should use integrators sparingly as they consume resources. You would use an integrator for the subpanel if you were interested in how much energy is imported to and exported from the sub-panel, but if you only care about how much energy is used by loads in the subpanel, you would treat it just like your Usage output on the main panel:

Hangar = Hangar_1 + Hangar_2 + Solar

But because energy can flow both ways (+/-) through the Hangar CTs, you would need to check “allow negative values” for those two CTs.

There is not. But downloading 17,280 5 second data points may not be necessary. An efficient query is 720 data points or less, which is 2 min intervals for a day. To find the first/last, you need only look at those to get your answer with 2 minute resolution or do a second query of the 24 datapoints in that two-minute interval to get 5 second resolution.

On the other hand, or for the maximum case, downloading a day’s worth of five-second samples takes about 3-5 seconds and is about a 20KB response. To search over a longer period of time I would recommend setting up an influxDB database. It has min/max query functions.

This is my case, so that’s what I did, and it works well.

Regarding an efficient query for peak/first/last: the 2-minute interval query seems like a good idea. However (there’s that word again :slight_smile: ) I need to do this multiple times as the day’s solar generation progresses and the web page displaying this stuff is updated.

But I do store a daily summary (to include peak/first/last) in a MySQL database so I would only have to download, calculate, and store these numbers one time and only for “yesterday” and prior. I would not have those figures for “today” but I think I can live with that, especially since I have the wonderful Graph+ that shows me those things at a glance.

Once again I am indebted to you for your help.

BTW, until you pointed me to Integrators I had been using a PDF copy of the docs that I found on the web but I now realize it’s sadly outdated (release number 02_03_20). Wonder if a current PDF is available?

Even after implementing an integrator I’m still having an issue with incorrect results via an API call. Oddly enough, if I restart the IoTaWatt I receive the correct results – for a while. Then it’s back to the incorrect results where it remains frozen until I restart the box again.

This query:


produces this result:

20814, 4885, 13586, 9220

but less than a minute later and after restarting IoTaWatt it returns:

20870, 4885, 16539, 9227

The third parameter, Exported power, was “frozen” for an unknown period of time. In the first returned results, it became obvious to me that Exported was bogus because Solar + Imported should equal Exported + Usage and it wasn’t so. After a restart they were approximately equal.

So I’m wondering if there’s something wrong with the format of my query. I’m interested in a single day’s results and I’ve entered today’s date with a timestamp for begin and end parameters but have tried others.

Incidentally, this is another pared down example and the full query has an additional 3 parameters that are always correct – no freezing. I believe Solar and Usage (the first and fourth in this example) are always correct too but I’m not 100% certain. The second parameter, Imported, was actually the original cause of this posting but I think it has been solid since using an integrator.

Thanks for any light you can shed on this.

Can you post your inputs, outputs and integrator setup?

Yes, I’m happy to.



Can I see the message log please?

What appears to have happened is that the integrator was not working and after the restart it “caught up” to the current time. This is very unusual as once synchronized (up to date) it is maintained at the same time as the primary datalog. Maybe there’s a clue in the message log.

Is this something that is happening regularly or a single instance? Can I see your status display as well with the uploader (if any) and data logs tabs expanded?

If this freezes again, can you look at “data logs” in the status display and see if the Grid Log end at the same data and time as the current log? They should be advancing in lockstep.

Yes, “caught up” is an apt description. Nothing seems to be permanently missing.

This has been happening regularly – numerous times per day. I don’t always restart; sometimes its seems to fix itself the next day (when I query for the previous day’s data).

The Status display seems to always show the three logs in lockstep but I’ll specifically check next time it freezes.

I can get fooled by Imported and/or Exported not changing as changing solar generation and air conditioning usage can make them seem to be frozen but ironically I think it was frozen when I took this screenshot of the Status display a few minutes ago. Next time I’ll be more certain.

Message Log.txt (9.8 KB)

Looking back at the restarts since 7/31 in the log, the integrator was up to date at the time of the restart. So if there is a problem, it’s not the integrator stopping (didn’t think that was possible anyway).

If it happens again that you think the query is returning low results, please run a Graph+ of the four entities before any restart. Be sure to select Wh and check the accrue box for each. Time period would be “today”.