Derive Group State from Member Items is delayed a lot => workaround

Setup, Configuration and Use Items & Sitemaps
, ,
1

Hi there,
I always had a problem that my group items states derived from member items had been delayed a lot. This made all my rules very complicated.
As this problem was getting a lot worse since I switched to OH4 I found some workarounds.
I don’t like them because they use way more calculating power but they work and they may help others:

Instead of working in rule directly with the group item im know checking all the members of this group items:
Code Examples: JavaScript Scripting (ECMAScript 2022+)
The delayed version which sadly doesn’t work always:

if (items.getItem("groupitem").state === "OPEN") {
// do something
}

My solution:

if (items.getItem("groupitem").members.find(item => item.state === "OPEN") ) {
// do something
}

Or as a trigger vor a rule:
The delayed version which sadly doesn’t work always:

triggers.ItemStateChangeTrigger(groupItem)

My solution:

triggers.GroupStateChangeTrigger("groupItem)

The concept is always to check the childs directly even if the functionaly is not even needed.

I really hope there will be a solution in the future that deriving the Group States from Member Items is not so delayed anymore.

2

Have you ever filed an issue on this? Group aggregation functions should only take a few milliseconds. In my experience it has never been that much of a delay.

It can be the case that the state of the Group changed after the rule triggered, especially if you are relying on updates to the Group Item to trigger the rule instead of changes.

What do you see in events.log?