Besonderheiten - GollmerSt/SolvisSmartHomeServer Wiki

Original URL: https://github.com/GollmerSt/SolvisSmartHomeServer/wiki/Besonderheiten

Das Admin-Feature

Der Server ist so konzipiert, dass er auch auf die Menüs des Installateur-Bereiches zugreifen kann und dort Werte ausgelesen/verändert werden können. Dies sollte aber nur erfolgen, wenn man weiß, was man tut. Aktuell gibt es folgende Werte, welche aus diesem Bereich vom Server ausgelesen/verändert werden können:

Kanalname Zugriffsart Beschreibung
C35.Min_Vorlauf_Temp_HK1 read/write Minimale Vorlauftemperatur Heizkreis 1
C40.Min_Vorlauf_Temp_HK2 read/write Minimale Vorlauftemperatur Heizkreis 2
C45.Min_Vorlauf_Temp_HK3 read/write Minimale Vorlauftemperatur Heizkreis 3
C47.Puffer_dT_Start read only Maximale Differenztemperatur zwischen oberer Heizungspuffer-Temperatur und dem WW-Sollwert, bei dem das Nachheizen für das WW startet

Werden noch weitere Werte gewünscht, meldet Euch.

Diese Werte des Installateur-Bereichs werden nur dann behandelt, wenn das Admin-Feature in der base.xml-Datei auf dem Wert true steht. Ist es in der base.xml nicht definiert oder steht es auf dem Wert false, so wird verhindert, dass der Server den Installateur-Bereich ansteuert.

Nachheizen

Der SmartHomeServer erlaubt ab Version 1.4 auch das Nutzen des Nachheizens für Warmwasser. Das Nachheizen kann durch den Kanal C46.WarmwasserNachheizen angestoßen werden. Der Name bezieht sich auf die Server-Client-Schnittstelle. Bei Verwendung der MQTT-Schnittstelle ist im Topic der Name C46:WarmwasserNachheizen zu verwenden.

Der Server greift dabei auf folgenden Screen der SolvisControl zu:

Wasser

Er überprüft auch, ob nach dem Touch auf den Nachheizen-Button entweder das Aktiv-Symbol ausgefüllt wird oder folgender Screen erscheint:

Nachheizen nicht erforderlich!

Um das Nachheizen vom Smarthome-System anzustoßen, ist der Kanal C46.WarmwasserNachheizen auf den Wert heating zu setzen, andere Werte sind nicht möglich. Als Rückmeldung erhält das Smarthome-System einer der folgenden drei Werte.

Wert Bedeutung
heating Das Nachheizen läuft.
not_required Das Nachheizen ist nicht erforderlich. Nach ca. 30s wechselt der Kanal dann wieder in den off- Zustand.
off Das Nachheizen ist beendet.

Ein vorzeitiges Beenden ist von der Solvis-Anlage nicht vorgesehen und wird daher nicht unterstützt. Prinzipiell kann man den Nachheizmodus verlassen, indem man die WW-Solltemperatur (C05.WassertemperaturSoll) erst auf einen niedrigen Wert setzt und nach Beenden des Nachheizens (C46.WarmwasserNachheizen -> off) wieder auf den ursprünglichen Wert zurück setzt. Diese Möglichkeit wird vom Server jedoch nicht angeboten, da man sie - bei Bedarf - im Smarthome-System realisieren kann.

Die Solvis-Anlage führt dieses Nachheizen nur aus, wenn die Differenz zwischen obere Puffertemperatur (S04.Heizungspuffertemperatur_oben) und der eingestellten WW-Sollwerttemperatur (C05.WassertemperaturSoll) kleiner ist als der Wert Puffer dT-Start (C47.Puffer_dT_Start). Der Wert Puffer dT-Start ist nur in den Installateur-Menüs zu finden und ist dort einstellbar. Standardmäßig ist er 12K, ist aber laut Solvis-Beschreibung installionsabhängig.

