Kanalunabhängige Befehle und Status - GollmerSt/SolvisSmartHomeServer GitHub Wiki
Neben der Kanäle, welche die Anlageparameter und Aktor- /Sensor-Werte wiederspiegeln, gibt es noch einen Reihe weiterer Status/Commands.
Anlagenunabhängige Status
Server-Online-Status (nur MQTT)
Das Topic
topicPrefix/server/online
liefert den Online-Zustand des Servers. Ist er true, ist der Server online.
Smarthome-System-Online-Status (nur MQTT)
Über das Topic
topicPrefix/smartHomeId/online
muss das Smarthome-System dem Server mitteilen, dass es Online (true) ist.
Server-Error (nur MQTT)
Über das Topic
topicPrefix/smartHomeId/error
liefert der Server an das SmartHomeSystem eine Fehlermeldung, wenn ein vom Smarthome-System angestoßener Befehl vom Server nicht ausgeführt werden konnte. Das Topic liefert in diesem Fall eine Fehlerbeschreibung.
Anlagenunabhängige Befehle
Über das Topic
topicPrefix/smartHomeId/server/cmnd
kann ein Server-Befehl angestoßen werden. Das Server-Client-Interface stellt diese Funktionalität über den SET/ServerCommand zur Verfügung. Folgende Befehle sind aktuell möglich (Stand 15.06.2021):
Befehl | Beschreibung |
---|---|
BACKUP | Die berechneten Werte und die Gui-Werte werden gesichert. |
RESTART | Der SolvisSmartHomeServer wird neu gestartet. |
TERMINATE | Der SolvisSmartHomeServer wird beendet (kein Restart!). |
LOG_STANDARD | Der Log des Servers erfolgt ungepuffert in eine Datei. |
LOG_BUFFERED | Der Log des Servers wird ins RAM geschrieben. Erst nach dem Befehl LOG_STANDARD werden die gepufferten Log-Daten in die Log-Datei geschrieben. |
Anlagenabhängige Status
Auf der Server-Client-Schnittstelle sind die anlagenabhängigen Status als Events realisiert. Eine Beschreibung findet man hier und hier. Sowohl auf der MQTT-Schnittstelle als auch im FHEM-Modul sind sie etwas differenzierter zusammengefasst:
Solvis-Status
Hier wird der Zustand der Verbindung zur Solvis-Anlage übermittelt. Den Zustand sendet der Server unter dem Topic
topicPrefix/unitId/status.
Das FHEM-Modul nutzt dazu das Reading state. Der Status kann die folgenden Werte annehmen:
Status | Bedeutung |
---|---|
POWER_OFF | Fehlt die Verbindung zur Solvis-Anlage länger als 3 Minuten, geht der Server von einer abgeschalteten Anlage aus. Der Status wechselt dann zu POWER_OFF |
REMOTE_CONNECTED | Es existiert nur eine Verbindung zur SolvisRemote. Auch hier nimmt der Server an, dass die Anlage selber ausgeschaltet ist. |
SOLVIS_CONNECTED | Es existiert eine Verbindung sowohl zur SolvisRemote als auch SolvisControl. |
SOLVIS_DISCONNECTED | Es fehlt aktuell einen Verbindung zur Solvis-Anlage (< 3 Minuten). |
ERROR | Die Solvis-Anlage hat einen Fehler gemeldet. Abhängig von der base.xml wurde eine Mail mit einer Hardcopy der Fehlermeldung verschickt. |
Human Access Status
Hierüber wird mitgeteilt, ob der Anwender/Service auf die SolvisControl zugegriffen hat. Diesen Zustand sendet der Server unter dem Topic
topicPrefix/unitId/human_access.
Das FHEM-Modul nutzt dazu das Reading HumanAccess. Dieser Status kann die folgenden Werte annehmen:
MQTT | FHEM | Bedeutung |
---|---|---|
HUMAN_ACCESS_FINISHED | none | Kein Zugriff durch den Anwender/Service |
USER_ACCESS_DETECTED | user | Zugriff durch den Anwenderwurde erkannt |
SERVICE_ACCESS_DETECTED | service | Zugriff durch den Service wurde erkannt |
Ein Service-Zugriff wird dann erkannt, wenn entweder in das Schornsteinfeger-Menü gewechselt wird oder in den Installateur-Bereich der SolvisControl gegangen wird. Der Service-Zugriff wird erst wieder nach 2h ohne Gui-Eingriff zurückgesetzt, der Anwenderzugriff schon nach 5 Minuten (bei base.xml-Standardwerten). Bei aktiviertem Feature PowerOffIsServiceAccess geht der Server davon aus, dass ein Wiedereinschalten der Anlage ein Service-Zugriff ist. Ein erkannter Zugriff durch den Service kann vorzeitig durch den Server-Befehl SERVICE_RESET beendet werden (siehe hier).
Zu beachten:
Die Erkennung des Service-Zugriffs ist sicher nicht perfekt, es setzt voraus, dass der Service wirklich in den Installateur-Bereich wechselt oder den Schornsteinfeger-Screen auswählt. Bei aktiviertem Feature PowerOffIsServiceAccess erfolgt das automatisch nach Einschalten der Anlage, was vermutlich auch meist der Fall sein wird. Trotzdem ist es zu empfehlen über die Server-Befehle GUI_COMMANDS_DISABLE und GUI_COMMANDS_ENABLE den Gui-Zugriff durch den Server vorher zu deaktivieren und danach wieder zu aktivieren.
Gui Access Status
Hierüber wird mitgeteilt, ob der Server auf die SolvisControl zugreift. Zum Zugriff auf das Gui der SolvisControl 2 nutzt der Server eine Queue. Ihren Zustand sendet der Server unter dem Topic
topicPrefix/unitId/gui_access.
Das FHEM-Modul nutzt dazu das Reading Control. Dieser Status kann die folgenden Werte annehmen:
MQTT | FHEM | Bedeutung |
---|---|---|
CONTROL_FINISHED | finished | Sämtliche Gui-Zugriffe sind abgeschlossen. |
CONTROL_MONITORING | monitoring | Es erfolgt ein Monitoring einer Gui-Seite. |
CONTROL_READ_ONGOING | rd_ongoing | Es erfolgen ein oder mehrere Lesevorgänge von Gui-Seiten. |
CONTROL_WRITE_ONGOING | wr_ongoing | In der Queue befindet sich mindestens ein Schreibvorgang auf eine Gui-Seite. |
Anlagenabhängige Befehle
Diese Anlage betrifft eine bestimmte Anlage, die im MQTT-Topic mit gesendet werden muss (der SolvisSmartHomeServer unterstützt mehrere Solvis-Anlagen).
Anlagenspezifische Server-Befehle
Über das Topic
topicPrefix/smartHomeId/unitId/server/cmnd
kann ein Unit-spezifischer Server-Befehl angestoßen werden. Das Server-Client-Interface stellt diese Funktionalität über den SET/ServerCommand zur Verfügung. Folgende Befehle sind aktuell möglich (Stand 15.06.2021):
Befehl | Bedeutung |
---|---|
SCREEN_RESTORE_INHIBIT | Am Ende eines Gui-Befehls wird normalerweise der Bildschirm wieder angefahren, der vorher (durch Anwender) ausgewählt war. Mit diesem Befehl wird dieses Verhalten deaktiviert. Der Bildschirm bleibt auf dem letzten durch den Server angefahrenen Bildschirm stehen. |
SCREEN_RESTORE_ENABLE | Gegenstück zu SCREEN_RESTORE_INHIBIT. |
COMMAND_OPTIMIZATION_INHIBIT | Normalerweise werden die Befehle der Queue optimiert. Unnötiges mehrfaches Lesen wird verhindert. Dieses Verhalten kann mittels dieses Befehls deaktiviert werden. |
COMMAND_OPTIMIZATION_ENABLE | Gegenstück zu COMMAND_OPTIMIZATION_INHIBIT. |
GUI_COMMANDS_DISABLE | Durch diesen Befehl wird der Zugriff auf das Gui der SolvisControl verhindert. Dies ist beispielsweise dann sinnvoll, wenn der Service im Haus ist und er durch den Eingriff des SolvisSmartHomeServers nicht irritiert werden soll. |
GUI_COMMANDS_ENABLE | Gegenstück zu GUI_COMMANDS_DISABLE. |
SERVICE_RESET | Löscht den Service-Zugriff. Man muss nicht 2h warten, bis er automatisch zurück gesetzt wird. |
UPDATE_CHANNELS | Der SolvisSmartHomeServer aktualisiert nicht von sich aus die Gui-Kanäle. Dies muss man entweder kanalabhängig mittels des Update-Befehls anstoßen. Alternativ dazu kann man auch das Lesen sämtlicher Gui-Readonly-Kanäle mittels des _UPDATE_CHANNELS-Befehls starten. |
DEBUG_CLEAR | Sämtliche DEBUG-Einstellungen werden gelöscht. |
Der Screen-Command
Normalerweise versucht der Server nach der Ausführung von Gui-Befehlen den Screen anzufahren, den der Anwender zuletzt ausgewählt hatte. Die Voraussetzung hierzu ist, dass der Server den ausgewählten Bildschirm auch kennt.
Dieses Verhalten kann man durch den Screen-Befehl ändern. Mit ihm kann man einen bestimmten Bildschirm auswählen, der nach Ausführung eines Gui-Befehls oder nach dem Ende des Anwender-Zugriffs automatisch wieder angefahren wird.
Dies erfolgt mit dem Topic
topicPrefix/smartHomeId/unitId/screen/cmnd.
Unter der Server-Client-Schnittstelle (FHEM) ist es der Befehl SET/SelectScreen.
Die Namen der Screens, welche dem Befehl übergeben werden können, kann man der Konfigurations-spezifischen Dokumentation (CSV-Datei) entnehmen. Sie wird hier beschrieben.
Der Debug-Channel-Befehl
Zum Austesten der Smarthome-System/SmartHomeServer-Kombination auf bestimmte Anlagenzustände kann man die Anlage nicht immer in den gewünschten Zustand bringen. Das ist manchmal physikalisch unmöglich (niedrigere Temperaturen als die Umgebung) oder wäre auch Energieverschwendung. Um trotzdem solche Funktionen überhaupt testen zu können, können die Kanäle auf bestimmte Werte gesetzt werden. Dazu dient der DebugChannel-Befehl.
Der Debug-Channel hat folgendes MQTT-Topic:
topicPrefix/smartHomeId/unitId/debugChannel/cmnd
Unter der Server-Client-Schnittstelle (FHEM) ist es der Befehl SET/DebugChannel. Diesem Befehl muss ein Wert eins der folgenden Formaten übergeben werden:
- Kanalname=Wert
- Kanalname
Mit dem ersten Format setzt man einem bestimmten Kanal auf einen festen Wert zu. Dieser Wert bleibt solange erhalten, bis der Wert von einem neuen DebugChannel-Befehl überschrieben wird.
Mit einem Wert des zweiten Formats deaktiviert man für diesen Kanal den Debug-Wert, der Wert des Kanals stellt wieder den der Anlage dar.
Will sämtliche Debug-Werte wieder zurücksetzen, kann man auch den anlagenspezifischen Server-Befehl DEBUG_CLEAR (wie hier beschrieben) verwenden.