bmerry

I eventually convinced my installer that there was a problem. They replaced the CT coil and ran a new cable in a separate conduit, and it's now much more reliable. There is still about a 40W bias, but it's pretty consistent and I've just set my trickle feed to 40W to cancel it out.

I just tested it, and we're both right: setting the time-of-use power level to 0 does prevent exporting battery (actually it still discharges 100W), but if I have more load than PV then the difference comes from the grid rather than the battery. So I think to get what I want I'll need to add some dynamic control on my Raspberry Pi to switch modes based on whether load exceeds PV.

Oh right, I'd misunderstood which setting you meant. That does sound sensible - will give it a try. My one concern is whether that will also limit power from the battery to the load: if a thick cloud comes over and PV can't cover the load, I'd rather supply load from the battery than from the grid.

Surely that means it will run the battery down to zero by exporting from the battery, rather than disabling export? I do have a Raspberry Pi connected to the inverter, so I can easily enough schedule changes to settings.

Do Sunsynk (5kW) inverters have a system mode in which excess solar is exported rather than used to charge the battery, but without exporting power from the battery? Currently I have "Zero export", "Solar export" and "Priority load" enabled, which only exports once the batteries are full. I've tried disabling the "Zero export" option, but that causes power to be exported from the battery, which is not what I want. The reason I want this is that I have more PV capacity than the city allows me to export. So I'd rather export in the morning and charge the battery at mid-day (peak production hours) so that I don't lose out on generation capacity.

More specifically, I've worked out that S = sqrt((P1-P2)^2 + (Q1+Q2-Q3-Q4)^2). And I found https://clouglobal.com/the-four-quadrant-diagram-in-electricity-metering/ helpful in understanding why there are four Q values: basically it separately measures inductive and capacitive reactive power, during importing and exporting. I'm not convinced that formula is really meaningful: if you import 100W for t/2 minutes then export 100W for t/2 minutes (with no reactive power), then the average apparent power over t minutes is still 100W, not 0W.

Anyone know which values I should be comparing to my CT coil readings to check their accuracy? In other words, when the Sunsynk inverter reports grid power from the CT coil, is it reporting kW (active power) or kVA? Also, any idea how CoCT computes the bill from this? Does it bill for reactive power?

The specific CT coil in my installation is a CTSA016. Unfortunately the data sheet doesn't say whether it is an AC CT or a Hall effect sensor. I'm curious how accurate CTs are at low currents (1A or less). The IEC 61869-2 accuracy classes only specify accuracy down to 5% of rated current, which for my coil is 5A.

