openhab-core
openhab-core copied to clipboard
Add event information in rules for time triggers
Closes #1391
This creates event information for time-based triggers (DateTimeTrigger, GenericCronTrigger, TimeOfDayTrigger). The topic contains the trigger type, the trigger id (or label) is passed as source and the trigger configuration as payload of the event.
Signed-off-by: Jan N. Klug [email protected]
+1. This enhancement would allow the jrubyscripting helper gem (https://github.com/boc-tothefuture/openhab-jruby/) to remove its own CronTrigger type that's used simply to correlate which trigger triggered the rule.
cc @boc-tothefuture
By adding these one wonders if we shouldn't be complete and have event information for all the ways the rule can be triggered. Off the top of my head, after these we would still be missing manual triggers and called from another rule.
One use case for this, which admittedly is a use case which may not matter any more when/if the global variable registry ever gets merged, is that I have at the top of any of my rules that use the JS Scripting cache
a test to see if this.event
is undefined
. If it is, it clears out the cache
the entries the rule uses. Otherwise it runs the rule as normal. But I can't do that in cases where the rule is called from another rule because this.event
is undefined
in both cases.
What would be the "payload" of these events?
Even if it's just a boolean flag that would be sufficient. Or maybe a new field could be added to event
that is always there and has an enum indicating how the rule was triggered. I like that idea because it means we don't need to figure it out based on what's undefined
and instead we could just check.
if(this.event.triggeredBy = 'Time')
if(this.event.triggeredBy = 'Manual')
if(this.event.triggeredBy = 'CalledBy') // could carry an additional parameter with the UID of the rule that called it
if(this.event.triggeredBy = 'ItemUpdate')
if(this.event.triggeredBy = 'ItemCommand')
and so on.
at the lowest level, anything would be sufficient, so that the trigger's module id is in the context map in some way that's sent to the action's execute method. ideal would be an "event" object, descended from AbstractEvent. I don't even care if it doesn't have extra fields (a calling rule UID would definitely be nice for the call-rule action).
Even if it's just a boolean flag that would be sufficient. Or maybe a new field could be added to
event
that is always there and has an enum indicating how the rule was triggered. I like that idea because it means we don't need to figure it out based on what'sundefined
and instead we could just check.if(this.event.triggeredBy = 'Time') if(this.event.triggeredBy = 'Manual') if(this.event.triggeredBy = 'CalledBy') // could carry an additional parameter with the UID of the rule that called it if(this.event.triggeredBy = 'ItemUpdate') if(this.event.triggeredBy = 'ItemCommand')
and so on.
Assuming we get a distinct descendant of AbstractEvent
for each possibility, you could just check the event's class type instead of having an explicit enum.
getType
should be available on all existing events. So what we need is an event for triggering manually/by other rule.
In JS a rule with
console.log("received: '" + event + "' with payload '" + event.getPayload() + "'")
result in the following logs
-
received: 'Execution triggered by manual' of type 'ExecutionEvent' with payload '{}'
when triggered from UI -
received: 'Execution triggered by runRuleAction' of type 'ExecutionEvent' with payload '{"previous":{"topic":"openhab/execution/2d4f245946/triggered","payload":"{}","source":"manual"}}'
when triggered from another rule that was triggered manually -
received: 'Timer 1 triggered.' of type 'TimerEvent' with payload '{"cronExpression":"0 0/5 * * * ? *"}'
when triggered from a cron trigger
This feels really useful, can we get it merged?
This pull request has been mentioned on openHAB Community. There might be relevant details there:
https://community.openhab.org/t/using-event-in-a-js-ui-defined-rule-that-is-triggered-periodically-and-by-an-item/146418/1
This pull request has been mentioned on openHAB Community. There might be relevant details there:
https://community.openhab.org/t/datetime-or-time-only-triggers-the-eternal-alarm-clock-question/146704/7
Ping @openhab/maintainers, this PR is awaited with great anticipation by me and others. It would be a great new feature to brag about for OH 4 if we can get it merged.
This pull request has been mentioned on openHAB Community. There might be relevant details there:
https://community.openhab.org/t/openhab-4-0-release-discussion/147957/111