TriggerModule which triggers if an items state matches a condition for at least a given time

[BenediktNiehues]

There should be a trigger for the rule engine which triggers a rule if an item state matches a condition like myNumberItem < 100. Additionaly there should be the possibility to tell the trigger not to fire the rule directly, but only if the value matches the condition for a given timebox. For example if the condition is myNumberItem < 100 and the timebox is 5 minutes the trigger will only fire the rule if the value of myNumberItem is < 100 for 5 minutes. If the value of myNumberItem is > 100 in between the timebox is resetted. Furthermore there should be the possibility to easily invert the condition of the trigger and it should be set as output if it was inverted or not to be handled by conditions and actions. Also a combination of the inverted and not inverted trigger should be available which fires the rule in each case. Benefit of such a trigger are

• Or combined ItemState conditions
• Observable ItemStates over a timebox with less rule executions
• easy invertable trigger logic

this gist shows an proposal of metadata for this trigger

[sjsf]

To me that sounds reasonable. @danchom, do you have any thoughts on this?

[danchom]

I think here is mixing concept of triggers and conditions. The triggers must be triggering when something occurs, The conditions have to decide if the rule's actions have to be executed or not. This what you want to achieve is some kind of CEP (Complex Event Processing). Soon or late we have to work with such complex conditions, but we have to decide how to do that. IMHO there are two ways: 1) the first is close to yours, we have to create a special trigger which will be trigger only when its complex logic is satisfied. This approach has two main disadvantages:

• it has to relay on some different events.
• it will not reuse available trigger
• it must have own language which has to define different use cases. Unfortunately you proposal is just a corner case and I'm not sure that it should be part of the core modules. IMHO we should not create a different module type for each use case. Of course this module type can be part of your project and it will be used by ESH. Other option is to have a separate package in ESH, where some useful module type, which are not enough general can be put in.
  2) The second option is to implement CEP in conditions. In this way we can reuse available triggers and do a complex logic over them. IMHO the script condition can be used for that. I'm not in deep in your javascript implementation, but it should have ability to do a logic define in the issue. Also a library of such functions can be predefined and reused by the users. We can more simplify the process when create a composite type over the script condition implementing CEP logic. @kaikreuzer what do you think?

[kaikreuzer]

Sorry for my late feedback, I was on holiday last week...

I agree with @danchom that this proposal seems to mix many different things together and that it probably is not a good candidate for adding it to the core modules (and yes, we have to think about a library of optional modules that we want to provide with ESH, but which are not there mandatorily).

From the mentioned options 1+2 and think 1 is probably the better approach; to me, the conditions should be ideally independent from the triggers of the rule - they are mainly a way to let users easily suppress certain rules in certain situations (at night, when not at home, if it is raining, etc.). It is imho ok to have more complex trigger implementations that filter out events by themselves already and only trigger when something special that they rely on for their use case is satisfied. We e.g. already have the possibility in the ItemStateChangeTrigger to compare the old and new state with some configured value.

Nonetheless, I think we should disect the requirements here. It seems to me that there are different parts to it:

• not only allow equal comparison as in the ItemStateChangeTrigger, but also have <, >, <=, >= as comparators similar to the existing state conditions
• introduce a "between" comparator. This is imho tricky for UIs as it will require an additional input field for the range
• if a condition is met, keep a state internally and only trigger again, if that state changes (currently, the ItemStateChangeTrigger with item>5 would trigger every time one the state is bigger than 5 - here, it would expect it to trigger only once)
• In contrast to ItemStateChangeTrigger, the output does not need to be a state, but rather a "condition met" or "condition not met anymore" boolean value. (that should cover the "inverted" feature, right?)
• defer the trigger event for the time x and only send it, if the internal evaluation state does not change meanwhile. It seems that you would even want to provide 2 times (one for true and one for false) as the false case seems to be "0" for your use cases, while in other cases you might want to have a time >0 before you claim that a condition is not met anymore.

So I agree with @danchom that we should look how this can be addressed in a generic way that would cover other use cases as well, before adding it in ESH.

Talking about CEP, maybe we could introduce a "ExpressionTrigger" module, which would hold a script expression that is to be evaluated (in any JSR223-compliant scripting language like Javascript) and configurable delays for the triggering. It would need a list of item names as inputs, so that it knows, which state updates to listen for. It would have a boolean as output.

Would such a module meet your expectations?

[BenediktNiehues]

@kaikreuzer , @danchom IMHO this trigger should be part of the core modules; it has no complex expression logic, just additional comparators as @kaikreuzer already mentioned. - The between comparator for me is not mandatory, so I could remove it if it is in your opinion too tricky for UIs... - The most important requirement for this trigger is that the condition should match for a defined timespan before the trigger fires the rule, as @kaikreuzer also mentioned. The inversion and the corresponding output is for the ability to easily create rules with an "opposite" trigger logic. E.g. switch on a light if the condition of the trigger matches and switch it off again if it does not match anymore... Please be aware that there is a composite trigger "core.AutoInvertConditionalTimeboxedItemStateChangeTrigger" coming with the PR based on the same implementation with additional configuration for the timebox for the "inverted" case. @kaikreuzer I think this would answer your question:

It seems that you would even want to provide 2 times (one for true and one for false)

I did it this way to not have unnecessary configuration parameters for the case where you don't need the inversion logic.

And as the timebox and the invert configuration are optional, this could also be a basic implementation for the ItemStateChangeTrigger without the state transition option...

Except the CEP, what other useCases do you think of?

[danchom]

Except the CEP, what other useCases do you think of?

There are a lot of useCases i.e. you may want to trigger the trigger base on combination of events from different items or other triggers (For example: you have to generate event when the alarm is ON and for a given delay the outdoor is not locked ). I think we should not add a new handler in the core for each separate case. If this usecase is important for your project, you can always create this ModuleType and handler in your bundle and provide them to the rule engine (using available providers).

@kaikreuzer I'm agree that first option will be clear decision and easy for users, but in that case we can't reuse available triggers (and reuse their logic) as event stream in CEP. May be the triggers should have inputs as actions. In that way the CEP trigger can receive events from available triggers.

[BenediktNiehues]

@danchom didn't get that

you have to generate event when the alarm is ON and for a given delay the outdoor is not locked

... would match perfectly here: trigger would be on outdoor=OPEN with a delay and a condition alarm=ON

[danchom]

trigger would be on outdoor=OPEN with a delay and a condition alarm=ON

What happened if the outdoor is closed before the delay?

Actually this was not my usecase you have divided the items into trigger and condition, which is right, but I mean in your handler has defined only one configuration property for itemName and you can listen for serials of events only from it. You can't combine events from two, three and more items.

[BenediktNiehues]

@danchom ah, now I got it, you would like to observe multiple item states at once... Yes, that is not possible with this trigger, but that would be a usecase for a CEP trigger, otherwise its configuration would get too complex. But if you don't want the trigger in core modules, I have no problem pulling that back to our codebase... Just thougth it could be useful for the community.

[danchom]

I don't want to stop your PR, but I think this is a corner case of CEP and if all different cases are added into core modules we will end with a long list of module types and it will be hard for users to oriented in them. If @kaikreuzer @maggu2810 or @sjka thinks that it is useful for ESH I don't mind to be added to core modules.