Solaredge: "cannot create meter" nach FW-Update

[softservicegit]

Describe the bug

evcc startet nach dem update nicht mehr. Config ist unverändert.

Steps to reproduce

1. update auf 0.132.1

...

Configuration details

meters:
  - name: solaredge_grid
    type: template
    template: solaredge-hybrid
    usage: grid
    modbus: tcpip
    id: 1
    host: 192.168.10.6 # Hostname
    port: 526
    timeout: 3s

Log details

Using config file: /config/evcc.yaml
starting evcc: 'EVCC_DATABASE_DSN=/data/evcc.db evcc --config /config/evcc.yaml'
[main  ] INFO 2025/01/08 08:10:28 evcc 0.132.1
[main  ] INFO 2025/01/08 08:10:28 using config file: /config/evcc.yaml
[main  ] FATAL 2025/01/08 08:10:37 cannot create meter 'solaredge_grid': cannot create meter type 'template': cannot create meter type 'custom': power: read tcp 192.168.10.67:47702->192.168.10.6:526: i/o timeout
[main  ] FATAL 2025/01/08 08:10:37 will attempt restart in: 15m0s

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

Linux

Nightly build

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

Version

0.132.1

[softservicegit]

auch nach dem downgrade auf 0.132.0 kommt der selbe Fehler.
Die letzte Änderung, die in der Richtung passiert ist, ist das update des WR auf die aktuelle Version 4.22.44.

[StefanSchoof]

read tcp 192.168.10.67:47702->192.168.10.6:526: i/o timeout

Da antwortet dein solaredge nicht. Schon versucht den einmal neu zu starten?

[premultiply]

Da antwortet nur der WR nicht (mehr).
Nix für uns zu tun.

[softservicegit]

Ich gebe zu, meine log Auszug war - wie es immer so ist - völliger Blödsinn und am Thema vorbei.

Richtig ist folgendes:
starting evcc: 'EVCC_DATABASE_DSN=/data/evcc.db evcc --config /config/evcc.yaml' [main ] INFO 2025/01/08 10:00:36 evcc 0.132.1 [main ] INFO 2025/01/08 10:00:36 using config file: /config/evcc.yaml [mqtt ] INFO 2025/01/08 10:00:36 connecting evcc-1170240778 at tcp://mqtt.sartool.de:1883 [mqtt ] DEBUG 2025/01/08 10:00:36 tcp://mqtt.sartool.de:1883 connected [main ] INFO 2025/01/08 10:00:36 listening at :7070 [main ] FATAL 2025/01/08 10:00:39 cannot create meter 'solaredge_grid': cannot create meter type 'template': cannot create meter type 'custom': power: sunspec model not found: [{203 0 W}] [main ] FATAL 2025/01/08 10:00:39 will attempt restart in: 15m0s

[premultiply]

power: sunspec model not found: [{203 0 W}]

Der WR liefert keine Daten des Grid-Meters mehr im erwarteten SunSpec Modell 203.

Ich würde mal tippen das Gerät braucht einen Neustart, die Konfiguration wurde verändert oder die Firmware ist anderweitig ganz kaputt.

[softservicegit]

Danke, ich teste. und melde mich

[andig]

Hilfreich wäre das trace log von

evcc sunspec

dann sehen wir auch, was das Gerät neuerdings glaubt bzgl Sunspec zu können.

[Ph1975]

hatte eine sehr ähnliche / analoge Fehlermeldung gestern mit meiner Keba Wallbox. Musste sie neu starten, danach hat alles wieder geklappt.

[aovaron]

Hatte das gleiche nach dem Update.
Tatsächlich hat ein Neustart des WR was gebracht.

[salvisbh]

