sma-si.modbus: nach update > 0.202.1 sma island modbus probleme

[Gpunkt417]

Describe the bug

Bitte ermöglicht "timeout" in Templates des sma-si-modbus .
Mein SMA Island benötigt mehr Zeit ;)
Oder gibt es da andere Möglichkeiten ?
Downgrade auf 0.202.1 behebt den Fehler

Steps to reproduce

1. Update 0.202.1 -> >= 0.203.0

Configuration details

- type: template
  template: sma-si-modbus 
  id: 3
  host: 192.168.1.176
  port: 9001
  usage: battery
  modbus: tcpip
  capacity: 22
  watchdog: 60s
  chargepower: 4200
  name: battery4

Log details

[site ] DEBUG 2025/04/15 08:56:44 battery 1 power: -4560W
[site ] ERROR 2025/04/15 08:56:45 battery 1 energy: read failed: read tcp 192.168.1.222:41588->192.168.1.176:9001: i/o timeout
[site ] ERROR 2025/04/15 08:56:46 battery 1 soc: read failed: read tcp 192.168.1.222:41602->192.168.1.176:9001: i/o timeout

What type of operating system or environment does evcc run on?

Linux

External automation

• I have made sure that no external automation like HomeAssistant or Node-RED is active or accessing any of the mentioned devices when this issue occurs.

Nightly build

• I have verified that the issue is reproducible with the latest nightly build

Version

0.203.0

[andig]

Schau mal bitte hier Zwecks Parameter: #20247 (reply in thread)

[Gpunkt417]

Fehler ist weiterhin vorhanden, wenn auch nicht so häufig
Kein Fehler mit 0.202.1

[andig]

Hättest du nochmal ein trace log davon für aktuelle Version?

[Gpunkt417]

reicht das so ?

[sunspec] TRACE 2025/04/23 16:58:21 model 103 block 0 point WH: 1.3975811e+07
[pv2 ] TRACE 2025/04/23 16:58:21 modbus: recv 11 77 00 00 00 07 03 04 04 00 00 02 c8
[site ] DEBUG 2025/04/23 16:58:21 pv 1 power: 712W
[pv2 ] TRACE 2025/04/23 16:58:21 modbus: send 11 78 00 00 00 06 03 03 77 31 00 04
[pv2 ] TRACE 2025/04/23 16:58:21 modbus: recv 11 78 00 00 00 0b 03 03 08 00 00 00 00 04 6e ec c8
[site ] DEBUG 2025/04/23 16:58:21 pv power: 4198W
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pvEnergy: '88354'
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pvPower: '4198'
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/2/controllable: ''
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv: '2'
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/1/title: ''
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/1/icon: ''
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/1/power: '712'
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/1/energy: '74378'
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/1/powers: ''
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/1/currents: ''
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/1/excessDCPower: ''
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/1/capacity: ''
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/1/soc: ''
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/1/controllable: ''
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/2/title: ''
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/2/icon: ''
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/2/power: '3486'
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/2/energy: '13976'
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/2/powers: ''
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/2/currents: ''
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/2/excessDCPower: ''
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/2/capacity: ''
[mqtt ] TRACE 2025/04/23 16:58:21 send evcc/site/pv/2/soc: ''
[sma ] TRACE 2025/04/23 16:58:21 recv 192.168.1.173: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma ] TRACE 2025/04/23 16:58:22 recv 192.168.1.173: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[db:3 ] TRACE 2025/04/23 16:58:23 modbus: recv 1a 4c 00 00 00 07 03 04 04 ff ff ff 7e
[site ] DEBUG 2025/04/23 16:58:23 battery 1 power: -130W
[db:3 ] TRACE 2025/04/23 16:58:23 modbus: send 1a 4d 00 00 00 06 03 03 77 31 00 04
[sma ] TRACE 2025/04/23 16:58:23 recv 192.168.1.173: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[httpd ] TRACE 2025/04/23 16:58:24 GET /api/system/log
[sma ] TRACE 2025/04/23 16:58:24 recv 192.168.1.173: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[sma ] TRACE 2025/04/23 16:58:25 recv 192.168.1.173: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[db:3 ] TRACE 2025/04/23 16:58:26 modbus: close connection: read tcp 192.168.1.222:46680->192.168.1.176:9001: i/o timeout
[site ] ERROR 2025/04/23 16:58:26 battery 1 energy: read failed: read tcp 192.168.1.222:46680->192.168.1.176:9001: i/o timeout
[db:3 ] TRACE 2025/04/23 16:58:26 modbus: send 1a 4e 00 00 00 06 03 03 78 7d 00 02
[sma ] TRACE 2025/04/23 16:58:26 recv 192.168.1.173: [proto.GroupPacketEntry, proto.SmaNet2PacketEntry]
[httpd ] TRACE 2025/04/23 16:58:27 GET /api/system/log

[andig]

port: 9001

Wo kommt denn dieser schräge Port her?

Aktuell haben wir https://github.com/evcc-io/modbus/pull/14/files#diff-49830af181541bc76c8bca9e4401d808240a559716536397ae4d22947acddf32R25 3s timeout. Wir können natürlich auch nochmal 10s versuchen, wobei man sich schon fragen muss, was das Ding so lange tut...

[Gpunkt417]

Das ist ein Modbusproxy.
Wie war denn der Timeout vorher ? Da lief es ~ 1 Jahr ohne eine Fehlermeldung
der SMA Island hat bei Modbus wohl manchmal ein bisschen "lähmung" was mit einem Systemneustart für Zeit X etwas bringt, aber nach einer gewissen Zeit ist es wie vorher. evcc ist aber nicht der einzige Modbuszugriff auf den SMA Island.

[christoph-ng]

I got i/o timeout's after 10s, too.
evcc | 2025-04-28 10:45:45.895287848 +0200 CEST m=+2795.094897263 !! 10000ms read failed: read tcp 127.0.0.1:59476->127.0.0.1:5021: i/o timeout

[andig]

Bis 201 haben wir das Errorhandling der Modbus Library verwendet. Leider funktioniert das nicht mit Geräten, die von sich aus die Verbindung nach kurzer Zeit schließen (z.B. Varta). Daher haben wir das in 202 komplett ausgebaut und durch eine einfache Lösung ersetzt: bei Fehler Verbindung schließen und Retry. Das klappt, solange der Fehler innerhalb der Retryzeit auftaucht (5s), was hier aber nicht passiert da der Timeout schon den kompletten retry aufzehrt.

Jetzt muss die Ursache gefunden werden. Einfach nur "warten" scheint nicht zu reichen da das Gerät auch bei hohem Timeout nicht antwortet. Falls es eine Möglichkeit gäbe, den Fehler zu reproduzieren (evcc meter) dann könnte ich das debuggen. Ohne Möglichkeit zum reproduzieren nutzt leider auch Remotezugang nichts.

Und natürlich sollte SMA in der Lage sein, hier sinnvollen Input zu geben...

[Gpunkt417]

Also bei mir läuft es jetzt nach dem Update auf 203.4 (10s Timeout) Danke!

[andig]

Probier bitte mal, ob .5 immer noch geht :/

[Gpunkt417]

sorry für die verzögerte Rückmeldung.
ja es geht, in Einzelfällen gibt es da mal einen Fehler, aber da sehe ich keine Problem drin.