Anhang - GollmerSt/SolvisSmartHomeServer GitHub Wiki

Kommando-Zeilen-Parameter

Übersicht über die Kommando-Zeilen-Parameter:

Parameter Bedeutung
--server-learn Lernt die Grafiken an.
--server-terminate Beendet den laufenden Server-Prozess so, dass noch ein Backup-File der aktuellen Messwerte geschrieben werden.
--server-restart Für den Restart des Servers notwendig, damit agentlib-Parameter nach dem Restart möglich sind (Remote-Debug). Dient nur der internen Verwendung, sollte man nicht von der Kommandozeile aus nutzen.
--string-to-crypt Ermittelt aus einem Wort/Phrase einen AES-256 verschlüsselten Wert. Syntax ist folgende:
--string-to-crypt=Word
--test-mail Sendet eine Test-Mail an die im base.xml angegeben Mailadressen
--base-xml Hiermit kann eine spezielle base.xml verwendet werden, welche sich nicht im dem Start-Pfad des SolvisSmartHomeServers befindet. Der angegeben Pfad kann auch Environment-Variablen enthalten. Diese werden wie bei Windows in %-Zeichen eingeschlossen. Beispiel:
--base-xml=%SOLVIS_SMART_HOME_SERVER_BASE_XML%
--documentation Schreibt die aktuellen Kanaldefinitionen samt Meta-Beschreibung im Csv-Format (Semikolon-separiert) in die Datei Appendix\SolvisDocumentation.csv in das im base.xml angegeben beschreibbare Verzeichnis. Zusätzlich werden die Screen-Ids dokumentiert, welche mit dem Server-Befehl SelectScreen genutzt werden können.
Zu beachten:
Der Aufruf dieser Option ist erst dann möglich, wenn der Learning-Vorgang fehlerfrei abgeschossen wurde, da ein Teil der Konfiguration aus dem GUI ermittelt wird. (Ab 01.03.00)
--channels_of_all_configurations Schreibt die aktuellen Kanaldefinitionen sämtlicher aktuell möglicher Konfigurationen samt Meta-Beschreibung im Csv-Format (Semikolon-separiert) in die Datei Appendix\SolvisAllChannels.csv in das im base.xml angegeben beschreibbare Verzeichnis (aktuell 324 Konfigurationen). (Ab 01.03.00)
--iobroker Schreibt eine Objektliste und ein Pairing-Skript in den Appendix-Ordner des im base.xml angegebene beschreibbaren Verzeichnisses.
Zu beachten:
Der Aufruf dieser Option ist erst dann möglich, wenn der Learning-Vorgang fehlerfrei abgeschossen wurde, da ein Teil der dafür notwendigen Konfiguration aus dem GUI ermittelt wird. (Ab 01.03.00)
--csvSemicolon Das Separier-Zeichen der Csv-Ausgaben (--documentation/--channels_of_all_configurations) ist das Semikolon (Standard: Komma). (Ab 01.03.00)
--create-task-xml Erstellt während der Windows-Installation die notwendige Task.xml. Ist eine Quick-And-Dirty-Lösung, da ich nicht geschafft habe, mittels InnoSetup eine entsprechende Datei zu generieren (UTF-16LE mit Byte Order Mark). Andere Formate, welche die Aufgabenverwaltung annimmt, habe ich nicht gefunden. Warum Windows dort so restriktiv ist, ist mir ein Rätsel. Die Syntax ist folgende:
-- create-task-xml =Pfad des base.xml-Files
--onBoot Im Zusammenhang mit --create-task-xml zu verwenden. Der erstellte Windows-Task startet des SolvisSmartHomeServer nach jedem Boot-Vorgang, andernfalls erst mit der User-Anmeldung.

Dateien

Folgende Dateien dienen der Konfiguration und der Datenablage des Programmes:

Name Beschreibung
base.xml Hier finden sich die wesentlichen Anlagen-, Anwender- und Netzwerk-spezifischen Konfigurationsdaten. Sie ist hier beschrieben.
control.xml Enthält die wesentlichen Informationen. Dort sind die Daten enthalten, welche Bildschirmbereiche zur Identifikation der Bildschirme herangezogen werden müssen, welche Touch-Points unter welchen Umständen gedrückt werden müssen, die Auswertungsinformation für die Daten des Hex-Strings sowie weitere programmbezogene Daten.
log4j2.xml Datei zur Steuerung des Log4j2-Loggings (wird aktuell nicht genutzt, durch TinyLog ersetzt).
tinylog.properties Datei zur Steuerung des Tiny-Loggings.
graficData.xml Eine vom Programm generierte Datei mit den zur Identifikation der Bildschirme notwendigen Bildausschnitten. Diese Datei wird beim Learning generiert.
measurements.xml Datei mit den Messwerten X*.*. Diese Messwerte werden bei einem Beenden des Programms sowie stündlich (veränderbar im control.xml) gespeichert.