Gleiche Beobachtung, beliebig reproduzierbar und ein Workaround in Docker erkannt. Ich habe heute erstmals den integrierten Modbus-proxy aktiviert und betreibe evcc in Docker mit Macvlan-Netzwerk-Treiber, damit ich keine Portmappings erstellen muss und evcc als eigener Host im Netzwerk erscheint.
Wenn ich ein docker restart ausführe, bleibt evcc bei mir während dem Start mit der gleichen Fehlermeldung hängen, der Modbus-Proxy läuft jedoch im Hintergrund perfekt (hm, oder perfekt weiter?). Was interessant ist: Meine anderen Geräte wie Homeassistant etc. welche via Modbus-Proxy auf meinen Solaredge Hybrid-Inverter zugreifen, können weiterhin via Proxy problemlos mit dem Inverter kommunizieren, diesen aktiv steuern sowie auch mit dem Solaredge Meter und der BYD Batterie kommunizieren. Einfach der evcc hat sich irgendwie verschluckt und kriegt die Verbindung nicht mehr hin.

Mein leider nicht automatisch wiederanlauffähiger Workaround:

• Docker compose down --> evcc Container wird gestoppt und in Docker komplett abgeräumt.
• Docker compose up --> evcc Container wird neu erzeugt und gestartet, evcc inklusive Modbus-proxy laufen perfekt.

Für mich schmeckt es danach, dass der Modbux-Proxy beim stoppen nicht alle Resourcen sauber freigibt. Ich kann dies leider nicht beweisen, da ich momentan als Java-Spezi noch nicht wirklich in der Lage bin, evcc als Go - Service zu debuggen.

[salvisbh]

Ich hoffe ja auch, dass es nicht eine Inkompatibilität von Docker handelt. Ich habe dies nur erläutert, damit ihr es besser einschränken könnt. In einem Satz: "Ein schneller Restart des evcc, ungeachtet davon, ob er direkt oder via Modbus-Proxy mit mit Solaredge sprechen will, fliegt auf die Nase und bleibt endlos hängen. Erst ein kompletter Prozesskill lässt ihn wieder verbinden. Der Modbu-proxy hat diese Probleme nicht."

[salvisbh]

Ich habe kein Ticket bei Solaredge erstellt, da ja sämtliche anderen Clients das Problem nicht haben, weder homeassistant, evcc-modbusproxy, andere Modbusproxies und co. Nur evcc kommt damit nicht klar. Wie sol ich dies Solaredge erklären?

[andig]

Der Modbu-proxy hat diese Probleme nicht."

Nochmal: das ist völlig irrelevant. Denn der macht keine Requests ohne Client. Darfst du mir ruhig glauben.

[andig]

Und: es werden alle Clients das Problem haben die schnell Verbindungen aufbauen. Welche hast du denn von dieser Sorte getestet?! Aber wenn du eine bessere Idee hast kannst du natürlich auch die verfolgen. Was weiss ich schon.

[salvisbh]

Ich greife mit drei Clients auf Solaredge zu:

• Homeassistant
• Solarmanager
• evcc
  Die ersten zwei funktionieren fehlerfrei.
  Für den Parallelzugriff habe ich auf den integrierten Modbus-proxy von evcc gewechselt, da ich hier am wenigsten Inkompatibilitäten erwartet habe und gemäss meinem Monitoring scheint dies wirlich der stabilste Proxy meiner getesteten Varianten zu sein.
  Wenn du mir sagen kannst, was ich im Ticket für Solaredge fomulieren soll, mache ich dies selbstverständlich gerne. Schliesslich möchte ich nach Möglichkeit etwas zur Problemlösung beitragen. Ich bin leider selber zuwenig Hardwarenah unterwegs und sehe mich nicht in der Lage, Solaredge da etwas wertvolles zu kommunizieren.

[softservicegit]

Bei mir ist es jetzt seit gestern Abend - nach einem Neustart der Wechselrichter - durchgelaufen.
Mein Gefühl ist auch, das da irgendeine Verdindung offen gehalten wird. Alles andere konnte in der Zeit ohne Probleme auf die modbus Schnittstelle zugreifen. Alles über den selben modbus proxy. Ich nutze dafür nicht den aus evcc.

ich hatte moch ein trace log im notepad++ offen. ist hier angehängt,

evcc_sunspec_trace_2025-01-08.txt