For a bit more detail, here's the plot I made, using a combination of data extracted from the Sunsynk telemetry and eyeballing the meter reading: each horizontal segment on the black line is the average power computed between two meter readings. Blue line is the CT coil reading (P-External-CT-L1), orange is grid power going into the inverter (P-L1), green is the absolute value of orange. If one ignores the large spikes (corresponding to the geyser running), the black line tracks the green pretty well. Also notice that at 2024-11-27 16:00, the coil value went up (I changed the trickle setting) while the meter usage went down. That's what convinced me that I've been exporting and the meter charges for exporting. I'm now using software and an RS485 connection to try to keep the orange line close to zero* by adjusting the trickle charge setting, and my meter is recording about 0.5 kWh per day (= 20W average). What do you mean by "high frequency" in this context? Presumably both the power cables and the cables carrying the CT coil current are 50 Hz? I've previously tried switching the non-essentials off at the DB, and it hasn't made any difference. There is a timer in the DB plus some LEDs for pilot lights/surge protection, but I'm pretty sure they're not drawing 200W (on the basis that I don't burn myself when I touch them).

I've got a Sunsynk 5kW single-phase inverter. I've always noticed the CT coil was a little off (compared to the meter), but recently after adding more panels I decided to dig further. My only non-essential loads are a geyser and stove, and the geyser is on a timer, so most of the time I'm sure there is no non-essential load. However, the inverter reports non-essential loads of between 200W and 500W, varying slowly over time. What's convinced me it's the CT coil is that if I check my meter readings (just manually noting them down every hour) they don't match up with the coil readings at all. Basically, that "non-essential load" is the coil over-reading. My installer keeps saying this is normal and that the Sunsynk coils are just not that accurate, or that it's electromagnetic interference (I've got about 10-15m of cable run between the DB and the inverter, and it's in the same conduit as the power cables). Is this sort of error really normal? It seems pretty high to me - if I wasn't correcting for the error by adjusting the trickle charge setting, I'd be exporting 5 kWh/day or more (and my meter charges me for export - still waiting for the AMI meter). Has anyone else had errors of this magnitude and managed to fix them? The two suggestions I've come across are to use a higher-quality cable (e.g. Cat 6 or 6A) between the coil and inverter, or to use a separate power measurement device with a Modbus connection to the inverter (e.g. https://www.sunsynk.org/post/eastron-meters-do-you-need-one). The latter sounds ideal, but could be difficult because my DB doesn't have any more space for such a device.

Sunsniff decodes the sensor values in the protocol when run on a router between the dongle and the internet. You can see a table relating offsets in the 292-byte packets to the modbus registers here. I never dug into the rest of the protocol (such as sending commands back to the dongle to modify inverter settings) because I ended up going with a Raspberry Pi and an RS-485 cable.

I'm not sure if it's relevant to your question, but what I did in https://github.com/bmerry/socit is that when I want to set the current minimum SoC, I construct a schedule which puts about a 15-minute window around the current time and sets the target SoC for that window (computed dynamically), and for all the other program slots I set a much more conservative minimum SoC (50% for me). That way, if something goes wrong (software crashes, RPi running the software dies, RS485 connection to the inverter fails etc) it will revert to the safe value (apart from 15 minutes a day) rather than depleting the battery because the dynamic control is unable to raise the minimum SoC in response to load shedding.

I've open-sourced some Rust code that I'm using to dynamically adjust the minimum battery level on my Sunsynk inverter, using information from EskomSePush to adapt to load-shedding. I know some people are already doing similar things with Node Red and/or Home Assistant, but this might be useful for someone wanting a light-weight self-contained solution. It tries to do some smart things to avoid cycling the battery unnecessarily. https://github.com/bmerry/socit

You might be thinking of https://github.com/bmerry/sunsniff. That runs on my router (which happens to be AsusWRT, but I imagine it would work on OpenWrt too).

This sounds pretty cool @RoganDawes. I've been thinking about going the RS485 route, but didn't really want to spend money on hardware for it when my current solution is working well enough. If reprogramming the original dongle will work that would be awesome. I'm a software guy so I have no idea how one would go about flashing the dongle. What tools would one need?

Ok, I went a bit further with my script and found matches for all the graphs the web interface shows (in the Custom tab) that isn't just all zeros. In some cases there are multiple matches because several plots are identical. P-pv is a slightly odd case because it mostly matches to offset 248, but is sometimes off by 1. The values in each entry are offset:scale:bias, and where there are multiple entries there are multiple matching offsets. What will still be interesting is to check which offsets are NOT matched (and not all zeros). @PLCguyalready spotted one bit in one field that seems to be a boolean for grid connectivity, but I don't think we know what the other bits are. Grid P-grid ['214:1.0:0.0', '216:1.0:0.0', '220:1.0:0.0'] Grid F-grid ['84:0.01:0.0'] Grid I-grid-L1 ['196:0.01:0.0'] Grid V-grid-L1 ['176:0.1:0.0', '180:0.1:0.0'] Grid Import ['78:0.1:0.0'] Grid Total Import ['82:0.1:0.0'] Grid Total Export ['88:0.1:0.0', '112:0.1:0.0'] Grid P-L1 ['210:1.0:0.0'] Inv P-inv ['222:1.0:0.0', '226:1.0:0.0'] Inv P-pv [] Inv F-ac ['260:0.01:0.0', '262:0.01:0.0'] Inv V-ac-1 ['184:0.1:0.0', '188:0.1:0.0'] Inv I-ac-1 ['204:0.01:0.0'] Inv DC TEMP ['106:0.1:-100.0'] Inv AC TEMP ['108:0.1:-100.0'] String I-pv-1 ['146:0.1:0.0'] String I-pv-2 ['150:0.1:0.0'] String V-pv-1 ['144:0.1:0.0'] String V-pv-2 ['148:0.1:0.0'] String Daily Production ['142:0.1:0.0'] String Total Production ['118:0.1:0.0'] Battery SOC ['244:1.0:0.0'] Battery T-bat ['240:0.1:-100.0'] Battery V-bat ['242:0.01:0.0'] Battery I-bat ['258:0.01:0.0'] Battery P-bat ['256:1.0:0.0'] Battery Capacity ['140:1.0:0.0'] Battery Today Charging ['66:0.1:0.0'] Battery Today Discharging ['68:0.1:0.0'] Battery Total Discharging ['74:0.1:0.0'] Battery Total Charging ['70:0.1:0.0'] Battery T-BMS ['290:0.1:-100.0'] Battery V-BMS ['286:0.01:0.0'] Battery V-Charge-BMS ['276:0.01:0.0'] Battery I-BMS ['288:1.0:0.0'] Battery I-Charge-Limit-BMS ['280:1.0:0.0'] Battery I-Discharge-Limit-BMS ['282:1.0:0.0'] Load P-load ['228:1.0:0.0', '232:1.0:0.0'] Load P-Load-L1 ['228:1.0:0.0', '232:1.0:0.0'] Load Daily Consumption ['94:0.1:0.0'] Load Cumulative Consumption ['96:0.1:0.0'] Meter P-External-CT-L1 ['214:1.0:0.0', '216:1.0:0.0', '220:1.0:0.0'] Meter P-External-CT-Total ['214:1.0:0.0', '216:1.0:0.0', '220:1.0:0.0']

I've starting hacking together a Python script to scrape the API for data and get it into a Pandas dataframe. I'm planning to use it to automate matching fields to the raw TCP data, but it could probably also be used directly as a source of data e.g. to stash it in a local time-series database. See https://gist.github.com/bmerry/1f9317485830e736974c98cb1e5fd3b5. At the moment it just prints the dataframe, so to be useful you'll need to extend it to do something with the data.

By the way, has anyone had their inverter long enough to charge/discharge/generate more than 6553.6 kWh? I assume the totals must actually be 32 bit, but until it ticks past that point it's going to be hard to say where the high bits are stored (assuming that they are stored, rather than reconstructed on the server side from history).

That mostly agrees with what I've found, at least on the fields where we both have something (see here), but for me 248-249 is PV power, not a frequency, and bytes 212-213 are always zero. So perhaps they change the fields around depending on the firmware version? I did dump out the initial communication. I'd hoped to see something like a JSON document mapping offsets to identifiers, but all I could clearly identify were a bunch of version information, serial numbers, the connection key (in plaintext, yay) etc. Maybe I should see what I can get out of the cloud API. If I can download a full day of data it'll be easier to match to what I capture with tcpdump (currently I'm doing the matching by eyeball comparison to the phone app).

Bytes 41 and 42 are always in the range 0-59 so I'm fairly sure they're the minute and second of the timestamp.

I've posted a very early version of my work on Github: https://github.com/bmerry/sunsniff. If anyone is interested, give it a go and let me know if it works for you.

I've written a bit of documentation for the capture tool, so while it's still pretty rough, I think it's ready for other people to try it out. See instructions at https://github.com/bmerry/sunsniff, and let me know if you run into difficulties, since that'll help me improve the instructions.

The whole setup seems to be a typical IoT security disaster. I haven't yet seen a way to change the Wifi password used to access that interface, which means anyone in my area could connect and start uploading firmware (maybe it has to be signed but given the rest of the security I wouldn't count on it) or routing the telemetry through their connection. Some of my fields agree with yours, but there do seem to be differences. For example, where you've indicated INV AC output load, it looks like I have battery voltage (V-Bat in the data logger app). Your battery voltage is my V-BMS (similar to but not quite the same as V-Bat). Your INV power I can't seem to match up to any of the custom graphs shown by the data logger. I'm wondering if the logger sends any metadata when it first connects to indicate which field is which. At some point I want to try deliberately break its TCP connection while still running tcpdump on the router so that I can see what the initial exchange looks like.

Yeah, seems to be the same as mine (identical hardware revision); I guess they just decided to slap their logo on it. For what you identified as battery capacity: is that in Ah? That does seem to fit with my battery.

That's the same model I have. Is your dongle also the unbranded one with red and green LEDs in it, or the Sunsynk-branded one?