Ich springe hier mal bei, um ein wenig Licht ins Dunkel zu bringen.
Die UI von openHAB ist dazu gedacht, Items bzw. deren Status anzuzeigen und/oder zu manipulieren (also Schalter AN/AUS).
Deshalb kann openHAB bis auf wenige Ausnahmen auch nichts anderes in eine UI einbetten.
Die Ausnahmen sind Webview, Mapview, Image, Video und Chart, wobei auch diese Elemente ihre Steuerinformationenen gewöhnlich aus Items beziehen.
Du musst also zwingend ein Item verwenden, wenn Du irgendeinen Zahlenwert oder gesteuerten Text anzeigen lassen möchtest.
Glücklicherweise muss man bei der Definition eines Items kein Binding oder auch Channels angeben. Es reicht also ein ungebundenes Item vom passenden Typ, um den errechneten Wert anzuzeigen.
var/val: var steht für Variable, also ein Platzhalter, dessen konkreter Wert (das, was darin gespeichert ist) variabel, also veränderbar ist. Der Gegensatz dazu ist val, das steht für Value, also ein Wert. Dieser Wert ist aber zur Laufzeit nicht änderbar, einmal festgelegt, bleibt er so, wie er ist, er ist also konstant.
Code: Alles auswählen
var int iMyInterger = 5
val int cMyInteger = 5
rule "Testrule"
when
Time cron "0 0 18 * * ?" // einmal täglich 18 Uhr
then
iMyInteger = iMyInteger + 1 // klappt, da variabel
cMyInteger = cMyInteger + 1 // Fehler, da konstant
end
Gemein wird es dann, wenn ich innerhalb einer Rule ein val einsetze. Auch hier darf der Wert nicht mehr verändert werden. Wenn die Rule aber beendet wird, wird auch die Konstante wieder aus dem Speicher entfernt. Beim nächsten Aufruf der Rule darf der Konstanten also erneut einmalig ein Wert zugewiesen werden. Der Unterschied besteht vor allem darin, wie der Speicher für Variablen und Konstanten verwaltet wird.
Code: Alles auswählen
logInfo("Prognose_PV_Leistung",Prognose_PV_Leistung.toString)
ist eine Action, die im Logging einen Eintrag der Stufe
INFO erzeugt. Es gibt auch
logDebug(),
logError() und
logWarn().
Der Witz einer solchen Zeile, und warum es dafür vier verschiedene Actions gibt, ist, dass man das Logging während der Laufzeit von openHAB steuern kann, und zwar extrem kleinteilig. Der erste Parameter von
logInfo() ist der Loggername (genauer der letzte Teil des Loggernamens). Wenn man das Logging für diesen Loggernamen auf
WARN setzt, wird
logInfo() keine Ausgabe mehr erzeugen,
logWarn() aber weiterhin. Wenn man das Logging auf
DEBUG setzt, werden zusätzlich auch
logDebug() Anweisungen eine Ausgabe erzeugen.
Es ist also sinnvoll, solche
logInfo() Actions überall da einzusetzen, wo man gerne recht genaue Informationen haben möchte, was gerade in der Rule abgeht. Wenn die Verarbeitung der Rule ungewöhnliche Randbedingungen vorfindet, bietet sich ein
logWarn() an, wenn ein krasser Fehler auftritt, ein
logError(). Wenn man eine sehr umfangreiche Rule schreibt, kann es auch sinnvoll sein, an weiteren Stellen z.B. Zwischenergebnisse mit
logDebug() ausgeben zu lassen. Man lässt dann das Logging auf
INFO oder auf
WARN, nur wenn es Probleme gibt, dreht man das Logging auf und bekommt dann zusätzliche Informationen.
Das Logging von Karaf (das ist die von openHAB eingesetzte OSGI-Schicht) ist extrem mächtig, man kann z.B. auch bestimmte Logs in separate Dateien laufen lassen, default landet alles erstmal in
openhab.log, bis auf Events, die landen in
events.log
Der zweite Parameter ist die eigentliche Information, die geloggt werden soll. Die zitierte Zeile ist nicht so ganz korrekt, denn der Loggername wird hier für Klartext missbraucht. Da dieser Klartext auch noch recht lang ist, wird die automatische Formatierung des log Files hier zerstörerisch wirken. Korrekt sähe das eher so aus:
Code: Alles auswählen
logInfo("pvCalc","Prognose_PV_Leistung: {} Wh",Prognose_PV_Leistung)
Diese Zeile bewirkt eine Logzeile in dieser Form:
Code: Alles auswählen
2018-05-17 16:28:39.482 [INFO] [.e.model.script.pvCalc] Prognose_PV_Leistung: 45321.12345 Wh
Für erste Schritte mit openHAB2 empfehle ich dringend, openHAB2 frisch zu installieren und dann die Demo auszuwählen. Dabei wird automatisch eine Konfiguration eingespielt, die zum einen einige Dinge zeigt, die so möglich sind, zum anderen kann man sich die Konfigurationsdateien prima anschauen und so verstehen, die openHAB tickt. Ich nutze openHAB seit Version 1.0 und habe es exakt so gemacht. Ich habe erst nach praktisch kompletter Inbetriebnahme erste Fragen gehabt, z.B. weil ich einen Zeitstempel aus der Persistence auslesen wollte (was bisher zumindest mit erheblichem Aufwand verbunden war), aber für die Grundfunktionen musste ich nicht mal groß im Wiki stöbern, das ergab sich alles praktisch von selbst aus der Demo.
Weiterhin möchte ich empfehlen, für ein Produktivsystem eine zweite openHAB Instanz separat einzurichten. Dabei kann man im Hinterkopf behalten, dass openHAB hervorragend auf kleinen Systemen läuft. Es reicht also z.B. auch eine kleine virtuelle Maschine, auf der dann freilich z.B. Debian werkeln muss - extra ein Windows dafür hochzuziehen ist albern
Falls Du aber noch eine ältere Gurke dastehen hast, die eh nur zustaubt, kann auch auf dieser eine Instanz laufen. Auf dem einen System kannst Du dann nach Herzenslust testen, auf dem anderen läuft das, was bisher für gut befunden wurde.