In OH2, if I send a command to a group, is it always distributed to the members of that group, including nested groups, in the same order? What about for iterators through the .members and .allMembers collections?
Also, when there is an event that fires off rules, is it correct that it is its own thread (or equivalent), so that the previous event’s action may still be executing while another thread processes the second event?
This is related to one action occurring on momentary button down, and another when it is released. The two events can be as close together as 200 ms, but the action may take 800-1200 ms to complete, so they will overlap. Because of the overlap, the “stop” trigger event happens before the last of the “start” actions is sent.
In question of groups, no, the command may be distributed if it is a switch (I don’t know, though), but I’m pretty sure it is not distributed to nested groups and it won’t be distributed at all for e.g. rollershutter items, you would have to use a rule for that.
Every event which fires off a rule would create it’s own thread, you would have to use a lock() to avoid overlapping.
Good to confirm that there are threads for each trigger.
It’s not that I want them to lock each other out, but that I need them to run simultaneously, and trigger actions in the same order. If I can only send out commands every 100 ms, for example, and I have 300 ms of “activity” around the “start increasing” command, and the button-down time is 250 ms, I’d like to guarantee that the sequence of events is
000 ms -- Button-down
010 ms -- Dimmer 1 gets start increasing
110 ms -- Dimmer 2 gets start increasing
210 ms -- Dimmer 3 gets start increasing
250 ms -- Button up
260 ms -- Dimmer 1 gets stop
310 ms -- Dimmer 4 gets start increasing
360 ms -- Dimmer 2 gets stop
460 ms -- Dimmer 3 gets stop
560 ms -- Dimmer 2 gets stop
with each dimmer getting 250 ms between the start increasing and stop commands
I’m a little surprised that inner groups don’t get commands sent to outer groups. I would have thought that the outer group sends the command to all its members, and that if one of those members is an inner group, that it recursively sends the command to its members as well.
Perhaps it is that the code that prevents a group for “accepting” a command unless all its members can accept the command? I ran into this with dimmers. I haven’t checked to see if a group provides the same method that a “regular” item does.
Looks like a group does check its members and that might be the “issue” you’ve run into.
/**
* The accepted command types of a group item is the same as of the underlying base item.
* If none is defined, the intersection of all sets of accepted command types of all group
* members is used instead.
*
* @return the accepted command types of this group item
*/
@Override
@SuppressWarnings("unchecked")
public List<Class<? extends Command>> getAcceptedCommandTypes() {
if (baseItem != null) {
return baseItem.getAcceptedCommandTypes();
} else {
List<Class<? extends Command>> acceptedCommandTypes = null;
for (Item item : members) {
if (acceptedCommandTypes == null) {
acceptedCommandTypes = new ArrayList<>(item.getAcceptedCommandTypes());
} else {
acceptedCommandTypes.retainAll(item.getAcceptedCommandTypes());
}
}
return acceptedCommandTypes == null ? Collections.unmodifiableList(Collections.EMPTY_LIST)
: Collections.unmodifiableList(acceptedCommandTypes);
}
}
