Ich komme gerade nicht weiter. Ich versuche eine Regel ausführen zu lassen, wenn ein Item einen gewissen Wert hat. Nur kann ich dies nicht wählen. Zur Auswahl stehen nur:
* an item state is updated
* an item state changes
* an item receives a command
Ein Kommando erhält das Item nicht, fällt also weg.
"state updated" würde die Regel ja nur ausführen, wenn sich der Status des Items neu gesetzt wird.
"state changes" würde die Regel ja nur ausführen, wenn sich der Status des Items ändert.
Oder verstehe ich da etwas falsch?
Es geht um ein Fensterkontakt. Die Regel soll ausgeführt werden, solange der Status des Fensterkontakts offen ist.
Im Moment ist es so, dass die Regel nur ausgeführt wird, wenn der Status sich ändert.
Vielleicht kann mir jemand den Knoten im Hirn nehmen.
Danke
Item Status als Triger für Regel
-
- Beiträge: 123
- Registriert: 5. Jan 2020 14:26
Item Status als Triger für Regel
Nein, das ist genau so richtig. Der äußere Rahmen ist die Definition des Timers, der nach zehn Minuten abläuft. Dabei wird beim Ablauf des Timers geprüft, ob das Fenster geöffnet ist. Ist das der Fall, so wird die Meldung ausgegeben und der Timer wird erneut eingeplant. Wie erwähnt wird die Rule nur einmalig ausgeführt, die Ausführung dauert nur wenige Millisekunden, eben die Zeit, die es braucht, im Scheduler einen Eintrag zu erzeugen, mit dem Zeitpunkt der Ausführung und einem Verweis auf den Code, der ausgeführt werden soll.
Der Scheduler startet dann zum angegebenen Zeitpunkt die Ausführung des Codes, komplett unabhängig von der ursprünglichen Rule. Wenn der Timer erneut geplant wird, wird lediglich der Zeitstempel ausgetauscht, was noch schneller geht als das initiale Anlegen des Timers - schließlich muss der Code nicht mehr in den Speicher geschrieben werden.
Gehe zur vollständigen AntwortDer Scheduler startet dann zum angegebenen Zeitpunkt die Ausführung des Codes, komplett unabhängig von der ursprünglichen Rule. Wenn der Timer erneut geplant wird, wird lediglich der Zeitstempel ausgetauscht, was noch schneller geht als das initiale Anlegen des Timers - schließlich muss der Code nicht mehr in den Speicher geschrieben werden.
-
- Beiträge: 123
- Registriert: 5. Jan 2020 14:26
Re: Item Status als Triger für Regel
Ich hab es jetzt so gelöst, das ein postupdate in der Regel ausgeführt wird, wodurch die Regel sich selber wieder triggert. Das kann doch aber nicht der Weg sein.
Code: Alles auswählen
configuration: {}
triggers:
- id: "3"
configuration:
itemName: FensterkontaktBadezimmer_Wert1
state: OPEN
type: core.ItemStateUpdateTrigger
conditions: []
actions:
- inputs: {}
id: "2"
configuration:
blockSource: <xml xmlns="https://developers.google.com/blockly/xml"><block
type="oh_timer_ext" id=",x8A;k!)T~/Is+qWb7J~" x="244" y="400"><field
name="delayUnits">plusSeconds</field><field
name="retrigger">reschedule</field><value name="delay"><shadow
type="math_number" id=")vtc!iuSalQ%JczXY$#Q"><field
name="NUM">10</field></shadow></value><value name="timerName"><shadow
type="text" id=",$:E%#p~v;-+};OA)QGP"><field
name="TEXT">BadFensterTimer</field></shadow></value><statement
name="timerCode"><block type="controls_if"
id="X60.cNvZ:;giSGRpY3tr"><value name="IF0"><block type="logic_compare"
id=";LHn4M4:p,B]N:G~3m!Y"><field name="OP">EQ</field><value
name="A"><block type="oh_getitem_state" id="iGFmRs_|HGM?A3YIt5sI"><value
name="itemName"><shadow type="oh_item" id="Fy~[.7Si`0`qC%8Qn~VV"><field
name="itemName">FensterkontaktBadezimmer_Wert1</field></shadow></value></block></value><value
name="B"><block type="text" id="2qFR$Ro:W3J4Xcg,S2E^"><field
name="TEXT">OPEN</field></block></value></block></value><statement
name="DO0"><block type="oh_event" id="(vRUN(}p?UyO|y#(G0Ql"><field
name="eventType">postUpdate</field><value name="value"><shadow
type="text" id=";{$l*%Fnsl1e]{`OnOe|"><field
name="TEXT">OPEN</field></shadow></value><value name="itemName"><shadow
type="oh_item" id="%miAlV|$nsw/*:`y;i(K"><field
name="itemName">FensterkontaktBadezimmer_Wert1</field></shadow></value><next><block
type="oh_event" id="Te1Z?]bjcdiw7%ieq]Q%"><field
name="eventType">sendCommand</field><value name="value"><shadow
type="text" id="M!N$5pxDSpI9huqaH^hp"><field name="TEXT">Bad Fenster
schliesen</field></shadow></value><value name="itemName"><shadow
type="oh_item" id="7-7+bN|hk(O)bW/OAYz:"><field
name="itemName">EchoBad_Sprich</field></shadow></value></block></next></block></statement></block></statement></block></xml>
type: application/javascript
script: >
var scriptExecution =
Java.type('org.openhab.core.model.script.actions.ScriptExecution');
var zdt = Java.type('java.time.ZonedDateTime');
if (typeof this.timers === 'undefined') {
this.timers = [];
}
if (typeof this.timers['BadFensterTimer'] === 'undefined' || this.timers['BadFensterTimer'].hasTerminated()) {
this.timers['BadFensterTimer'] = scriptExecution.createTimer(zdt.now().plusSeconds(10), function () {
if (itemRegistry.getItem('FensterkontaktBadezimmer_Wert1').getState() == 'OPEN') {
events.postUpdate('FensterkontaktBadezimmer_Wert1', 'OPEN');
events.sendCommand('EchoBad_Sprich', 'Bad Fenster schliesen');
}
})
} else {
this.timers['BadFensterTimer'].reschedule(zdt.now().plusSeconds(10));
}
type: script.ScriptAction
- scotty
- Beiträge: 676
- Registriert: 28. Apr 2020 04:44
Re: Item Status als Triger für Regel
Eine Lösung, welche ich häufig verwende: zunächst ein Dummy-Item (Switch) anlegen,
Code: Alles auswählen
Rule "anything"
when
Item Dummy changed from OFF to ON
then
....
....
Dummy.postUpdate("OFF")
end
OH 3.4.5 im Docker auf Synology DS918+ mit USV, Reolink-RLC-511WA, Philips Hue, AVM Fritz!Box 6591C, Alexa, Logitech Harmony und diversen Shelly's
- udo1toni
- Beiträge: 15265
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Item Status als Triger für Regel
Nein, das kann nicht der Weg sein. Und es ist auch nicht der Weg 
openHAB ist ein System, welches "Event driven" ist, es geht nur um Ereignisse. Eine Regel wird immer dann ausgelöst, wenn ein bestimmtes Ereignis auftritt. Eine Regel ist kein Programm, welches in einer Dauerschleife läuft, es stellt bei Auftreten des Triggers einen gewünschten Zustand her.
Bei Dir geht es ja um eine wiederkehrende Meldung, die ausgegeben werden soll. Das geschieht schon über den von Dir verwendeten Timer. Der Timer plant sich selbst wieder ein und wird dann wieder ausgeführt.
Die Regel lautet also nur, dass dieser Timer angelegt werden soll. Danach ist die Regel beendet und wird nicht mehr ausgeführt. Stattdessen übernimmt der Code, der vom Timer gestartet wird nun den Job, sich selbst immer wieder aufzurufen, bis das Fenster geschlossen wurde. Das hat aber nichts mit der ursprünglichen Rule zu tun, die ist beendet und wird erst wieder ausgeführt, wenn das Fenster erneut geöffnet wird. Der Trigger muss also auf "changed to OPEN" lauten.

