Neu: Samson Trovis Integration (auch für OEM von Sauter, Pewo, Yados)

[Tom Bombadil]

Was lange währt, wird endlich gut: Nachdem ich den Jungs von HA lange die Ohren über die andauernden Änderungen in pymodbus vollgeheult habe (und wie doof es ist, alles ständig wieder anpassen zu müssen), hat sich balloob (Paulus Schoutsen, "Mr. Home Assistant" höchstpersönlich) im Juni meiner erbarmt. In gemeinsamer Arbeit ist daraus die neue HA modbus-connection Library entstanden, die mit HA Core 2026.9 im Rahmen der kompletten 'Modbus-Überholung' von HA nun offziell ausgeliefert wurde.

Als erstes Test-/Referenzobjekt wurde die YAML-Version meiner Samson Trovis Anbindung in eine "echte" Integration überführt; seit August läuft diese hier stabil und sauber. Listing als Core Integration hab ich aus verschiedenen Gründen abgelehnt, obwohl ich mehrfach dazu gefragt wurde (ist mir einfach zu umständlich und zu formal vom handling her) - aber die Aufnahme als HACS Default Integration habe ich gestern beantragt.

Alles getestet auf 3 Modellen: 5578+5579 (Test-/Dev-VM) sowie 5576 (Produktiv-VM). Mehrere Betatester haben u.a. auch 5573 sowie 5573-1 angebunden.

Lange Rede, kurzer Sinn; wer sie brauchen kann - hier ist sie: https://github.com/Tom-Bom-badil/samson_trovis_557x

Ebenfalls dort zu finden sind ein ausführliches Wiki, das die letzten 10 Jahre Trovis-Bastelei zusammenenfasst, sowie die Discussions aus dieser Zeit. Diese sollen beim Einstieg helfen. Installationsanleitung ist natürlich auch dabei.

Viel Spass und Erfolg damit!

/tom

p.s. Die Integration kann übrigens beliebig viele Regler gleichzeitig verwalten (zwinker zwinker oefchen).

[henfri]

Hallo Tom,

pymodbus ist eine Katastrophe und die Maintainer beratungsresistent.
Das hat der Autor der Huawei-Solar Integration allerdings auch schon erkannt und tmodbus entwickelt
https://github.com/wlcrs/tmodbus

Wenn ich es richtig sehe, ist modbus_connection ein wrapper um die Beiden herum so dass nur noch an einer Stelle auf Inkompatible Änderungen reagiert werden muss?

Gruß,
Hendrik

[Tom Bombadil]

Genau das war der Punkt, mit dem wir bei modbus-connection an den Start gegangen sind. Es stimmt, dass Galen Collins und insbesondere auch Jan Iversen auf der einen Seite eine super Arbeit mit pymodbus leisten; gleichzeitig nehmen sie aber nie Rücksicht auf Abwärtskompatibilität und ändern dieselben Funktionen und deren Parameter gern gleich dreimal hintereinander. Das ist ein Hase-Igel-Spiel, das man als Nutzer von pymodbus oder auch als Maintainer von größeren Systemen wie SmartHomeNG oder HA nicht gewinnen kann. Versionschaos ist vorprogrammiert; inkompatible Versionsstände im gleichen System auch; Dominoeffekt bei neuen Versionen ebenfalls.

Hinzu kommt, dass Jan Iversen vor einiger Zeit sehr deutlich gemacht hat, "keinen Bock" mehr auf die HA Modbus Integration zu haben, geschweige denn diese weiter maintainen zu wollen. Da bestand also Handlungsbedarf.

Ursprünglich hatte ich im Mai begonnen, einen eigenen Wrapper als 'neutrale Schicht' für pymodbus zu schreiben, um nicht bei jeder neuen pymodbus Version an der eigentlichen Integration herumschrauben zu müssen. Den Gedanken (und einige weitere, wie das Teilen derselben Verbindung für mehrere Integrationen, oder die einmalige Definition von sich wiederholenden Registerblöcken) hat Paulus dann aufgegriffen und daraus modbus-connection gebaut. Etwa zur gleichen Zeit ist Thijs (wlcrs; der von Dir genannte Maintainer der Huawei-Solar Integration) mit seiner neuen, eigenen Modbus-Bibliothek 'tmodbus' dazugestossen. Wobei modbus-connection von Anfang an sowohl mit pymodbus als auch tmodbus arbeiten konnte (default ist aber tmodbus).

Mittlerweile gibt es außer Trovis noch reichlich andere Referenzprojekte (Stiebel, Huawei usw usw). modbus-connection soll dabei die ebenfalls verbreiteten alten YAML-Konfigurationen nicht ablösen; diese wird es weiterhin geben. Aber die Hürden für den Umstieg von YAML auf 'echte Integration', insbesondere mit all den kürzlich erstellten Referenzprojekten und im Zeitalter von KI, sind extrem gesunken.

Es gibt mittlerweile einige Integrationen, die fast 'one shot' Umstellungen von YAML sind; entsprechende Referenz-Prompts stehen zur Verfügung. Paulus' Ziel ist es, möglichst viele Umstellungen von YAML auf Integration zu erhalten; und gleichzeitig die Anzahl der Direktimports von pymodbus durch Integrationen massiv zu verringern.

