You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've done a search, but cannot see that anyone else is experiencing the same.
I've been using this add-on for a long time, but a couple of things have changed in my setup in this time, so not sure when the problem came in.
I'm using dev-edge version.
I have a Sunsynk 8kw on SW version M 6.0.1.4 / S 1.7.2.4 / C E.4.3.D
At some stage I had lightning damage, and my communication board on the Inverter got replaced, I've also moved from one usb-to-RS485 device to the waveshare one.
I also changed from umodbus to pymodbus at some point, but I think either works.
I have no problem reading any sensors.
My problem comes in writing sensors. A couple of seconds after writing a sensor, the value gets restored to what it was before.
I've fed the detailed debug logs through Claude, which seems to think the Write is successful, but then the value is overwritten/replaced with what Sunsynk Cloud had as its lost value.
I'm specifically trying to write to the progX_capacity sensors.
Anyone else experiencing similar?
Here's Claude's diagnosis:
Here's exactly what happens in the log:
10:47:51 — The MQTT callback fires when you set prog3_capacity to 31:
MQTT: topic SS/ss/prog3_capacity_set, async callbacks: ['on_change']
MQTT: Publish 1R SS/ss/prog3_capacity, 31
10:47:53 — The add-on writes value 31 (0x1f) to register 270 (0x10E) using modbus function code 16 (write multiple registers):
send: 0x0 0xc0 0x0 0x0 0x0 0x9 0x1 0x10 0x1 0xe 0x0 0x1 0x2 0x0 0x1f
The inverter responds with a successful write acknowledgement:
decoded PDU function_code(16 sub -1) -> WriteMultipleRegistersResponse(dev_id=0, transaction_id=0, address=270, count=1)
10:47:53 — The add-on immediately reads register 270 back and confirms it's 31:
Request registers: [270] glen=1. Response [31] len=1. regs={270: 31}
prog3_capacity=31% (31,)
10:47:57 — On the next poll cycle (~5 seconds later), register 270 still reads 31. The value is holding on the inverter.
10:48:12 — About 20 seconds after the write, register 270 suddenly reads 30 again:
prog3_capacity=30% (30,)
MQTT: Publish 1R SS/ss/prog3_capacity, 30
This confirms the inverter accepted the write, held it for ~20 seconds, and then something pushed it back to 30. That's the Sunsynk cloud server overwriting your local change. The cloud periodically syncs its stored settings to the inverter, and since the cloud still has 30 stored, it pushes 30 back down.
It suggests unplugging my Sunsynk Dongle, which isn't really a solution for me.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Hi
I've done a search, but cannot see that anyone else is experiencing the same.
I've been using this add-on for a long time, but a couple of things have changed in my setup in this time, so not sure when the problem came in.
I'm using dev-edge version.
I have a Sunsynk 8kw on SW version M 6.0.1.4 / S 1.7.2.4 / C E.4.3.D
At some stage I had lightning damage, and my communication board on the Inverter got replaced, I've also moved from one usb-to-RS485 device to the waveshare one.
I also changed from umodbus to pymodbus at some point, but I think either works.
I have no problem reading any sensors.
My problem comes in writing sensors. A couple of seconds after writing a sensor, the value gets restored to what it was before.
I've fed the detailed debug logs through Claude, which seems to think the Write is successful, but then the value is overwritten/replaced with what Sunsynk Cloud had as its lost value.
I'm specifically trying to write to the progX_capacity sensors.
Anyone else experiencing similar?
Here's Claude's diagnosis:
Here's exactly what happens in the log:
10:47:51 — The MQTT callback fires when you set prog3_capacity to 31:
MQTT: topic SS/ss/prog3_capacity_set, async callbacks: ['on_change']
MQTT: Publish 1R SS/ss/prog3_capacity, 31
10:47:53 — The add-on writes value 31 (0x1f) to register 270 (0x10E) using modbus function code 16 (write multiple registers):
send: 0x0 0xc0 0x0 0x0 0x0 0x9 0x1 0x10 0x1 0xe 0x0 0x1 0x2 0x0 0x1f
The inverter responds with a successful write acknowledgement:
decoded PDU function_code(16 sub -1) -> WriteMultipleRegistersResponse(dev_id=0, transaction_id=0, address=270, count=1)
10:47:53 — The add-on immediately reads register 270 back and confirms it's 31:
Request registers: [270] glen=1. Response [31] len=1. regs={270: 31}
prog3_capacity=31% (31,)
10:47:57 — On the next poll cycle (~5 seconds later), register 270 still reads 31. The value is holding on the inverter.
10:48:12 — About 20 seconds after the write, register 270 suddenly reads 30 again:
prog3_capacity=30% (30,)
MQTT: Publish 1R SS/ss/prog3_capacity, 30
This confirms the inverter accepted the write, held it for ~20 seconds, and then something pushed it back to 30. That's the Sunsynk cloud server overwriting your local change. The cloud periodically syncs its stored settings to the inverter, and since the cloud still has 30 stored, it pushes 30 back down.
It suggests unplugging my Sunsynk Dongle, which isn't really a solution for me.
Beta Was this translation helpful? Give feedback.
All reactions