Sungrow SG5KD Works for a few hours and then fails

[mhoroschun]

Hi Everyone

Just wondering if anyone is having this fail after a few hours running?

I'm running a 60 second scan_interval.

For a while, I get:

DEBUG:pymodbus.transaction:SEND: 0x0 0x4 0x0 0x0 0x0 0x6 0x1 0x4 0x13 0x88 0x0 0x64
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
DEBUG:pymodbus.transaction:RECV: 0x0 0x4 0x0 0x0 0x0 0xcb 0x1 0x4…. etc…

Then a few hours later:

DEBUG:pymodbus.transaction:SEND: 0x0 0xd 0x0 0x0 0x0 0x6 0x1 0x4 0x13 0x88 0x0 0x64
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
DEBUG:pymodbus.transaction:RECV: 0x0
DEBUG:pymodbus.framer.socket_framer:Processing: 0x0
DEBUG:pymodbus.factory:Factory Response[0]
ERROR:pymodbus.factory:Unable to decode response Modbus Error: Unknown response 0
ERROR:pymodbus.transaction:Modbus Error: [Input/Output] Unable to decode request

I thought it might have something to do with the way SungrowModbusTcpClient caches the key. But killing the process and starting it again doesn't solve the problem.

It appears to just start working again some time later.

Anyone else experience this, or is it just me?

[mhoroschun]

Downgrading pymodbus as per #45 seems to resolve this for me. Now it works mostly, however it still seems to go offline overnight and doesn't respond again until some time in the morning

[mhoroschun]

So, I think I finally figured out why this stops working after a while. The SungrowModbusTcpClient.py stores the day that it retrieves the comms key and won't renegotiate a new key until the next day. It appears as though the key valid period is shorter than this, so at some stage, the key is no longer valid and communications fails.

For the moment, restarting the solariot.py script hourly resolves the problem.

I'm running mine on K8s on Raspberry Pi using the below config and its now solid and reliable. Note the livenessProbe to restart hourly. This is using my version of the docker image which has pymodbus pinned to 2.4.0

Next I'll try to update Sungrow-Modbus to refresh the key hourly or perhaps after the established key fails at the bottom of connect().

---
apiVersion: v1
kind: Namespace
metadata:
  name: solariot
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: solariot-configmap
  namespace: solariot
data:
  config.py: |
    inverter_ip = "192.168.0.1"
    inverter_port = 502
    model = "sungrow-sg5kd"
    timeout = 10
    scan_interval = 450
    slave = 0x01
    mqtt_server = "192.168.0.2"
    mqtt_port = 1883
    mqtt_topic = "inverter/stats"
    mqtt_username = "inverter"
    mqtt_password = "password"
---
apiVersion: v1
kind: Pod
metadata:
  namespace: solariot
  name: solariot
spec:
  containers:
  - name: solariot
    image: mhoroschun/solariot:latest
    volumeMounts:
    - name: solariot-config
      mountPath: /config
    livenessProbe:
      exec:
        command:
        - /bin/sh
        - -c
        - "end=$(date -u +%s);start=$(ps -p 1 -o etimes --no-headers | awk '{print int($1)}'); test $(($end-$start)) -lt 3600"
      failureThreshold: 1
      initialDelaySeconds: 3600
      periodSeconds: 60
  volumes:
  - name: solariot-config
    configMap:
      name: solariot-configmap

[m-chandler]

Having the same issue with my SG5KD. I just added a cron to restart the solariot docker container every hour.