Bis auf die Datei log4j2.xml existiert für jede der XML-Dateien ein XML-Shema. In dieser Datei sind die einzelnen XML-Elemente dokumentiert. Auf eine weitere Dokumentation wird hier daher verzichtet. Wenn jemand die control.xml verändern will, sollte er einen XML-Editor verwenden, der auch mit den XSD-Dateien umgehen kann (z.B. der XML-Editor des Eclipse-Pakets). Auf diese Weise werden die Fehlermöglichkeiten reduziert. In dem Editor kann man sich dann in der Regel zu jedem Attribut/Element auch die dazugehörige Dokumentation ansehen (in Eclipse durch Tool-Tips). Außerdem stellen solche Editoren Pull-Down-Menüs breit, mit dnen man die Atribute/Tags entsprechend dem XSD-Shema auswählen kann.

Die Properties-Datei tinylog.properties

Seit Version V01.00.11 zum Loggen nicht mehr Log4j2 verwendet sonder TinyLog. Dadurch ist das Programmpaket um 2 MByte kleiner geworden (nun 1,4 MByte). Der Fileinhalt sieht wie folgt aus:

writer1             = console  
writer1.level       = error  
writer1.format      = {date: HH:mm:ss,SSS}|{level}|{message}  
writer1.tag         = -  
  
writer2             = rolling file  
writer2.level       = info  
writer2.file        = solvis-tiny.log.{count}  
writer2.format      = [{date: yyyy-MM-dd HH:mm:ss,SSS}] {level} {message}  
writer2.append      = true  
writer2.policies    = size: 1mb  
writer2.backups     = 5  
  
writer3             = console  
writer3.level       = info  
writer3.format      = {date: HH:mm:ss,SSS}|LEARN|{message}  
writer3.tag         = LEARN  

writer4             = rolling file  
writer4.level       = error  
writer4.file        = solvis-error.log.{count}  
writer4.format      = [{date: yyyy-MM-dd HH:mm:ss,SSS}] {level} {message}  
writer4.append      = true  
writer4.policies    = size: 1mb  
writer4.backups     = 2  

writingthread       = false  
autoshutdown        = false  

Wenn mehr geloggt werden soll, ist der Wert des Properties writer2.level von info auf debug zu stellen. Dies ist zur Fehleranalyse u. U. notwendig.

Die XML-Datei log4j2.xml

Bis zur Version V01.00.10 genutzt.

Der Server nutzt log4j2 von der Apache Software Foundation. Dieses System bietet eine Vielzahl von Möglichkeiten, so ermöglichst es auch das Logging auch in einer Datenbank.

Für den Anwender ist der letzte Abschnitt dieser Datei interessant:

<Async name="Async">
	<appender-ref ref="Solvis" level="info" />
	<appender-ref ref="Console" level="LEARN"/>
	<appender-ref ref="Solvis-Error" level="error"/>
	<!-- appender-ref ref="RFC5424" level="info"/ --> <!-- Database logging -->
</Async>

Der erste Appender (Solvis) schreibt in die Datei solvis.log. In der obigen Einstellungen werden alle Levels ab info dort reingeschrieben. Zur Fehlersuche ist es sinnvoll info durch debug zu ersetzen. Dann liefert der Log noch mehr Informationen.

Der zweite Appender (Console) bestimmt, was auf die Konsole geschrieben wird. Mit der obigen Definition werden nur die Ausgaben des Lern-Vorgangs sowie Fehlermeldungen ausgegeben. Läuft der Server als Service, kann man die letzten Meldungen mittels sudo systemctl status ausgeben lassen.

Der dritte Appender (Solvis-Error) bewirkt, dass Fehlermeldungen in eine Extra-Datei mit dem Namen solvis-error.log geschrieben werden.

Der letzte auskommentierte Appender (RFC5424) wäre für ein Datenbank-Logging notwendig. Der ist aktuell nicht aktiv und die in der log4j2.xml dazu notwendigen Teile habe ich einfach die verwendet, die ich auch in der Arbeit verwende. Das erfordert noch weitere Infrastruktur, daher ist das erst mal auskommentiert.

Das Makefile

Das makefile wird wie folgt aufgerufen:

