Proxy für Anfänger... evcc führt Selbstgespräche :) Solaredge und andere

[RandomRam2023]

Erfahrungsbericht aus dem Fachsimpeln mit einem kundigen Kollegen (also er eher Fach, ich eher Simpel):
Kernaussage; irgendwie hat der proxy nur "halbgar" gearbeitet, die Lösung (siehe unten) hat mich überrascht.

Mein PV-WR ist ein Solaredge, bekanntermaßen zickig bzgl. mehreren ModBus-Master, also evcc als Proxy einrichten als Lösung.

Suboptimales Ergebnis: beide Regler (Hausbatterie-Lademanagement und evcc-Auto-Überschuß) arbeiten korrekt und effizient. Jedoch konnten recht zufällig (jeden Tag/Neustart mal anders) entweder evcc die PV-Leistung erkennen, anzeigen und schön regeln und der Speicher war blind (kann aber trotzdem auf Gridleistung arbeiten) oder evcc hat rein auf Gridleistung geregelt und der Speicher hat schön die PV-Leistung und den Hausverbrauch gezeigt. Kosmetikproblem, denn in Summe waren beide Regler funktional zielführend in Aktion und haben jeweils Geld gespart, was will man mehr (hüstel..naja, dass es besser aussieht, wie wär’s damit?)

Die dazugehörige Konfig (evcc.yaml (Ausschnitt) war:
[...snip...]
[...meters]

• name: solaredge_pv #so wie in den Vorlagen zu Solaredge
  type: template
  template: solaredge-inverter
  usage: pv
  modbus: tcpip
  id: 1
  host: Solaredge.fritz.box # evcc frägt den PV-WR direkt an <<<=====
  [ in meinem Netz arbeitet ich mit sprechenden hostnames, Auflösung auf IP-adressen macht die Fritzbox...
  [ diese Einbindung hat "vor" Proxy gut gearbeitet, aber alle anderen Master rausgeworfen
  port: 1502 # modell SE5K

Modbusproxy:

• port: 1502
  uri: SolarEdge.fritz.box:1502 # Umleitung für den Speicher über evcc, der Speicher hat halt die IP-Adresse von evcc als Partner
  [....snap....restliche Yaml]

Mit dieser Konfig hatte ich aber immer noch die lästige Konkurrenzsituation (und ein Fragezeichen im Kopp).

Dafür kam dann von meinem „Starthelfer“ die (für Linuxianer und andere IT-berufenen eingängige) Idee, daß evcc den Proxy auch selbst nutzen könnte, also was anderes für den PV-WR konfigurieren wie in den Beispiel-Konfigs dargestelt.

HEUREKA
Lösung ist, beim Solaredge-PV nicht den Solaredge direkt zu fragen , sondern die Kartoffel frägt sich selbst (ok, kein Lachsalve bitte, mein Kleincomputer heißt Kartoffel, „le potato“ als Raspi4-Alternative):

hier das Yaml, mit dem beide Front-Ends (evcc und Varta-Speicher-App) erfolgreich vollständig werden:

[..snip..]
[...meters]

• name: solaredge_pv #fast so wie in den Vorlagen zu Solaredge
  type: template
  template: solaredge-inverter
  usage: pv
  modbus: tcpip
  id: 1
  host: kartoffel.fritz.box # evcc frägt sich selbst, daher leicht schizophren <<<=====
  port: 1502 # modell SE5K

Modbusproxy:

• port: 1502
  uri: SolarEdge.fritz.box:1502 # Umleitung für den Speicher über evcc, der Speicher und nun auch evcc selbst hat halt die IP-Adresse von evcc als Partner
  [....snap....restliche Yaml]

Soweit mal eine Problemlösung der Klasse „Anfänger-kniff“. Kundingen Proxy-Nutzern aus anderem Umfeld mag das einleuchten, einem Menschen, der brav die Vorlagen zusammenkopiert und eher durchstolpert, wird das "nur im Nachgang" verständlich
Karsten ist daher mein „Kartoffelheld“ 8-)

Lessons learned: wenn Proxy, dann für alle Kanäle ggü dem "Slave" nutzen, ein direkter Zugriff parallel zu fahren ist ungünstig, auch wenn es in den Vorlagen drin steht

Sonnige Grüße
Ralf

[andig]

Mit dieser Konfig hatte ich aber immer noch die lästige Konkurrenzsituation (und ein Fragezeichen im Kopp).

Ich denke die Erklärung ist ganze einfach. Du hast

host: Solaredge.fritz.box # evcc frägt den PV-WR direkt an <<<=====

und

uri: SolarEdge.fritz.box:1502 # Umleitung für den Speicher über evcc, der Speicher hat halt die IP-Adresse von evcc als Partner

Die Hostnames sind NICHT identisch- deshalb wird auch die Verbindung in evcc nicht re-used. Anwenderfehler ;)

host: kartoffel.fritz.box # evcc frägt sich selbst, daher leicht schizophren <<<=====

Das braucht es nicht weil evcc bei identischen Namen die Verbindung erneut nutzt. Du musst es nur lassen...