Multiple events from one change to group

Setup, Configuration and Use Scripts & Rules
, ,
1

Hello there,
talked my father into using openhab and now I’m struggeling to get all parts together :smiley: :blush:

One things really confuses me. Groups and their created events for rule scripting.

gLight_WHZ is a group of 18 Ikea Tradfri bulbs, which is working fine using a slider.
(using the MAX function for the group)

The Rules uses the changed event.

But why on earth creates one change like 30+ events???
If I used the received update I might understand it, but not for changed?

I found this wich should work, but does not (throwing exceptions like crazy).

But really my question is: Shouldn’t this be only 1 event at all (slider change to the group directly)?

boolean gotLock = lock.tryLock();
try{
    if(gotLock){
        // Do Stuff
    } else {
        // Don't do stuff
    }
}
finally{
    if(gotLock){
        lock.unlock();
    }
}

from recommended Lock

2

What do you mean by “one change”?
Obviously the item is changed multiple times when you use the slider (like sliding not tapping to another value)
Maybe have a look into the events log (/var/log/openhab2/events.log on ubuntu) and look (and show us) what exactly those events are?

3

@ChrisW this is a somewhat confusing effect at first, but each member of the group will update your group. So if you switch off all lamps you get 30 updates to your group status. I use the reentrant lock to prevent multiple triggers. If your rule moves too fast and is already done while your group is still updating, try adding a Thread::sleep(100) or so to wait, in this case 100millisecond, but be careful sleep should only be used for a short time.
For reentrant locks, use the right import and define a variable:

import java.util.concurrent.locks.ReentrantLock

var ReentrantLock lock = new ReentrantLock()

rule "Some Rule"
when
     your_rule_trigger
then
var gotLock = lock.tryLock()		
	try {
		if (gotLock) {
           //do stuff
		}		   
	}
	finally {
		if(gotLock){
			lock.unlock()
		}
	} 
end
4

Just to step back a little bit it is important to realize how the state of a Group gets calculated. Every time one of the members of a Group changes it iterates through all of its members and recalculates its own state incrementally. Consequently, a Group will receive N-1 updates (where N is the number of members of the Group) for each single change to one of its members. Now as the Group incrementally updates its state, it is possible, depending on the aggregation function, that the Group’s state changes on each update.

Throw in the fact that you are using a slider and I’m not surprised you are seeing lots and lots of rule triggers.

5

Maybe not the best example, but it was really a single change which resulted in multiple events.

You could see it in the log files, as there were several lines changing to the same value.

Only got it half working by adding a timer which waited 2 secs and then took the current value to execute the code if the value changes at all.

But this made a simple rule really complex.
I don’t think it is meant that way.

I can post logs and code when I’m visiting my parents again.

6

It’s like in Group rule triggered twice - why?

7

Hm well I might expect what you told for received update.

But for changed I would expect one update only.

If a group changes the bulbs which change again the group - we would have a loop?

8

I’m now using NodeRED as rule engine.
Got from Node-RED as a rule/script engine for openHAB
There is even a menu entry to install it in openhabian.

From my experience it is a lot less troublesome then the native rule engine.

currently running 6 rules