Wo soll ich anfangen? Da sind so viele für mich offensichtliche Verständnisfehler...
Erstmal Items: Ein Switch Item kennt exakt zwei Befehle, ON und OFF. Es kennt ein paar mehr Status, nämlich neben ON und OFF noch NULL und UNDEF. Nicht zu den möglichen Status gehören Zahlen, genauso wenig kann man Zahlen als Befehle (erfolgreich) an das Item senden.
Ein Number Item kennt Zahlen als Befehle, sonst nichts. Bei den möglichen Status kommen noch die Werte NULL und UNDEF hinzu.
Wie sind die zu schaltenden Items definiert? Du sendest Befehle 0 und 1, das sind keine sinnvollen Befehle für sinnvolle Items zum Schalten von Lampen. Aus den Namen (Spots und RGB) ergeben sich für mich drei Möglichkeiten, Switch, Dimmer oder Color als Item. Nicht sinnvoll wäre Number.
Dies gilt sinngemäß auch für die anderen Items in der zweiten Rule, auch hier fürchte ich Fehler schon in der Itemdefinition.
Nun Widgets in der Sitemap:
Tatsächlich ist
Switch hier das Mittel der Wahl für den Aufruf einer Szene. Aber hier lauert vielleicht gleich ein weiteres Missverständnis, denn Switch Widgets sind mitnichten auf Switch Items beschränkt Es ist immens wichtig, zu erkennen, dass Widgets (in der Sitemap) und Items erst mal nichts miteinander zu tun haben. Freilich kann man Items an Widgets binden, um das Item über das Widget zu steuern.
Jetzt zu der Szene: Eine Szene wird aufgerufen. Eine Szene ist aber per Definition nicht "aktiv" (auch wenn das gerne so betrachtet wird).
Das heißt, ein Item, welches eine Szene aufruft, sollte
nicht den Zustand behalten, sondern wieder verlieren.
Du hast zwei Szenen, eine zum Einschalten, eine zum Ausschalten, und Du könntest noch weitere Szenen anlegen (z.B. das eine an, das andere aus), Das Item für die Szenen wäre also am ehesten ein Number Item, keinesfalls ein Switch Item.
Eine sinnvolle Definition des Items wäre
Code: Alles auswählen
Number PoolSzene "Pool Szene" <light> (gSzenen) ["Lighting"] {autoupdate="false"}
Das passende Widget sieht dann so aus:
Du erhältst also zwei Knöpfe, auf dem einen steht "AUS", auf dem anderen "Nacht", und die "Überschrift" lautet "Pool Szene". Solltest Du das Item per Sprachbefehl ansteuern, so müsstest Du allerdings ziemlich sicher "Null" und "Eins" sagen, wobei das Tag "Lighting" hier vielleicht auch "An" und "Aus" ermöglichen wird, aber es gibt keine eindeutige Zuordnung. Ich habe keine Erfahrung mit Alexa, da müsste jemand anderes aushelfen. Im Zweifel könnte man aber auch ein String Item verwenden und dort die Schlüsselworte nutzen, ist aber fraglich, wie man dann taggen muss...
Nun zu den Rules:
Die erste Rule kann niemals triggern, weil das Item niemals einne korrekten Wert bekommt (siehe oben) Wenn es um eine Eingabe über die UI geht, ist aber der korrekte Trigger
received command
Ich sehe unheimlich oft Rules, die auf
received update triggern sollen. In etwa 1% der Fälle ist dieser Trigger die richtige Wahl. Auch hier trifft das nicht zu.
received update wird jedes Mal ausgelöst, wenn der
Status des Items
aktualisiert wurde.
changed wird jedes Mal getriggert, wenn sich der
Status des Items
geändert hat.
received command wird jedes Mal getriggert, wenn das Item einen
Befehl empfangen hat.
Gegeben, dass die Items so definiert sind:
Code: Alles auswählen
Number PoolSzene "Pool Szene" <light> (gSzenen) ["Lighting"] {autoupdate="false"}
Number PoolPumpe "Pumpenmodus"
Switch P3PoolSpots "Pool Spots" <light> ["Lighting"] {channel="..."}
Switch RGBP3Pools "Pool RGB Spots" <light> ["Lighting"] {channel="..."}
wäre also diese Rule passend:
Code: Alles auswählen
rule "Pool Szenen"
when
Item PoolSzene received command
then
logDebug("poolscene","empfangener Befehl ({})",receivedCommand)
switch(receivedCommand.toString) { // abhängig vom empfangenen Befehl
case "0" : {
logDebug("poolscene","Szene 0 erkannt")
PoolPumpe.postUpdate(0)
P3PoolSpots.sendCommand(OFF)
RGBP3Pools.sendCommand(OFF)
}
case "1" : {
logDebug("poolscene","Szene 1 erkannt")
PoolPumpe.postUpdate(1)
P3PoolSpots.sendCommand(ON)
RGBP3Pools.sendCommand(ON)
}
default : {
logWarn("poolscene","Ungültiger Befehl ({})",receivedCommand)
}
}
end
Die log-Befehle...
Alle Logbefehle erwarten zwei Strings als Parameter. Dabei ist der erste Parameter der zu verwendende Logger, der zweite Parameter ist die zu loggende Meldung. Das heißt, der erste String ist keinesfalls "Neopool-RULE". Die Loggernamen könne zwar frei gesetzt werden, es gibt aber ein paar ungeschriebene Regeln:
- Kleinbuchstaben des englischen Alphabets. Im Ausnahmefall CamelCaseSchreibweise, falls unbedingt nötig noch Ziffern
- Ein Punkt trennt die Hierarchieebene
- keine Sonderzeichen (Leerzeichen, Trennstriche, Unterstriche...)
- kurz
Hinzu kommen Gesetzmäßigkeiten:
Alle Logger werden mittels log4j2 verwaltet. Die Logger aus den Rules erscheinen dabei unterhalb des Knotens org.openhab.core.model.script. im Hierarchiebaum von log4j2. Die Loggerkonfiguration wird dabei grundsätzlich vom übergeordneten Logger geerbt, das heißt, grundsätzlich wird auf der Stufe INFO geloggt, weil diese Stufe für org.openhab.core.model.script konfiguriert ist. Der Logger aus "meiner" Rule taucht dann als
org.openhab.core.model.script.poolscene im Baum auf und ich kann mittels
in der Karaf Konsole verhindern, dass überhaupt Meldungen der Rule im Log auftauchen.
Umgekehrt kann ich mit
dafür sorgen, dass die Rule sehr auskunftsfreudig wird. und quasi jeden einzelnen Schritt dokumentiert.
Mit
Code: Alles auswählen
log:set DEFAULT org.openhab.core.model.script.poolscene
wird nur im Fehlerfall die Meldung des ungültigen Befehls ausgegeben.
Zeige bitte mal die genaue Definition aller Pool-Items (insbeondere auch, mit welchen Channels sie verknüpft sind), evtl. gibt es da noch weitere grundsätzliche Fehler...
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