Um ein unnötiges Ansteuern der SolvisControl 2 zu vermeiden, untersucht der Server diese obige Bedingung, wenn ihm Puffer dT-Start bekannt ist. Das kann auf unterschiedliche Arten erfolgen:

  1. Ist in der base.xml das Admin-Feature auf true gesetzt, liest der Solvis-Server diesen Wert selbstständig aus dem Installateur-Bereich.
  2. Der Anwender ermittelt diesen Wert selber aus dem Installateur-Bereich und trägt es in den FixChannelValues-Bereich der base.xml-datei ein.
  3. Der Anwender verzichtet darauf. Dann erfolgt doch ein Zugriff auf den Warmwasser-Screen und der Button Nachheizen wird gedrückt. Anschließend untersucht der Server, ob der Kreis des Aktiv-Symbol ausgefüllt wird oder der Screen Nachheizen nicht erforderlich erscheint. Entsprechend werden die obigen Werte an das SmartHome-System zurück gemeldet.

Nachdem das Nachheizen angestoßen wurde, fragt der Server solange wiederholt den obigen Screen ab, bis das Aktiv-Symbol wieder einen nicht ausgefüllten Kreis darstellt, also das Nachheizen beendet ist. Das wird durch den Wert off an das Smarthome-System gemeldet.

Prinzipiell funktioniert das Monitoring des Nachheizens auch dann, wenn es direkt über die SolvisControl 2 oder über das Solvis-WebInterface angestoßen wurde. Da nach einem manuellen Eingriff der Server erst mal 5 Minuten (in base.xml definiert, Attribut: releaseBlockingAfterUserAccess_ms ) wartet, kann es sein, dass der Server von einem manuellen über die SolvisControl angestoßenen Nachheizen nichts mitbekommt. Wer das vernünftig Monitoren will, sollte daher das Nachheizen immer vom Smarthome-System anstoßen. Eine andere Möglichkeit wäre das Reduzieren der Zeit releaseBlockingAfterUserAccess_ms in der base.xml. Aber auch das ist nicht ideal, da der Server erst mal sämtliche beschreibbaren Werte holt, die der Anwender verändert haben könnte (siehe auch hier). Und das dauert eine Weile.

Aktualisierung der über das Gui der SolvisControl gelesenen Kanäle

Die Kanäle, welche nur über die SolvisControl mittels OCR gelesen werden können, werden in diesem Kapitel Gui-Kanäle genannt

Da der Aufwand der Aktualisierung dieser Kanäle recht hoch ist (es muss durch verschiedene Menüs der SolvisControl gegangen werden), erfolgen Aktualisierungen nur in folgenden Fällen:

Bei einem Schreiben eines Gui-Kanals

Wird über das Smarthome-System ein Gui-Kanal modifiziert, werden automatisch auch die Gui-Kanäle aktualisiert, welche im Bildschirm des zu schreibenden Kanals sich mit befinden. Dies erfolgt im Anschluss an den Schreibvorgang. Hat also der Schreibvorgang Einfluss auf einen nur zu lesenden Gui-Kanals (z.B. Raumeinfluss/Sollwert Vorlauftemperatur), so erkennt man gleich dessen Einfluss im aktualisierten Kanal.

Bei besonderen Kanälen erfolgt selbst bei einen Schreiben kein Zugriff zum Gui, und zwar man das Ergebnis des Schreibens schon aus den Anlagenparametern voraussehen kann und es nicht erforderlich ist, dass die Solvis-Anlage auf dieses Ergebnis reagiert. Aktuelle betrifft das nur einen einzigen Kanal und zwar C46.WarmwasserNachheizen. Hier kann man aus den vorhandenen ständig durch den XML-String gemonitorten Anlagenparametern das Ergebnis vorausberechnen, wenn ein Nachheizen gar nicht notwendig ist. Erst wenn es wirklich notwendig ist, erfolgt der Zugriff auf das Gui und stößt das Nachheizen an.

Nach einem Anwenderzugriff auf die SolvisControl

Der Server bzw. das Smarthome-System muss mitbekommen, wenn der Anwender einen Wert direkt über die SolvisControl (oder per SolvisRemote per Browser) modifiziert. Dazu wird ständig der Bildschirm der SolvisControl überwacht, erfolgt dabei einen Änderung, welche nicht vom Server veranlasst wurde, liegt ein Anwender-Zugriff vor.

Erfolgt keine Änderung des Bildschirms mehr, wird davon ausgegangen, dass der Anwender seinen Zugriff beendet hat. Der Server liest dann die Kanäle aus, welche der Anwender verändert haben könnte. Es werden dabei nur ein Teil der Bildschirme angefahren, Bildschirme, welche nur lesbare Kanäle enthalten, werden nicht angefahren und die Daten dieser Kanäle werden nicht aktualisiert.