Die modbus-connection Lib selbst ist Backend-/HA-unabhängig (oder sollte es zumindest per Definition sein) - kann also auch von anderen Systemen verwendet werden: https://home-assistant-libs.github.i...us-connection/

/tom

[starwarsfan]

Hi

Umstieg von YAML auf 'echte Integration'

Das verstehe ich gerade nicht. Was ist denn eine 'echte Integration'? Und was hat das mit yaml zu tun?

[r4id]

Das verstehe ich gerade nicht.

Dito

[uncelsam]

Meine Vermutung:

Bei Modbus musste ja bis jetzt des Register einzelnen in der YAML konfiguriert werden, was bei Geräten mit sehr vielen Registern recht aufwendig war, bei der Integration ist das halt alles "unsichtbar" im Hintergrund.

[Tom Bombadil]

Bei Modbus musste ja bis jetzt des Register einzelnen in der YAML konfiguriert werden, was bei Geräten mit sehr vielen Registern recht aufwendig war, bei der Integration ist das halt alles "unsichtbar" im Hintergrund.

Genau. In HA gibt es 2 Möglichkeiten, ein Modbus-Gerät einzubinden:

• 'Klassisch' per pymodbus-Integration mit aufgeproftem YAML-Interpreter: Du editierst Deine configuration.yaml, bindest von Hand eine 'modbus:' Seketion ein und passt dort manuell die Parameter jedes einzelnen Gerätes an.
  
  Anschließend kannst Du Dir eine oder mehre YAML-Dateien für jedes Gerät anlegen, in der Du die einzelnen Register, Coils usw aufführst und sie als sensor:, binary_sensor:, number:, switch: usw definierst (bei KNX läuft es ja ähnlich, per include der YAML Dateien). Beispiel hier.
  
  Das geht für einfache Geräte mit ein paar wenigen Registern und Coils recht fix. Kompliziert wird es, wenn das Gerät wie bei Trovis hunderte verschiedene Konfigurationen haben kann (7 verschiedene Modelle mit unterschiedlichen Möglichkeiten; jedes mit bis zu 96 verschiedenen Hydrauliken mit 1..3 Heizkreisen, Warmwasser ja/nein, Solar ja/nein, Pufferkreis ja/nein, bis zu 17 verschiedene Sensoren, mehrere analog Aus-/Eingänge ja/nein, verschiedene Pumpen / Ventile, unterschiedliche Zeitprogramme usw usw).
  
  Dann fängt der Anwender an, sich sein Gerät 'zusammenzufrickeln' (trotz YAML-Vorlage); und muss dabei oft auch selbst entscheiden, was jetzt sensor:, binary_sensor, switch usw ist - entsprechend der konkreten lokalen Installation und Konfiguration der gesamten Heizungsanlage. Zusätzlich gehen Ableitungen, Berechnungen und Auswertungen nur als komplexe YAML/Jinja Templates, die ggf ebenfalls von Hand angepasst oder erweitert werden müssen. Und genau dies überfordert viele Endanwender und ist für den Ersteller der YAML-Vorlagen extrem Supportaufwendig (Erfahrung aus meinen anderen Integrationen wie UGreen oder Helios/Vallox).
  .
• Per Integration für das konkrete Gerät: (Setzt natürlich jemanden voraus, der vorher die Integration/Anbindung in Python programmiert hat und das spezifische Gerät recht genau kennt.) Gehe zu 'Geräte und Dienste', wähle 'Integration hinzufügen', wähle 'Samson Trovis' aus, gib IP/Port, serielle Schnittstelle oder den angeschlossenen ESP an (letztere beiden werden Dir schon automatisch von HA angeboten).
  
  Danach beginnt die Integration, das Gerät automatisch zu proben, und nach ca. 1 Minute hast Du mehrere hundert Entitäten in Deiner spezifischen Reglerkonfiguration fix und fertig verfügbar, samt Berechnungen wie Heizkurven für jeden Heizkreis, WW-Einstellungen, installierte Heizkreise und deren Funktion und Parameter, Sensor-Messwerte usw usw. Keine tiefergehenden Kenntnisse über sensor:, number:, Jinja-Templates und die Dateistruktur von HA notwendig; kein YAML editing; Du kannst sofort beginnen, den Regler auf dem Dashboard anzuzeigen oder zu konfigurieren / optimieren.

Fazit: YAML ist eher für den versierten HA-Anwender, von denen wir hier ja etliche haben. Integration ist eher für die breite Masse der Endanwender ohne tiefgehende Kenntnisse, wie HA funktioniert, und im Fall Trovis auch ohne eigenen Abschluss als Heizungsbauer. Beide führen zum Ergebnis; mit einem riesigen Unterschied im Zeitaufwand, um das konkrete Gerät einzubinden (oft wochenlanges Gefrickel mit vielen Rückfragen bei YAML).

Hoffe, das hilft für das Verständnis - falls nicht, nochmal fragen.

/tom

[r4id]

Kompliziert wird es, wenn das Gerät wie bei Trovis hunderte verschiedene Konfigurationen haben kann

Wo wird den sowas eingesetzt? Industrie? Große Wohnkomplexe? Nutzt man dann wirklich HASS?