sudo make Ausführungs-Rule

Folgende Ausführungs-Rules sind möglich:

Rule Bedeutung
install Installation des Servers als auch FHEM-Moduls
installService Einrichten des Servers als Service
installDebugService Einrichten des Servers als Service im Remote-Debug-Mode. Es wird dazu der Port 10736 genutzt. Solange der Server läuft wird dieser Port beobachtet. Aus Sicherheitsgründen sollte der Server daher wirklich nur für Debug-Zwecke in diesem Mode gestartet werden.
installFHEM Installation nur des FHEM-Moduls
installSolvis Installation des Servers
uninstall Deinstallation des Servers als auch des FHEM-Moduls
uninstallAll Löscht sämtliche Dateien, auch die, welche vom Programm selber erstellt wurden. Dies ist dann sinnvoll, wenn man das Programm komplett entfernen will oder eine vollständige Neuinstallation durchführen will (normalerweise nicht notwendig).
uninstallFHEM Deinstallation des FHEM-Moduls
uninstallSolvis Deinstallation des Servers
uninstallService Server ist nicht mehr ein Service des Systems
uninstallDebugService Server (im Debug-Mode) ist nicht mehr ein Service des Systems.
update Bei einer neuen Version. Der Service wird dabei gestoppt, die Dateien (auch der FHEM-Client) werden ausgetauscht und der Server wird wieder gestartet
updateSolvis Bei einer neuen Version. Der Service wird dabei gestoppt, die Dateien (ohne den FHEM-Clienten) werden ausgetauscht und der Server wird wieder gestartet
learn Lernmodus des Servers starten. Im Anschluss wird der Service wird der Service wieder gestartet
documentation Schreibt die aktuellen Kanaldefinitionen samt Meta-Beschreibung im Csv-Format (Semikolon-separiert) in die Datei Appendix\SolvisDocumentation.csv in das im base.xml angegeben beschreibbare Verzeichnis. Zusätzlich werden die ScreenIds in dieses Csv-File geschrieben, welche vom Server-Befehl SelectScreen genutzt wer4den können. Vor Aufruf des Makefiles mittels dieser Rule muss ein Learning-Vorgang durchgelaufen sein, da einige Konfigurationseinstellungen aus dem GUI der SolvisControl gelesen werden. (Ab 01.03.00)
iobroker Schreibt die Objektliste und ein Pairing-Skript-Datei in den Ordner Appendix in das im base.xml angegebe beschreibbare Verzeichnis. Vor Aufruf des Makefiles mittels dieser Rule muss ein Learning-Vorgang durchgelaufen sein, da einige notwendigeKonfigurationseinstellungen aus dem GUI der SolvisControl gelesen werden. (Ab 01.03.00)
foreground Server im Vordergrund (nicht als Service) starten
debug Der Server wird gestartet, wobei die VM mit einer agentlib-Option (Port 10736) gestartet wird. Damit ist Remote- Debugging des Servers möglich

Das Makefile geht von folgenden Vorgaben aus:

  1. FHEM (falls vorhanden) liegt im Verzeichnis /opt/fhem
  2. Der SolvisSmartHomeServer wird im Verzeichnis /opt/solvis/SolvisSmartHomeServer installiert
  3. Der Server läuft unter dem User solvis

Ist das System etwas anders konfiguriert, ist der Header des Makefiles anzupassen. Im Header des Makefiles finden sich dazu folgende Variablen:

Name Bedeutung
fhemDir Installationsverzeichnis von FHEM
account User-Namen unter dem der Server läuft
serverDir Installationsverzeichnis für den SolvisSmartHomeServer

Mit dem Release V01.05.01 wurde das Makefile so geändert, das hier normalerweise keine Anpassungen mehr notwendig sind, auch dann nicht, wenn kein FHEM auf dem System existiert. Der Server läuft seit V01.05.01 nicht mehr unter dem User fhem sondern unter dem User solvis. Außerdem ist das Default vom writablePathLinux im base.xml auf /opt/solvis geändert worden, ein Verzeichnis, dass das Makefile in der Grundkonfiguration automatisch erstellt und mit den entsprechenden Benutzerrechten versieht.

Es empfiehlt sich seit dem Rrelease V01.05.01 daher nicht diese Einträge zu ändern.

Will man es denoch ändern, ist zu beachten, dass man die Service-Datei SolvisSmartHomeServer.service möglicherweise ebenfalls ändern muss. Dort steht der Aufruf des Servers sowie der Usernamen drin.

⚠️ **GitHub.com Fallback** ⚠️