[SOLVED] findFirst[ ] from Group doesn't find a match

[rlkoshak (Rich Koshak)]

@dancemichi

Maybe we are lucky and @rlkoshak even knows whether a group’s state is calculated upon an update of one or more of its members before any rules are triggered, or not.

It’s all a big jumble which is rossko57’s point I think.

At each step through the comparisons of the members with the Group the Group’s state gets updated. So the Rule could be triggered before the actual min is arrived at.

[dancemichi (Michael)]

@rossko57

Of course a second change might still happen along
I’d still code for a no-match,no action failsafe if possible.

I added a 1-sec Thread::sleep() by now. Hope that circumvents said issues. Following your suggestion I do an additional NULL and UNDEF check now. Seems to work fine so far.

[rossko57]

You could go a much shorter delay. When triggering from member of, you know that a group recalculation/update is in progress or imminent. But it will only take a few milliseconds.
Waiting longer doesn’t reduce the chances of nothing else happening - it’s just tying up resource.

[dancemichi (Michael)]

@rossko57

You could go a much shorter delay. When triggering from member of, you know that a group recalculation/update is in progress or imminent. But it will only take a few milliseconds.
Waiting longer doesn’t reduce the chances of nothing else happening - it’s just tying up resource.

I know and I quite understand the urge for optimization, but frankly I don’t care about that second . The rule won’t be triggered that often, anyway.

[rlkoshak (Rich Koshak)]

@dancemichi

I know and I quite understand the urge for optimization, but frankly I don’t care about that second . The rule won’t be triggered that often, anyway.

Is not about optimization. Long running rules can be dangerous. Sleeps longer than 300 msec are risky. You can run the risk of delays in all your rules or all your rules just stopping running in extreme circumstances. See (OH 1.x and OH 2.x Rules DSL only] Why have my Rules stopped running? Why Thread::sleep is a bad idea.

[dancemichi (Michael)]

@rlkoshak

Is not about optimization. Long running rules can be dangerous. Sleeps longer than 300 msec are risky. You can run the risk of delays in all your rules or all your rules just stopping running in extreme circumstances. See Why have my Rules stopped running? Why Thread::sleep is a bad idea.

Thanks for the heads-up. Since I’m triggering my rule using ‘Member of gSpritpreise changed’ and all five members of the group might get updated (more or less) simultaneously no further rules can run for at least a full second with my Thread::sleep(1000), if I understood the following correct?

@rlkoshak

By default the Rules DSL only provides five threads for Rules to execute in. This means that the Rules Engine can only support five simultaneously running Rules at a given time.

I just changed to a createTimer solution, as suggested in your linked post. Which I use anyway in all other rules.

[rlkoshak (Rich Koshak)]

@dancemichi

correc

Correct.