openHAB ist ein System, welches "Event driven" ist, es geht nur um Ereignisse. Eine Regel wird immer dann ausgelöst, wenn ein bestimmtes Ereignis auftritt. Eine Regel ist kein Programm, welches in einer Dauerschleife läuft, es stellt bei Auftreten des Triggers einen gewünschten Zustand her.
Bei Dir geht es ja um eine wiederkehrende Meldung, die ausgegeben werden soll. Das geschieht schon über den von Dir verwendeten Timer. Der Timer plant sich selbst wieder ein und wird dann wieder ausgeführt.
Die Regel lautet also nur, dass dieser Timer angelegt werden soll. Danach ist die Regel beendet und wird nicht mehr ausgeführt. Stattdessen übernimmt der Code, der vom Timer gestartet wird nun den Job, sich selbst immer wieder aufzurufen, bis das Fenster geschlossen wurde. Das hat aber nichts mit der ursprünglichen Rule zu tun, die ist beendet und wird erst wieder ausgeführt, wenn das Fenster erneut geöffnet wird. Der Trigger muss also auf "changed to OPEN" lauten.
openHAB4.3.5 stable in einem Debian-Container (bookworm) (Proxmox 8.4.1, LXC), mit openHABian eingerichtet
-
- Beiträge: 123
- Registriert: 5. Jan 2020 14:26
Re: Item Status als Triger für Regel
Danke. Ich hatte jetzt erst wieder Zeit gefunden.
Ich denke ich habe die richtige Zeile gefunden in Blockly. Obwohl ich diese Zeile etwas widersprüchlich finde.
-> after 10 minutes reschedule "BadFensterTimer"
Zu dieser Zeile komme ich ja erst, wenn der Timer einmal abgelaufen ist und das Fenster noch offen ist. Und dann wird gesagt nach 10 Minuten den Timer neu starten(planen). Aber Timer wird doch sofort wieder neu gestartet(geplant). Nach meiner Logik würde der zweite aufruf erst wieder nach 20 Minuten kommen. Aber vielleicht denke ich da zu verquirlt.
Auf jeden Fall funktioniert es so, und der Aufruf wird aller 10 Minuten wiederholt, solange das Fenster auf ist. (Getestet mit 10 Sekunden) (Getestet mit -> item changed to "Open")
Oder sollte man es doch noch anders machen?
Ich denke ich habe die richtige Zeile gefunden in Blockly. Obwohl ich diese Zeile etwas widersprüchlich finde.
-> after 10 minutes reschedule "BadFensterTimer"
Zu dieser Zeile komme ich ja erst, wenn der Timer einmal abgelaufen ist und das Fenster noch offen ist. Und dann wird gesagt nach 10 Minuten den Timer neu starten(planen). Aber Timer wird doch sofort wieder neu gestartet(geplant). Nach meiner Logik würde der zweite aufruf erst wieder nach 20 Minuten kommen. Aber vielleicht denke ich da zu verquirlt.
Auf jeden Fall funktioniert es so, und der Aufruf wird aller 10 Minuten wiederholt, solange das Fenster auf ist. (Getestet mit 10 Sekunden) (Getestet mit -> item changed to "Open")
Code: Alles auswählen
configuration: {}
triggers:
- id: "3"
configuration:
itemName: FensterkontaktBadezimmer_Wert1
state: OPEN
type: core.ItemStateChangeTrigger
conditions: []
actions:
- inputs: {}
id: "2"
configuration:
blockSource: <xml xmlns="https://developers.google.com/blockly/xml"><block
type="oh_timer_ext" id=",x8A;k!)T~/Is+qWb7J~" x="263" y="396"><field
name="delayUnits">plusMinutes</field><field
name="retrigger">reschedule</field><value name="delay"><shadow
type="math_number" id=")vtc!iuSalQ%JczXY$#Q"><field
name="NUM">10</field></shadow></value><value name="timerName"><shadow
type="text" id=",$:E%#p~v;-+};OA)QGP"><field
name="TEXT">BadFensterTimer</field></shadow></value><statement
name="timerCode"><block type="controls_if"
id="X60.cNvZ:;giSGRpY3tr"><value name="IF0"><block type="logic_compare"
id=";LHn4M4:p,B]N:G~3m!Y"><field name="OP">EQ</field><value
name="A"><block type="oh_getitem_state" id="iGFmRs_|HGM?A3YIt5sI"><value
name="itemName"><shadow type="oh_item" id="Fy~[.7Si`0`qC%8Qn~VV"><field
name="itemName">FensterkontaktBadezimmer_Wert1</field></shadow></value></block></value><value
name="B"><block type="text" id="2qFR$Ro:W3J4Xcg,S2E^"><field
name="TEXT">OPEN</field></block></value></block></value><statement
name="DO0"><block type="oh_event" id="Te1Z?]bjcdiw7%ieq]Q%"><field
name="eventType">sendCommand</field><value name="value"><shadow
type="text" id="M!N$5pxDSpI9huqaH^hp"><field name="TEXT">Bad Fenster
schliesen</field></shadow></value><value name="itemName"><shadow
type="oh_item" id="7-7+bN|hk(O)bW/OAYz:"><field
name="itemName">EchoBad_Sprich</field></shadow></value><next><block
type="oh_timer_reschedule" id="vE_+xJq23_gx5w=L3#}Q"><field
name="delayUnits">plusMinutes</field><value name="delay"><shadow
type="math_number" id="~-4o8s4Y=M+zmK(ce^X@"><field
name="NUM">10</field></shadow></value><value name="timerName"><shadow
type="text" id="%Tlrst.6=3QW40hL],R2"><field
name="TEXT">BadFensterTimer</field></shadow></value></block></next></block></statement></block></statement></block></xml>
type: application/javascript
script: >
var scriptExecution =
Java.type('org.openhab.core.model.script.actions.ScriptExecution');
var zdt = Java.type('java.time.ZonedDateTime');
if (typeof this.timers === 'undefined') {
this.timers = [];
}
if (typeof this.timers['BadFensterTimer'] === 'undefined' || this.timers['BadFensterTimer'].hasTerminated()) {
this.timers['BadFensterTimer'] = scriptExecution.createTimer(zdt.now().plusMinutes(10), function () {
if (itemRegistry.getItem('FensterkontaktBadezimmer_Wert1').getState() == 'OPEN') {
events.sendCommand('EchoBad_Sprich', 'Bad Fenster schliesen');
if (typeof this.timers['BadFensterTimer'] !== 'undefined') { this.timers['BadFensterTimer'].reschedule(zdt.now().plusMinutes(10)); }
}
})
} else {
this.timers['BadFensterTimer'].reschedule(zdt.now().plusMinutes(10));
}
type: script.ScriptAction
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
- udo1toni
- Beiträge: 15265
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Item Status als Triger für Regel
Nein, das ist genau so richtig. Der äußere Rahmen ist die Definition des Timers, der nach zehn Minuten abläuft. Dabei wird beim Ablauf des Timers geprüft, ob das Fenster geöffnet ist. Ist das der Fall, so wird die Meldung ausgegeben und der Timer wird erneut eingeplant. Wie erwähnt wird die Rule nur einmalig ausgeführt, die Ausführung dauert nur wenige Millisekunden, eben die Zeit, die es braucht, im Scheduler einen Eintrag zu erzeugen, mit dem Zeitpunkt der Ausführung und einem Verweis auf den Code, der ausgeführt werden soll.
Der Scheduler startet dann zum angegebenen Zeitpunkt die Ausführung des Codes, komplett unabhängig von der ursprünglichen Rule. Wenn der Timer erneut geplant wird, wird lediglich der Zeitstempel ausgetauscht, was noch schneller geht als das initiale Anlegen des Timers - schließlich muss der Code nicht mehr in den Speicher geschrieben werden.
Der Scheduler startet dann zum angegebenen Zeitpunkt die Ausführung des Codes, komplett unabhängig von der ursprünglichen Rule. Wenn der Timer erneut geplant wird, wird lediglich der Zeitstempel ausgetauscht, was noch schneller geht als das initiale Anlegen des Timers - schließlich muss der Code nicht mehr in den Speicher geschrieben werden.
openHAB4.3.5 stable in einem Debian-Container (bookworm) (Proxmox 8.4.1, LXC), mit openHABian eingerichtet