Erst mal grundsätzlich: Was Dir vorschwebt, ist keine Steuerung, sondern ein Regelung.
openHAB ist kein Regelsystem, sondern ein Steuersystem.
Natürlich kannst Du (in Grenzen) openHAB als Regelsystem verwenden, Du musst Dir aber bewusst sein, dass es einen Unterschied zwischen den beiden Begriffen gibt.
Frage Text vs. UI: Natürlich kannst Du beide Arten Konfiguration nutzen, ausdrücklich auch im Mischbetrieb, Der Punkt, warum man das eher vermeidet, ist vor allem, dass Du Dich schnell verzetteln kannst. Wo hab ich denn das Thing angelegt? Und wo das Item? ISt die Rule nun als Text oder als UI Rule erstellt? Hab ich das in Blockly gelöst, oder mit Ruby?
Am Ende des Tages musst Du (als derjenige, der das System betreut) durchsteigen, das ist der entscheidende Faktor.
Die DSL ist seit Anbeginn in openHAB eingebaut und sie ist auch als einzige Rule Engine in jeder bisherigen openHAB Version fester Bestandteil. Insofern kann jeder DSL Rules nutzen, ohne Ausnahme, und ohne dass man weitere Randbedingungen erfüllen muss (installiere Addon XY in openHAB, installiere externe Zusatzsoftware a, b oder c, aber Achtung, c verträgt sich nicht mit k, also falls Du k im Einsatz hast...)
Grundsätzlich kann man jede Text DSL Rule auch in die UI überführen, allerdings gibt es Punkte, die über Text sehr einfach funktionieren, aber in der UI gar nicht oder nur mit hohem Aufwand. Z.B. gibt es Lambdas (Codeblöcke), die man in der Textform als eine Art Funktion einsetzen kann, die müssen dann aber global definiert werden, damit sie in der Datei zur Verfügung stehen. in der UI gibt es keinen globalen Kontext. Man kann lediglich innerhalb einer Rule shared oder private Variablen definieren, welche dann ähnlich funktionieren wie globale Definitionen, nur dass man sie (einmalig pro Systemstart) innerhalb der Rules anlegen muss, die sie verwenden - erhöht die Komplexität, wenn man eine Funktion definiert, um sie in mehreren Rules zu verwenden...
schwabenhab hat geschrieben: ↑8. Nov 2023 07:47
Meine Einstellungen in der Regel über die PaperUI: WHEN - ITEM "was updated" - to state ">22"
Nein, das funktioniert so nicht.
Erst mal gibt es zwei Triger, die sich auf den Itemstatus beziehen (das Item liefert die Temperatur), nämlich received update und changed.
Es gibt nur sehr selten die Notwendigkeit, auf received update zu reagieren, allgemein willst Du reagieren, wenn sich ein Eingangswert
geändert hat, nicht, wenn er gleich geblieben ist.
Du kannst eingrenzen, ob der alte Wert eine Rolle spielt und/oder ob der neue Wert eine Rolle spielt (bei update nur ob der neue Wert eine Rolle spielt).
Du kannst hier aber keinen Wertebereich angeben (> 22), sondern nur exakt einen Wert (22). Das ist also bei Deiner Rule keine Option.
Stattdessen muss die Rule immer triggern, wenn sich die Eingangsgröße geändert hat.
Es gibt in der UI noch einen weiteren Bereich "But only if", über den Du dann eine Einschränkung definieren kannst, z.B. "Temperatur > 22".
Gewöhnlich wird man das innerhalb des Rule Codes erledigen, denn Du brauchst im Zweifel noch eine weitere Rule, welche die Eingangsgröße nutzt, um die Solltemperaur zu erhöhen, falls die Raumtemperatur unter einen bestimmten Wert absinkt, die zweite Rule hätte also ebenfalls den Trigger Temperatur changed, aber im "But only if" Teil z.B. Temperatur < 21. Nun hast Du also zwei Rules, die per Definition immer exakt gleichzeitig ausgeführt werden, weil die den identischen Trigger nutzen, jedoch über die "But ony if" Bedingung wieder beendet werden, falls diese nicht erfüllt ist. Das ist reichlich umständlich, zumal, wenn man das Ganze leicht mit wenigen Zeilen Code erledigen kann:
Code: Alles auswählen
rule "Thermostat Solltemperatur setzen"
when
Item Temperatur changed
then
if(newState > 22)
Thermostat.sendCommand(20)
else if(newState < 21)
Thermostat.sendCommand(22)
end
Der Code ist aus verschiedenen Gründen nicht gut, aber als Beispiel ok
Der Code kann weitgehend identisch auch über die UI verwendet werden, wobei die UI Rules eine UID bracuhen, welche keine Leerzeichen oder Sonderzeichen enthalten darf, das Label der Rule setzt Du aber auf den Teil, der nach dem Schlüsselwort rule in Anführungszeichen steht.
Zwischen when und then stehen alle Trigger, Du suchst also als nächstes bei den Triggern Item-Trigger aus, wählst dort changed aus und trägst als Item das angegebene Item Temperatur ein.
zwischen then und end steht der auszuführende Code, Du gehst also auf Action und wählst dort NICHT Item aus, sondern Script. Unter Script wählst Du dann DSL als Sprache aus. Anschließend kannst Du exakt den Code ZWISCHEN den beiden Schlüsselworten then und end als Text einfügen und Deine UI Rule ist fertig, sie schaltet dann bei Überschreiten der 22 auf Sollwert 20, bei Unterschreiten auf Sollwert 22.
Vermutlich ist die Temperatur aber keine gute Eingangsgröße für die Aufgabe
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
Was eine super Erklärung, allerdings muss ich das erstmal verdauen 
