I am out of town for most of this week so I’ll have to get back to you when I return.
I believe I do - I have a kit of electrolytic capacitors of various values.
Those values will probably be plastic film, not electrolytic.
I’m not so sure anymore. I just pulled some new data from my board and plotted it, comparing the “everything connected” case vs. the “everything disconnected” case. Everything connected means that the CT sensor leads are connected via my RJ-45 coupler and the AC input voltage is connected. Disconnected means neither the AC voltage input nor the CT sensor leads are connected. It’s strange that the average noise value with the leads connected is lower than the ADC “zero” level of 511, but if I remove the CT leads, the ADC output is a bit less noisy, but it’s at the proper “zero” level at 511.
My previous post where I shared the min and max values from noise pickup were just that: min and max. I ran the numbers again in a new dataset and this time compared the median to the average to get a better sense of how the noise is influencing my data. For instance, with the CT leads connected, the average reading for a single CT is 504.8, and the median is 505, which tells me that the noise is not really skewing a dataset of 2k samples that much.
C1 is a 10µF electrolytic capacitor.
You’re right. The smallest electrolytic capacitor I have is 0.1µF. The next smallest capacitor value I have is a 22pF ceramic. I still want to try adding a filtering capacitor and I can order either some plastic film caps or some small ceramic ones. Is one better than the other when it comes to filtering?
I’m seeing consistently low “zero” levels on all 4 of my CT channels when the CT leads are connected to the board and not surrounding a conductor. Over 2k samples, my average CT input values are at 504.8, 505.01, 500.87, and 504.08. These are raw ADC output values before any corrections are applied. With the CT leads disconnected from the board, the average CT input values are better, at 511.0, 511.2, 506.9, and 510.1.
The filtering capacitor is more a case of the value than the type, too high a value and you’ll add a phase shift that you’ll need to account for somewhere else, so you really want the smallest value that takes the worst of the noise out, whilst still leaving a reasonably faithful representation of the signal you want to measure.
I wouldn’t attach any significance to the average (d.c.) value that you measure. You’ll take that out in the maths anyway. The transformer (any transformer) can’t pass through a d.c. value, so any d.c. going into the ADC is false, and has to be removed to get the true value of the wanted signal - voltage or current. And bear in mind, that d.c. bias you’re putting in to make the negative swings of the signal fall within the ADC’s range is going to move about with temperature and all the other things that affect component values and their properties, so you can’t take out a fixed value, you need to measure it to remove it completely. (Post no. 63)
Ok, thanks! I went ahead and ordered a kit of plastic film capacitors. I’ll have 10nF, 22nF, and 47nF values, among others outside of the range you suggested. I’ll add one to a single CT input and see how it looks when they arrive in a few days.
In the meantime, I wanted to share the current state of my code. I have not really started building database implementation other than learning the basics of InfluxDB and brainstorming how I’m going to structure it. Maybe I’ll do some more of that this afternoon.
Thanks again for your support!
That’s one of the nice things about Influx. It’s “schemaless.”
Let’s say you’ve set it up to record Voltage, Power and Energy measurements, then later
you want to add Power Factor and Current measurements. No problem. All you need to do is start
sending the PF and I measurements to the same database you’re sending the V, W, and kWh
measuremets to. You don’t have to use the same database, i.e you could create another database
and send the measurements there if you wanted to, but you don’t need to.
Absolutely! I am figuring out which datasets will be my tags and which will be my fields - from what I’ve read, there is a performance difference between the two because tags are internally indexed, while fields are not. Both hold keys and values, but queries that contain filters can perform differently depending on if you’re filtering based on a field or on a tag.
You’ve got it!
I don’t use the tags, as I’m only interested in how the system is performing now vice how it performed
say a month or a year ago.
Have you looked at the Line Protocol docs?
This should help: InfluxDB schema design and data layout | InfluxDB OSS 1.7 Documentation
Since I’m monitoring both consumption and solar PV production, I will probably tag each CT sensor value as “production” or “consumption” so I can easily query based on each of these points. I’ll have 3 “consumption” CT sensors, and 1 “production” CT sensor.
I have - but the Python InfluxDB client I’m using has some higher level functions that I’ll likely be using, like taking a JSON object (aka, a Python dictionary datatype) and inserting it into Influx.
That is helpful. Thanks!
Yesterday afternoon I connected my power meter to the panel and did a quick sanity check on the numbers. The solar PV power reading was really low (about half of what it should be), which made me think it’s pushing power out at 240V and not 120V. A quick panel check confirmed that the solar inverter output is going into a 2-pole breaker. I also confirmed the output voltage by querying my inverter’s API as seen below:
{
"date": "2020-03-07 17:28:12",
"totalActivePower": 136.795,
"dcVoltage": 391.362,
"groundFaultResistance": 11000.0,
"powerLimit": 100.0,
"totalEnergy": 1.21233E7,
"temperature": 34.5895,
"inverterMode": "MPPT",
"operationMode": 0,
"L1Data": {
"acCurrent": 1.01013,
"acVoltage": 246.407,
"acFrequency": 59.9978,
"apparentPower": 248.837,
"activePower": 136.795,
"reactivePower": 207.863,
"cosPhi": 1.0
}
}
You might ask why I don’t just poll the inverter for the solar PV stats, and I have several reasons for not wanting to:
- It’s very slow, with 5 minute update intervals, and the most recent data I can pull is always 15 minutes old.
- It’s cloud based (so I’m actually polling the manufacturer’s website using a unique API key and site ID, not the inverter itself).
- Lastly, the manufacturer limits API queries to only 300 per day.
It’s neat that I can get data from the inverter, but I don’t want to rely on it.
To correct the solar PV reading, I simply added a multiplier (x2) in the power calculations for that particular CT sensor.
After connecting the CT leads to the panel, I performed another calibration by comparing the output of my AC clamp meter around each main in the panel and the output of my circuit’s measurements. When I did the initial calibration at my desk, my test load (heater) was only pulling about 650-700W. Now that I’m dealing with amounts 10x that, the calibration error was more evident. Was calibrating against the mains a bad idea? I remember the requirement of having a resistive load for calibrating, and my mains are probably far from that.
Here’s some sample output:
Solar : 7615.65 W | 30.93 A
Subpanel : 624.62 W | 5.39 A
L Main : -3777.17 W | 30.73 A
R Main : -3759.92 W | 30.66 A
Current Status: Producing
Solar Output: 7615.65 W | 30.93 A
Home Consumption: 703.18 W | 5.85 A
Line Voltage: 123.43 VDoubling your measured value of 123.43 and multiplying it against 30.93 A yields PV power
of 7635.38. Not far off the mark from your “Solar” measurement. (assuming a PF of 1.0 at that power
level. My system behaves that way, and AFAIK, most, if not all, do) Don’t know about you, but I sure
wouldn’t be too unhappy with an error that small. 
However, you may find your measurements at low power levels, especially when they’re less than 10% of the CT rating, may exhibit larger errors.
Your L Main and R Main measurement values appear to still be using 123.43 Volts for their respective calculations, i.e they should be very near to the PV measurement value.
Nice job! 
1 Like
I have to say that being independent can have distinct advantages. History tells that relying on something like that can result in a painful experience if the manufacturer decides you’ve got to pay up, or they cease trading.
That might not be absolutely accurate, but any error there should be small - 20 W in near enough 8 kW is, as Bill says, not bad at all.
Measurements at low power levels will depend very much on the quality of the c.t., especially its phase error. While the amplitude error does increase at low currents, the phase error can increase dramatically, and because we’re talking real power (or should be), the error does become significant.
You could possibly make your test load up to several kW by putting multiple turns through your c.t. I can easily manage 100 A: a 5 A, 6.5 V transformer and 20 turns gives me 100 A and 24 kW. The wire - it’s 16/0.2mm or so - gets a bit warm but at 6.5 V, it’s not dangerous and it’s only like that for a few seconds while I do a single measurement.
I’m stoked to have come this close with my lack of expertise!
Yes, unfortunately this is still my biggest concern. At zero power, the CT leads are picking up lots of noise (as discussed in post #77-85). I’m hoping the plastic film capacitors help take out some of the noise so I can specify a separate calibration factor for low power levels.
That’s correct - they are individual 120V legs of my 240V panel. Current will flow in either direction depending on whether or not I’m net-producing or net-consuming. I’ve designated the negative reading to mean I’m sending power back into the grid.
Thanks!
I agree - I much prefer the self-reliant route!
It’s been difficult to gauge my accuracy because the data I get from the inverter is about 15 minutes old. That makes real time comparisons impossible. However, now that my PV production has peaked for the day, I can compare the peaks in my monitor’s reading vs. the data I get from the inverter, and there is about a 150W difference. The peak reported by my Pi monitor is higher - 7.74kW - while the inverter shows me a peak of 7.59kW). I would tend to believe my Pi monitor over the inverter since I know exactly how the data is being calculated, but it’s hard to say. When I calibrated the Pi to the AC clamp meter, I noticed the reading on the clamp meter varied depending on the angle that the conductor passed through the clamp. The variance was only a few tenths of an amp, and I calibrated the Pi to the clamp meter when it was giving the highest reading. I would think that the meter is most accurate when the conductor is passing through the hole at a 90 degree angle relative to the clamp opening - so should I recalibrate to that? A few tenths of an amp at 246V could account for half of the 150W discrepancy between my monitor and the inverter!
That’s a great idea. I’ll do that in a few days when I take the Pi circuit back to my desk to add the plastic film capacitors.
What is the accuracy of your clamp meter? You can’t get better than that. It’s usually specified as a percentage of reading + a number of digits, so you have to calculate it at the actual reading.
You can’t get any instantaneous values from your inverter?
Might be worth asking “what is the accuracy of the inverter’s measurements?”
I say that because the Enphase microinverters I have, are spec’d at ±5%
His inverter specs may be tighter than that, but unless we know for sure…
My clamp meter is +/- 2.5% + 8 digits. I’m not sure how to apply that to the actual reading though.
Unfortunately, no. The inverter’s API updates only once every 5 minutes. For example, here’s the latest data I can get:
{
"date": "2020-03-08 15:53:11",
"totalActivePower": 4939.39,
"dcVoltage": 395.976,
"groundFaultResistance": 11000.0,
"powerLimit": 100.0,
"totalEnergy": 1.21712E7,
"temperature": 45.9941,
"inverterMode": "MPPT",
"operationMode": 0,
"L1Data": {
"acCurrent": 19.8432,
"acVoltage": 249.341,
"acFrequency": 59.99,
"apparentPower": 4949.09,
"activePower": 4939.39,
"reactivePower": 309.6,
"cosPhi": 1.0
}
},
{
"date": "2020-03-08 15:58:11",
"totalActivePower": 4781.97,
"dcVoltage": 396.306,
"groundFaultResistance": 11000.0,
"powerLimit": 100.0,
"totalEnergy": 1.21716E7,
"temperature": 45.5464,
"inverterMode": "MPPT",
"operationMode": 0,
"L1Data": {
"acCurrent": 19.1896,
"acVoltage": 249.37,
"acFrequency": 59.985,
"apparentPower": 4786.74,
"activePower": 4781.97,
"reactivePower": 213.696,
"cosPhi": 1.0
}
}
Great point - my inverter is a SolarEdge SE10000H-US. The datasheet suggests it has an accuracy of 1% (I don’t have the revenue-grade 0.5% accuracy model).
Like it says!
Using one of your numbers above: 30.93 A
+2.5% = 31.70325, which will be rounded to 31.70, then add 8 digits = 31.78
-2.5% = 30.16 (rounded), then subtract 8 digits = 30.08
So the “real” error is more like 2.75% at that reading.
And the actual current could be anywhere between 30.08 A & 31.78 A - and that’s if your meter is in calibration.
If your meter happens to be at one end of its tolerance band and the inverter happens to be at the opposite end of its, then you could have a 3.75% discrepancy measuring the same thing.
1 Like
I see, thanks!
@Bill.Thomson, how do you structure your influxDB measurements?
I setup my tables with the following schema and it doesn’t seem to be working out for me when I try to write a query with some adds and subtracts. I’m storing my voltage readings in a completely separate table/measurement because they’re not really needed here.
> select * from energy order by time desc limit 10;
name: energy
time ct_sensor current real_power
---- --------- ------- ----------
1583853565132000000 3 2.876795337520502 -236.9910884525767
1583853565132000000 2 2.898788124366999 -246.48679771561115
1583853565132000000 1 3.372243436955877 287.74756857151147
1583853565132000000 0 3.403629982447483 649.0341395463205
1583853560152000000 3 2.858149466960662 -233.27431335645466
1583853560152000000 2 2.87897577210441 -244.78477766596475
1583853560152000000 1 3.375859975734488 289.99795128901275
1583853560152000000 0 3.404092818821192 652.9205395065735
1583853554879000000 3 2.8312179678114178 -228.6892347824164
1583853554879000000 2 2.883386367353047 -244.7300126740809
… where current and real_power are my “fields”, and ct_sensor is a tag.
I’m thinking I will need to restructure the schema for my measurements, but I wanted to see if you had any insight. The specific problem I’m having is in order to calculate what my home is using, I have to subtract the amount of power that my PV system generates from what I am sending back into the grid, then add the power from my subpanel. The InfluxDB math section doesn’t mention performing operations by selecting via tag, only fields. My searches for similar issues haven’t really turned up much, but it looks like nested queries and groupings deserve further exploration before restructuring.