Interne Komponenten des SolvisSmartHomeServer - GollmerSt/SolvisSmartHomeServer GitHub Wiki

Der SolvisSmartHomeServer besteht folgenden Funktionseinheiten

Server

Der eigentliche Server stellt die Schnittstelle nach außen dar. Er nimmt Verbindungen von bis max. 50 Clients entgegen, interpretiert deren Befehle und sendet die Solvis-Daten an die Clients.

MQTT Client

Neben der Server-Client-Schnittstelle kann der „Server“ auch als MQTT-Client in das „IoT“ eingebunden werden. Auf diese Weise ist es möglich ohne einen speziellen Client den Server mit einem SmartHome-System zu betreiben. Voraussetzung für das Smarthome-System ist, dass für diesen ein MQTT-Client/Server zur Verfügung steht.

Messwerte-Erfassung

Diese fragt regelmäßig (default alle 10s) den Solvis-Hex-String (siehe hier) mit den Messwerten ab, interpretiert den Hexstring und sendet bei einer Änderung dem Client die gemessenen Werte.

Für bestimmte Daten (Temperaturen) erfolgt eine Mittelwertbildung über eine Messwerte-Reihe (Default: 12, entspricht ein Zeitraum von 2 Minuten). Erkennt dabei das Modul einen Wert, der vom Mittelwert stärker abweicht als die normale Schwankungsbereich des Sensors, wird der Wert bei der Mittelwertbildung mehrfach gewichtet(abhängig von der Abweichung), so dass der vom Modul gelieferte Wert trotz Mittelwert-Bildung dem wirklichen Wert bei größeren Änderungen besser folgt (z.B. bei Aufheizung des Kesselwassers durch laufenden Brenner in der höchsten Stufe).

Der Schwankungsbereich eines Sensors ermittelt der Server näherungsweise aus dem Mittelwert sämtlicher bisher gemessenen Absolutwertdifferenzen zwischen 2 aufeinanderfolgenden Messwerten. Dieser Algorothmus hat sich bei den Solvis-Sensoren als recht brauchbar herausgestellt.

Neben der Mittelwertbildung ist auch eine Hysteresis eingebaut. Dies ist notwendig um die Anzahl der zum Smarthome-System gesendeten Werte zu reduzieren, welche in der realität keine weitere information beinhalten. Auch die Größe der Hysteresis ist von der Schwankungsbreite der Sensoren abhängig.

Wie stark sich ständig die Messwerte ändern, kann man den Anlagenstatus auf der Solvis-Control oder des Webseite Anlagenschema erkennen. Bei mir ist es stark Sensor-abhänig.

Auswertung und Steuerung über die SolvisControl-Bildschirme

Zur Interpretation des Bildschirminhalts wurde ein abgespecktes OCR realisiert, das folgende Zeichen der SolvisControl erkennen kann:

+ - 0 1 2 3 4 5 6 7 8 9 ° C [ ] : . / h %

Zur Identifikation der einzelnen Screens werden gezielt bestimmte rechteckige Flächen der Screen untersucht. Zusätzlich kann auch der Identifikation das OCR herangezogen werden. So wird für Screens der Heizkreise nur die Überschrift herangezogen, welche einzelne Screen gerade angezeigt wird, wird durch die Detektion der Nummern rechts von der Überschrift erkannt (z.B. 14/5, Heizkreis 1, Bild 4 von 5) Das in Wirklichkeit vorhandene Leerzeichen wird vom OCR nicht beachtet, da es zur Unterscheidung nicht notwendig ist und ohne wirklichen Nutzen ein höhere Aufwand in der OCR-Erkennung notwendig gewesen wäre.

Der erste Versuch eine kostenlose Library zur OCR-Erkennung zu verwenden schlug fehl, da teilweise auch sehr kleine Schriften erkannt werden müssen, bei der die Pixelzahl für ein Zeichen bei der SolvisControl2 recht gering sind. Daher wurde ein auf diese wenigen Zeichen reduzierter spezieller Algorithmus entwickelt.

Weitere Auswertungen des Solvis-Bildschirms

Ändert sich der Bildschirminhalt der Solvis-Anlage ohne dass der Server dies initiiert hat, so wird die erfolgte Änderung in folgender Weise analysiert:

Bildschirmschoner

Es wird untersucht, ob die Änderung durch den Bildschirmschoner erfolgt ist. Den Bildschirmschoner erkennt der Server anhand der relativen Lage der Zeit- und Datumsfelder.

Ein erkannter Bildschirmschoner bewirkt keine weiteren Aktionen.

Meldungs-Box-Erkennung

Der Bildschirm wird in den Ruhephasen auch auf eine Meldungs-Box untersucht. Dazu werden die Lage der Umrandung der Box sowie der Strich unter der Überschrift der Meldung analysiert. Hier ein Beispiel einer solchen Message-Box:

Störungsanzeige

