I’m dubious. Are you saying that you put two CTs on the same wire and they read exactly opposite?
That just doesn’t make sense. The Utility meter is showing nothing. You had mentioned a one-hour time skew. Can you post the Device setup display with UTC offset and DST setting and also tell me what your time-zone is? When you look at the IoTaWatt message log, do the timestamps match your local time?
I did put the same wire through two CTs.
The two solar systems and the pool are located on a sub-panel.
All 9mm CT were positioned exactly in the same way, that is the side with the writing oriented toward the CB where its respective wire is connected to.
Unlike the other CTs there’s no markage on how they should be connected, so I arbitrarily chose that.
One of them read differently than the others. At first I thought I had connected it wrong, so I re-opened the panel again to check. But it was right.
Seeing that the polarity can be changed in the iotawatt interface, I didn’t investigate further.
My guess is that an error was made when my meter was replaced earlier this month. The readings for the last Friday and Saturday make no sense. It shows almost 0 export when it was a nice sunny day, at 28C.
I have taken measurements every 30 minutes yesterday for 6 hours, and what I read on their site doesn’t match the value I recorded.
I have now removed the Tesla wiring to go from the common CTs and instead go through their own clamp. did manage to fit them all in the end, just a small gap present with the panel cover.
This is what I now have for output definition.
Sounds like you are asserting that they are oriented the same way with respect to the breaker on different wires. I was asking if you ever put them both on the same wire and observed equal but opposite readings.
There are other explanations for negative readings in a three phase system. Potentially the phase assignment is incorrect. If you plot the two solar inputs individually in Graph+ for a day (or more) and compare to the output indicated by the individual inverters, is one correct and the other not so much? Also, what are the power factors for each when they are producing?
that’s what I’m saying yes. I have no other point of reference to determine the current flow direction.
I could do that, but I’m fairly certain of what the result of this test would be.
Here is a reading example/
At 2:47PM local time this is what the inverters were reporting (I poll ever 10s and average over one minute.
Solar1 : 518W
Solar2: 1139W
http://iotawatt.local/query?select=[time.utc,Solar1,Solar2]&begin=2020-03-30T03:46:00Z&end=2020-03-30T03:47:00Z&group=m&format=csv
2020-03-30T03:46:00, -605.5, -1236
Graph from iotawatt compared to the graph I draw with RRD tool , reading directly from the inverter.
The iotat uses 2m average, while rrd use 5minutes, so the peak won’t be as high with the 2nd graph, you can see that it’s pretty similar still
0.99 and 1.00 typically
Ok.
Problem solved.
Tonight I did just that. And they all read the same.
So my explanation now is the load on this CB is opposite to the others.
All CBs on this panel have their bottom connector leading to the main. But on this particular one, it’s the top connector that goes to the main.
So the current flow appears reverted if you place the clamp on the wire going to the CB.
I’m not sure if this is per AS3000 spec. Certainly makes for some dangerous assumption if you believe that turning of the CB let you disconnect the top wire like I had always assumed!
I’ll check with my electrician tomorrow.
""I set Import as Phase1 + Phase2 + Phase3 + Pool + Solar1 + Solar2 max 0
And Export as: Phase1 + Phase2 + Phase3 + Pool + Solar1 + Solar2 min 0“”
please, correct me if i m wrong: usual, this kind of mathematics, when you use max 0 or min0 need to be as usual in matematics.
( Solar1+Solar2) max0 or min0. the result is different from the first formula between “”
IoTaWatt scripting does not apply operator hierarchy and evaluates left to right, but parenthesis do cause the expression within to be evaluated separately. The example above would evaluate differently with and without parenthesis if the min and max functions were evaluated before +, but it is not.
While parenthesis are recommended anyway, I regret not having implemented operator hierarchy initially. Doing so now would introduce incompatibility. It’s not impossible, but much more difficult.
indeed not having the usual operators priority made me struggle at stuff.
The issue I’ve had in the past is that when using parenthesis, even correctly placed and closure matching opening; intermittently the “save” button wouldn’t re-appear.
I can’t consistently reproduce the problem.
In regards to forward compatibility, what about adding an extra flag for each entry that if checked it uses the old calculation method. For new ones, it’s cleared by default.
The flag would be set to all previous entries.
When you make a claim like that, you should have an example. If you can reproduce it at all, consistently or not, take a screenshot. I fix bugs that are demonstrated. Over the past two years I’ve never had anyone report a problem with the parenthesis.
Set some flags and have two different evaluation rules? I don’t think so.
I did try to reproduce it before hand of course. I couldn’t rule out a web browser issue.
Well ultimately there would be none left, or one always set. That there are no operator priority is the most puzzling thing ever.
Particularly as I don’t believe this was documented anywhere.
Perfect is the enemy of good. The script system was intended as a way to add and subtract inputs to aggregate and calculate differences. Addition and subtraction are associative, so no need for hierarchy. In the rare cases where multiplication is used, parenthesis are available. This is not a computer with unlimited resources. Operator hierarchy requires essentially compiling the expression into reverse polish or other stack algorithm. Parenthesis allow direct evaluation because they define priority operators before their operands can be incorporated into another lower priority operation. It’s a balance between efficiency, utility and return on development resources and complexity. Perhaps the Script system will be extended in the ESP32 implementation where there are more resources and script evaluation doesn’t have to be sliced up into the spare time between power monitoring.
https://docs.iotawatt.com/en/master/outputs.html
This is the calculator interface that IoTaWatt uses to specify how to calculate an output using input channel values. A script is created that IoTaWatt uses to compute the value when needed. It works just like the simple four function calculators we are all used to, and using the input key, you can select input channel values to be used in the formula that you are creating. The resulting expression is evaluated left to right, with calculations within parenthesis evaluated before being used.
Thank you all for your comments.
Using the query API I now can integrate this data in my own RRD monitoring.
Not as pretty as the iotawatt internal graph that’s for sure:
I calculate the import/export energy from the minute average returned by the iotawatt.
The solar data comes directly from the two inverters however as it has an energy accrual counter over RS485 which is likely much more accurate than sampling the wattage.
Short update.
Turned out the 3-phase power meter installed earlier last month was badly programmed and it got reflashed on Monday by a technician.
I’ve had pretty good accuracy since (April 7th)
calculated - measured
21.73kWh - 21.8kWh import
2.31kWh - 2.3kWh export
20.77 - 20.8 import
6.42 - 6.4 export
28.54 - 29.6 import
13.90 - 13.8 export
20.39 - 20.4 import
5.91 - 5.9 export
27.48 - 27.6 import
7.70 - 7.8 export
So within 1% of the official figure.
Export is calculated by looking at the minute average obtained from the iotawatt for the main on all phases and the accumulated energy export obtained from the solar inverters.
Own system (one hour average)
utility: (30 minutes average)