Update bestimmter Kanäle bei dem Feature EquipmentTimeSynchronisation

Ist das Feature EquipmentTimeSynchronisation in der base.xml aktiviert, so werden die Gui-Kanäle mit den Laufzeiten der Zeitfunktion immer aktuell gehalten. Das sind die Kanäle C02.LaufzeitBrenner, C03.LaufzeitAnforderung2, C24.LaufzeitSolarpumpe und C25.LaufzeitSolarpumpe2.

Gezielter Update aller nur lesbaren Gui-Kanäle

Neben den obigen Automatismen kann der Anwender vom Smarthome-System auch gezielt alle nur lesbaren Kanäle aktualisieren lassen.

Dies erfolgt über die Server-Client-Schnittstelle mittels des Server-Commands UPDATE_CHANNELS, wie hier beschrieben.

Unter FHEM verwendet man dazu den Befehl SET deviceName ServerCommand UPDATE_CHANNELS

Das gleiche erreicht man über die MQTT-Schnittstelle, indem man den Wert "UPDATE_CHANNELS" an das Topic "prefix/client/unit/server/cmnd" sendet (publish). Das wird bei der Beschreibung der MQTT-Schnittstelle genauer beschrieben. Sie ist hier zu finden.

Gezielter Update einzelner Gui-Kanäle

Sind nur wenige Gui-Kanäle von Interesse, können einzelne Kanäle gezielt ausgelesen werden. Dabei werden auch die Kanäle aktualisiert, die sich auf der anzufahrenden Seite befinden.

Dies erfolgt über die Server-Client-Schnittstelle mittels des GET-Commands, wie hier beschrieben.

Unter FHEM verwendet man dazu den Befehl GET deviceName Kanalname

Das gleiche erreicht man über die MQTT-Schnittstelle, indem man einen beliebigen Wert (auch null) an den Topic "prefix/client/unit/channel/update" sendet (publish). Das wird bei der Beschreibung der MQTT-Schnittstelle etwas genauer beschrieben. Sie ist hier zu finden.

Erkennung des Abschlusses des Auslesens/Beschreibens der Gui-Kanale (ab Version 1.4.0)

Das Auslesen/Beschreiben erfolgt intern über einen Command-Queue. Man kann daher schon andere Kanalwerte auslesen/verändern, ehe ein solcher Befehl abgeschlossen ist. In manchen Fällen ist es erforderlich, dass auf der SmartHome-Seite etwas Weiteres angestoßen werden muss, wenn das Auslesen/Beschreiben eines bestimmten Werts abgeschlossen ist oder wenn alle in der Queue befindlichen Commands abgearbeitet sind.

Es wird daher - im Gegensatz zu den anderen Kanälen - immer der geschrieben/gelesene Wert zurückgegeben, auch dann wenn sich der Wert gar nicht verändert hat. Auf diese Weise kann das Smarthome-System erkennen, dass die Gui-Bearbeitung abgeschlossen ist.

Zusätzlich wird das Ende der Abarbeitung der gesamten Queue in dem SolvisStatus zurückgemeldet. Dazu gibt es folgende SolvisStatus:

SolvisStatus Bedeutung
CONTROL_FINISHED Die Queue ist abgearbeitet.
CONTROL_MONITORING Der Server beobachtet aktuell einen oder mehrere Screens der SolvisControl (Beispiel: Nachheizen). Es können andere Gui-Befehle ausgeführt werden, diese haben höhere Prio.
CONTROL_READ_ONGOING Es befindet sich noch mindestens ein lesender Zugriff in der Queue.
CONTROL_WRITE_ONGOING Es befindet sich noch mindestens ein schreibender Zugriff in der Queue.

Anmerkung:

Es gibt keinen Status, der Anzeigt, dass es sowohl lesende als auch schreibende Zugriffe in der Queue gibt. Aus meiner Sicht ist das unnötig, da ein Schreibender Zugriff immer vorrangig ist. Ob sich noch lesende Befehle in der Queue befinden, ist aus meiner Sicht in diesem Fall belanglos. Wenn sämtliche schreibenden Befehle ausgeführt wurde und es befinden sich noch lesende in der Queue, wird der Status CONTROL_READ_ONGOING an das Smarthome-System gesendet. Gibt es trifftige Gründe, diese Behandlung doch zu ändern, meldet Euch!