Besonderheiten
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.
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:
Er überprüft auch, ob nach dem Touch auf den Nachheizen-Button entweder das Aktiv-Symbol ausgefüllt wird oder folgender Screen erscheint:
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 gesetzt. 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 installationsabhä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:
- Ist in der base.xml das Admin-Feature auf true gesetzt, liest der Solvis-Server diesen Wert selbstständig aus dem Installateur-Bereich.
- Der Anwender ermittelt diesen Wert selber aus dem Installateur-Bereich und trägt es in den FixChannelValues-Bereich der base.xml-datei ein.
- 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ünftige 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.
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:
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.
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.
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.
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.
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.
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 triftige Gründe, diese Behandlung doch zu ändern, meldet Euch!
Der Server beobachtet regelmäßig das Display der SolvisControl 2. Taucht darauf eine Fehlermeldung auf, dann wird diese vom Server erkannt und der Status wechselt in den Zustand ERROR.
Dabei gibt es folgende Zustandsmöglichkeiten der Anlage:
Solange die Fehlermeldung auf dem Display sichtbar ist, ist die grafische Steuerung durch den Server über die SolvisControl 2 deaktiviert. Die Fehlermeldung bleibt weiterhin sichtbar. Erst wenn der Back-Button betätigt wird, kann die Anlage wieder über den Server gesteuert werden.
Die Back-Button-Betätigung kann über 2 Methoden bewirkt werden:
- Durch manuelles Drücken des Back-Buttons entweder über das WebInterfase der SolvisRemote oder an der SolvisControl 2 selber.
- Ist das Feature
ClearErrorMessageAfterMailin der base.xml aktiviert (true), dann wird im Fehlerfall versucht eine Mail mit der Hardcopy zu versenden. Ist der Versand erfolgreich, so erfolgt der Druck auf den Back-Button automatisiert. Nach dem Versand ist ein Steuern der Anlage durch den Server wieder möglich.
Wurde die Fehlermeldung wie oben beschrieben gelöscht, dann ist die Anlage noch weiter im Fehlermodus, dies wird nur im Home-Screen sichtbar:
Dort, wo normalerweise die Uhrzeit und das Datum eingeblendet sind, erscheint ein blinkender Button mit einem Warn-Schild. Solange der Fehler vorliegt, ist auch dieser Error-Button im Home-Screen eingeblendet.
Im Fehlerfall beobachtet der Server daher immer den HomeScreen, der Bildschirmschoner wird verhindert. Natürlich können weiterhin GUI-Befehle ausgeführt werden. Wenn diese ausgeführt sind, erfolgt die Beobachtung des Home-Screens weiter. Erst wenn Fehler nicht mehr vorhanden sind, wird der Bildschirmschoner nicht mehr unterdrückt und ein vorher manuell selektierter oder durch den Server-Befehl "SelectScreen" ausgewähler Screen wird wieder angefahren.
Zu beachten:
Ein Fehler wird verzögert gelöscht, d.h. nachdem im HomeScreen die Zeit eingeblendet ist, vergeht noch einen gewisse Zeit, bis der ERROR-Status wieder gelöscht ist. Dies wurde erforderlich, da die Solvis-Anlage manchmal den vorhandenen Fehler löscht um in dann einige Minuten später wieder zu Melden. Dies Zeit ist in der base.xml unter resetErrorDelayTime_ms einstellbar und sollte 300000 ms betragen.
Der Server hat in der base.xml mehrere Features und Werte, mit dem man das Verhalten des Server im Anlagen-Fehlerfall beeinflussen kann:
| XML-Pfad (XPath) | Bedeutung |
|---|---|
| /BaseData/Units/Unit@resetErrorDelayTime_ms | Zeit vom Verschinden des Anlagenfehlers bis der Status ERROR gelöscht wird |
| /BaseData/Units/Unit/Features/Feature[@id="ClearErrorMessageAfterMail"]@value | "true": Fehler-Box wird nach Versenden der Mail gelöscht, der Server kann weiter die Anlage steuern. "false: Nach einem Anlagenfehler wird solange die Bedienung über den Server blockiert, bis von Hand der Zurück-Button gedrückt wurde. |
| /BaseData/Units/Unit/Features/Feature[@id="SendMailOnError"]@value | Im Fehlerfall wird eine Mail mit einer Hardcopy des Screens versendet. |
| /BaseData/Units/Unit/Features/Feature[@id="SendMailOnErrorsCleared"]@value | Ist der Anlagenfehler gelöscht, wird einen Mail verschickt. |