Wird eine Meldung erkannt, so wird der Status der Anlage im Server auf den Status ERROR. Ist die ExceptionMail in der base.xml eingerichtet, wird zusätzlich eine Hardcopy des Bildschirminhalts an die in base.xml eingetragenen Mail-Empfänger versendet. Zusätzlich werden die letzten 100 Fehlerbildschirme in den Ordner
<beschreibarer Pfad>/SolvisServerData/SolvisErrorImages abgegt.

Anschließend gibt es noch zwei unterschiedliche Behandlungen, je nachdem das Feature „ClearErrorMessageAfterMail“ im base.xml gesetzt ist.

  • Im Falle von ClearErrorMessageAfterMail = “false”, bleibt die Meldungsbox bestehen, die GUI-Steuerung ist dadurch blockiert!
  • Im Falle von ClearErrorMessageAfterMail = “true”, wird nach erfolgreichem Mail-Versand der Hardcopy mit dem <<-Button zum HomeScreen zurückgegangen. Die GUI-Steuerung ist nicht blockiert.

Der Status ERROR des Servers bleibt auch nach dem Verschwinden der Meldungsbox noch bestehen. Es wird automatisch in den Homescreen gewechselt und der dortige Button mit dem Warndreieck untersucht. Erst wenn dieses Warndreieck verschwunden ist, wird der ERROR-Status gelöscht (siehe auch 6.5.4).

Error-Button-Erkennung auf dem HomeScreen

Im Fehlerfall der Anlage wird anstelle der Datums/Uhranzeige ein Button mit einem Warndreieck eingeblendet. Hier ein Beispiel:

In Wirklichkeit erkennt der Server nicht den Button (das würde ein Provozieren eines Fehlers in der Lern-Phase erfordern) sondern die fehlende Einblendung von Zeit und Datum.

Dieser Button ist quasi der Summen-Button für alle gemeldeten Fehler der Anlage. Ist noch ein Fehler aktiv, dessen Meldung schon weggeklickt wurde, dann wird das durch diesen Button kenntlich gemacht.

Erkennt der Server diesen Button, geht der Status des Servers auf ERROR (falls er nicht schon ist). War vorher der ERROR-Status noch nicht gesetzt, wird auch einen Mail mit der Hardcopy verschickt (falls die Exception-Mail eingerichtet ist).

Ist der ERROR-Status gesetzt werden GUI-Befehle immer ausgeführt. Nach der Ausführung wird immer wieder zum Home-Screen zurück gegangen und es wird weiter der Error-Button beobachtet. Erst wenn dieser verschwindet wird der ERROR-Status des Servers zurück gesetzt und es wird zur letzten vom User ausgewählte Seite gegangen.

Nachheizen-Monitoring

Wird das nachheizen angestoßen (C46.WarmwasserNachheizen), so wird der Screen "Wasser" solange beobachtet, bis das Nachheizen beendet ist. In dieser Zeit bleibt der Kanal C46.WarmwasserNachheizen auf dem Wert heating. Ist das Nachheizen beendet, so wechselt der Kanal in den Zustand off.

Nachheizen aktiv

Beim Monitoring wird der im obigen Bild rot umrandete Kreis beobachtet. Ist er gefüllt, ist Nachheizen aktiv, ist er leer, ist Nachheizen beendet.

Anwender-/Service-Erkennung

Erfolgte eine Änderung des Bildschirms ohne vom Server veranlasst ist und es werden weder der Bildschirmschoner noch der beiden Fehler-Darstellungen erkannt, so geht der Server davon aus, dass der Anwender in die Anlage eingegriffen hat. Er sperrt dann für eine bestimmte Zeit (in base.xml definiert) die GUI-Command-Ausführung.

Werden eins der folgenden Bildschirme erkannt, dann geht der Server von einem Eingriff eines Service-Mitarbeiter aus:

Schornsteinfeger-Screen Nuzer-Eingabe Code

In diesem Fall wird ebenfalls die GUI-Steuerung gesperrt, dies jedoch deutlich länger (default 2h, in der base.xml konfigurierbar). Auf diese Weise wird verhindert, dass ein Service-Mitarbeiter durch den Eingriff des Servers irritiert wird und von einem falschen Fehler ausgeht.

Logging

Zur Fehlersuche werden wesentliche Infos und Fehlermeldung in Log-Dateien geschrieben. Diese werden in den im base.xml definierten beschreibbaren Pfad geschrieben. Seit der Version 1.00.11 ist die Namenskonvention dieser Log-Dateien folgende:

solvis-tiny.log.*: In diese Datei werden sämtliche Logmeldungen geschrieben

solvis-error.log.*: In diese Datei werden nur die Fehlermeldungen geschrieben

Die Unterscheidung dieser beiden Log-Typen erfolgt, da normalerweise in die normale Log-Datei deutlich mehr geschrieben wird als in die Error-Log-Datei. Da die Log-Dateien begrenzt sind (5MByte für die Standard-, 2 MByte für die Error-Datei), kann es sein, dass wichtige Fehlermeldungen in dieser Datei schon nicht mehr vorhanden sind. Wenn man den Log-Level auf Debug setzt, kann das – je nach Konfiguration - schon innerhalb eines Tages erreicht sein.