How do I translate the following to the new rules engine:
rule "example trigger rule"
when
Channel ‘astro:sun:home:rise#event’ triggered START or
Channel ‘astro:sun:home:dawn#event’ triggered START
then
…
end
Let’s assume I create a rule with the two triggers, then I’d need two conditions with each of them connected to one of the triggers verifying that START and not END was triggered.
unfortunately this does not work since it will always be, that one of the conditions did not receive and input and then it’ll be false. (see GenericEventConditionHandler line 67)
Is this behaviour intended or is it a bug?
If it is not a bug, then how can I create a rule as the one above.
Your old Rules engine rule is invalid to start with.
It should be:
when
Channel 'astro:sun:home:rise#event' triggered START or
Channel 'astro:sun:home:dawn#event' triggered START
then
The old rules engine is event based, not state based. So triggers can only ever be OR. No two events will take place at the same time so it makes no sense to have an and in rules triggers and therefore and is not supported. But you must supply the or for the rule to be syntactically correct.
I have no experience with the new rules engine but suspect the same holds true (the event based part at least). I could be wrong though and the new rules engine may include state in the triggers now.
Yeah, Thanks for correcting that. Of course I meant it to be or not and. (I changed the initial post accordingly)
The point with the new rules is, that the trigger will fire with START and END so I need to add a condition to limit it to START only. But I have to do that for both triggers.
However, if I do that, one of the conditions will always return false. So the rule will never ever be executed.
As far as I can see, there is no way such a “when statement” can be described using the new rules.
Looking at the code, it does appear that the new rule engine only supports an AND combination of conditions (condition modules). I could be wrong though. I’ve only experimented with the new rule engine using Jython and don’t need to use condition modules since I write the conditional logic in code instead.
If your primary (or only) question is whether a condition OR combination is supported by the new rule engine it might be better to start a new topic with that specific question. I had to read your current question several times to determine what you were asking.
I want to use this in jython as well. However it feels wrong to test on “START” in the action part of the rule.
Assuming I change
"Channel ‘astro:sun:home:rise#event’ triggered START"
to
"Channel ‘astro:sun:home:rise#event’ triggered END"
Then I should not have to change my action.
The “triggered START” part really is more part of the trigger than actually a condition. Yes, one can argue about that, but why would an event-channel be a trigger by itself. It has to trigger something. Similarly, cron is not a trigger by itself either You don’t have to check the time as a condition or in the action, that would be utter nonsense too
So maybe my question would rather be:
why can’t I fully specify my channel trigger in the trigger part of the rule?
Or maybe it is just me doing it all wrong trying to setup an eventChannel trigger with “core.GenericEventTrigger”?
I agree with everything you said. Maybe @Kai can comment, but it seems like the channel trigger module (if that’s the correct terminology) might need some improvement. It looks to me like there is specific support in the old rule engine for matching the channel trigger payload. I haven’t seen that support so far in the new rule engine (but I very well could have missed it).
When I was doing experimentation with the JSR223 PR prior to the merge, I developed several trigger-related Jython classes to wrap and simplify usage of the low-level “module” API and to create completely new trigger types. I haven’t tried it yet, but it should be possible to use Jython to create the type of channel trigger you want (although hopefully this will be improved in the ESH core at some point). Here’s a pointer to the Jython code. I think the Jython implementation works with the current merged code, but it’s possible it needs some small tweaks.
Yes, this is absolutely correct! It is a restriction on the trigger, i.e. you really only want the trigger to happen if the payload has a specific value.
Or maybe it is just me doing it all wrong trying to setup an eventChannel trigger with “core.GenericEventTrigger”?
Well, partly. The core.GenericEventTrigger is not meant to be used by end users, but rather to be reused by more specific trigger definitions, such as the core.ChannelEventTrigger.
I think all that is missing for your use case is a second configuration parameter on core.ChannelEventTrigger, with which you can add the START as a payload filter. I’d suggest you enter a feature request issue at ESH for it.
Thanks for sharing this code. I had read this a while ago. It helped me a lot when getting started with jython and openhab2.
Unfortunately, it does not help here. There really is missing proper support for EventChannels in core.GenericEventTrigger.
@schnidrig I’m guessing the payload is in the raw OSGI event. There is an OSGI event trigger implementation in the my repository (see scripts/components/OsgiEventTrigger.py and lib/openhab/osgi/events.py). However, I’m sure it needs some work to be compatible with the latest version of the openHAB JSR223 code.
@schnidrig, Dear Christian, would you like to share with us how your final jython code looks for the trigger Channel 'astro:sun:home:rise#event' triggered START ?
I had a look at your lovely rollershutter code and the ChannelEventTrigger class:
class ChannelEventTrigger(Trigger):
def __init__(self, channelUID, event, triggerName=None):
I guess that “event” is an event filter, but I’m not sure what to assign to it. Thanks!
