Anhang - GollmerSt/SolvisSmartHomeServer GitHub Wiki
Ü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. |
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.
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.
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 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:
- FHEM (falls vorhanden) liegt im Verzeichnis /opt/fhem
- Der SolvisSmartHomeServer wird im Verzeichnis /opt/solvis/SolvisSmartHomeServer installiert
- 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.