Tipp: Man kann beide Rules zu einer Rule zusammenfassen.
Code: Alles auswählen
import java.math.BigInteger // we need this for testBit
// rule immer unique
rule "update OWD2 register"
when
Member of gLight received command
then
var register = (Reg_Image.state as DecimalType).toBigDecimal.toBigInteger // use existing image
logInfo("OWD2update","update for {}",triggeringItem.name)
var Number nReg = -1
switch triggeringItem.name { // act on switched Item name to change only one bit
case "Bedroom_Light" : nReg=0
case "Bathroom_Light" : nReg=1
case "Kitchen_Light_1" : nReg=2
case "Kitchen_Light_2" : nReg=3
case "LivingRoom_Light_1" : nReg=4
case "LivingRoom_Light_2" : nReg=5
case "LivingRoom_Light_3" : nReg=6
case "Stairwell_Light" : nReg=7
}
if(nReg > -1) {
register = (if(receivedCommand == ON) register.setBit(nReg) else register.clearBit(nReg)
// at last, write to Modbus
Reg_Image.sendCommand(register)
} else
logWarn("OWD2update","Something went wrong! Can't find Bit for {}!",triggeringItem.name)
end
Beim Import bin ich mir ziemlich sicher, dass der in OH2 nicht mehr gebraucht wird, aber sicherheitshalber...
Die Prüfung des Status des triggernden Items ist hingegen Unsinn, denn dieser Status spielt ja nun zu keinem Zeitpunkt eine Rolle.
Das Kommando kann (mal vorausgesetzt, alle Member der Gruppe gLight sind vom Typ Switch) nur ON oder OFF heißen, es gibt kein anderes Kommando. Womit hier hervorragend der ternäre Operator eingesetzt werden kann.
Die Wertzuweisung nach register ist abhängig vom receivedCommand, welches Bit beeinflusst wird, wird vorher durch switch festgelegt. Sollte aus irgendeinem Grund switch keinen Wert setzen, wird auch nichts nach Reg_Image geschrieben.
Weiterhin habe ich die logWarn Zeile oben gegen logInfo getauscht (man könnte sogar darüber nachdenken, hier auf logDebug zu gehen) und lasse unten nur bei Fehlschlag ein logWarn ausgeben.
Ich hab gerade heute davon gelesen, dass jemand logWarn einsetzt, weil die Zeilen im Log farblich hervorgehoben werden. Das ist, mit Verlaub, am System vorbei.
Man kann das LogLevel (für jeden Logger einzeln, weshalb es sinnvoll ist, jeder Rule einen eigenen Logger zu spendieren) zur Laufzeit von openHAB festlegen, sprich, man muss keine log-Anweisungen auskommentieren, um sie zu unterdrücken. Ebenfalls kann man sowohl in frontail (Das Log im Browser) als auch auf der Kommandozeile komfortabel die Ausgaben des Logs filtern, wenn man Angst hat, die entscheidenden Zeilen zu verpassen.
Die verschiedenen log Level sind ausschließlich dazu da, verschieden wichtige Meldungen zu erzeugen, nebensächlich (DEBUG), informativ (INFO), wichtig (WARN), extrem wichtig (ERROR). Wenn man nur wichtige Meldungen sehen möchte, ändert man das log Level auf WARN und bekommt in der Folge weder INFO noch DEBUG zu sehen. Man kann das log sogar komplett stumm schalten, was verschiedentlich für Erweiterungen schon notwendig war, da z.B. für konfigurierte, aber abgeschaltete Geräte ständig ERROR-Meldungen kamen (bis ein Entwickler den korrekten logLevel dafür eingebaut hat - Debug)
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet