bmerry

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.

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'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

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

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).

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.
 

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.

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.

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.

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.