Ich lese unseren SOLVIS Ben Heiz- und WW-Kessel per MODBUS-TCP aus.
Allerdings funktioniert das nur, wenn der Kessel (die Solvis-Steuerung = SC3 äquivalent) NACH HA gestartet wird. Im Fall eines Stromausfalls mit nachfolgender Netzwiederkehr (oder manuellem Abschalten des HA-Rechners) ist die Heizung vermutlich schneller am Start als HA, die Abfrage funktioniert dann nicht, z.B. die Heizungspuffertemperatur wird dann mit “nicht verfügbar” in HA angezeigt. Ein Powercycle der Heizung bei laufendem HA bringt die Funktion zurück. Woran kann das liegen bzw. wichtiger, wie kann ich dieses Verhalten abstellen? Ein (verzögerter) Neustart der MODBUS Komponente in HA hilft leider nicht. Ein Shelly für den automatisierten Powercycle wäre overkill.
Habe das gleiche Problem, inzwischen eine Lösung gefunden?
Jeein 
Aktuell scheint es nicht aufzutreten, es könnte aber auch ein Eigentor gewesen sein:
Ich betreibe HA als VM unter ProxMox, da kann man so schöne Kopien der VM erstellen…
Die hatte ich dann zwar “HA_Backup” benannt, aber ansonsten ist das eben eine 1:1 Kopie, die, wenn sie nicht explizit am Starten gehindert wird, eben parallel startet.
Wenn nun die Haupt VM updates etc. bekommt, wird der Modbus kurzzeitig frei und die Kopie schnappt sich die Kommunikation, Wenn ist den Benhart resette, bekam (meistens)
die Haupt-VM den Zugriff, seit dem ich die Kopie deaktiviert habe, ist das Problem nicht meg´hjr aufgetreten, kann aber auch Zufall sein. Bin mir nicht sicher, ob Modbus-TCP Multi-Master fähig ist?
Es war kein Eigentor, nach dem jüngsten Powercycle im Haus wg. Verdrahtungsarbeiten war die Backup-VM (1:1 Kopie der Home Assistant Instanz) doch wieder aktiv, aber das Modbus-Problem trat dennoch nicht auf. Ich vermute, da wurde etwas am Modbus-Code optimiert?
Nutze zur Zeit Core 2023.9.3 und der Ben kann auch auch ohne Neustart nach HA-Start ausgelesen werden.
Bei mir klappt es auch wieder, nutze einen Raspberry Pi 3 und als ich den damals einmal komplett neustarten musste, kam HA nicht mehr an die Daten via ModBus. Nach ca 3 Tagen dann aber doch wieder, dazwischen erfolgten nur ein ein paar Core Updates im HA.
Bei meinen ersten Versuchen mit der Anbindung des Solvis Max bin ich auch darauf reingefallen. Habe das aber nicht näker untersucht. Letztlich hat das komplette Aus und Ein der Anlage (sicherlich keine gute Lösung) geholfen.
Aber ich habe eine eine andere Frage. Könnt Ihr die Parameter Wochenplan xxx 34048 ff deuten sowie auch HKR1 Fix Temperatur Tag 2820, der liefert mir bei einer FBH 50°
Ich habe auch den Solvis Max.
Frage zum Auslesen der Daten: Braucht man dazu unbedingt die Solvis Remote? Oder was genau ist dazu notwendig?
In meinem 2021er Solvis Ben ist die Solvis-Remote Funktionalität bereits in die Steuerung integriert (SC3, wenn ich mich richtig erinnere).
Ich musste nur den Zugriff auf den Modbus freischalten (lassen).
Hatte einen Stromausfall im Ort, danach waren zunächst die Zigbee Entitäten nicht mehr ansprechbar. Ein Versuch, das über ein angebotenes HA OS update wieder in Gang zu bringen, hat mich letztlich die Verbindung zum Solvis Ben gekostet. Keine Verbindung mehr per ModbusTCP möglich, “unknown error”. Aller meine eigenen Tipps zu diesem Thema wirken leider nicht. Wenigstens habe ich Zigbee wieder zum Laufen bekommen, bin ein wenig frustriert und ratlos.
Versuche mit QModMaster als Modbus Tool ergaben zunächst auch nur Fehlermeldungen. Nachdem ich allerdings dort mit Function Code “Read Holding Register 0x03” erfolgreich ein Holdingregsiter im Solvis Ben lesen konnte und dann das Modbustool sauber beendet hatte, funktioniert es nun auch wieder per Homeassistant. Warum das so ist weiß ich immer noch nicht, aber die Entitäten sind wieder vorhanden. Es scheint, dass eine “unvollständige” Modbus-Kommunikation den Modbus “lahmlegt” ?
Im Symcon Forum wird eine mögliche Erklärung für das Verhalten beschrieben:
“Man darf halt auf keinen Fall den Modbus-Client „hart“ rebooten, ohne die Verbindung zu beenden, weil die betüddelte Modbus-Implementierung der Solvis nur eine Verbindung kann und keinen Timeout oder TCP-Keepalive verwendet.” Quelle: [Solvis SC-3 Modbus Ben steuern - #19 von taipan - Haustechnik - IP-Symcon Community]
Das deckt sich mit meiner oben geschilderten Erfahrung und leider gibt es dann wohl auch keine sichere Methode. Vor einem Neustart der Modbus-Kommunikation mit den Solvis Geräten müsste eine laufende Verbindung erst sicher beendet werden und auch keine weitere Anfrage an die Solvis-Steuerung abgesetzt werden. Keine Ahnung, ob sich solch ein Verhalten in der Modbus-Implementation von HA einstellen lässt. Ein Shelly in der Zuleitung zur Heizung scheint da die sichere Lösung zu sein.
Die im oben genannten Forum genannte generelle Kritik an Solvis kann ich leider auch bestätigen: Trotz mehrmaliger Nachfrage per E-Mail und zweier Telefonate bezüglich eines sehr merkwürdigen Verhaltens der externen PV2Heat-Variante (aka SolvisTom), erhielt ich nur abwiegelnde Antworten im Sinne von “Das ist schon korrekt so”. Nach einem dauerhaften Fehler dieser Anlage habe ich mir dann die Zeit genommen, das Installationshandbuch intensiv zu lesen. Danach konnte ich den aktuellen Fehler resetten und hatte nebenbei auch die Lösung für das merkwürdige Verhalten gefunden. Der Solvis-Installateur hatte einen wichtigen Parameter auf Werkseinstellung belassen. Nachdem ich das “Problem” verstanden und den Parameter korrekt gesetzt hatte funktioniert das Teil ~ 2,5 Jahre nach Installation nun endlich wie es soll. Eine (rudimentäre) Anbindung in eine Haussteuerung ist aber leider ebenfalls nur per Shelly (EIN/AUS) machbar, da das ein völlig autarkes System ist. Vor Kauf der Anlage waren als Kommunikationsmöglichkeiten noch einige Bussysteme im Datenblatt aufgeführt (u.a. Modbus), aber das wurde scheinbar nie umgesetzt.
Ich finde es traurig, wenn sich deutsche “Premium-Hersteller” derart selbst ins Knie schießen.