I’m struggling with the GROUP principle in the following OH3 configuration:
I’ve got two Zigbee light switches connected via Zigbee2MQTT and made them available as two MQTT-generic Things. For each Thing I have made a Switch Item, lets call them “Switch1” and “Switch2”.
I’m able to control the switches physically (manual) and through openhab interface (remotely).
They respond and report on changes .
Now I created a Group Item in PaperUI and put the two switches in as group member.
I am able to control both switches through the Group Item in PaperUI
Now I’m struggling with the situation that if I make a CHANGE somewhere, that it will propagate to all bound items (command).
Switch1 turned manually ON → Group ON → Switch2 ON
Switch2 turned manually OFF → Group OFF → Switch1 OFF
GROUP turned remotely ON → Switches ON
I’ve tried to set it up using rules which trigger on “group member change” and propagate though events.sendCommand(“switches group”, event.itemState) but then I get caught in an endless loop and with an in house disco which my wife doesn’t like.
I’ve seen some examples and tried some things with aggregation but I have really no idea how I should approach.
Has someone done this before or could point me in the right direction?
Not by default, it doesn’t.
Group states reflect the state of members, via whatever aggregation function you have chosen.
Commands sent to a Group Item are propagated to all members. (commands may originate from rules or UI etc.)
That’s it.
Don’t do that yet.
You’ve not told us your actual objective here. You want these two lights linked? You want them independent, but with a ‘master’ UI control?
Thank you for your reply.
Yes, I would like to have the switches linked and that a change in state on one switch will forward as new state to the other(s) switch(es).
So, event based.
And, that they are also controllable via paperUI as group (as action on present detection).
Sure. The trick to avoid endless loops on cross-linked devices is to take care only to act on change, and not on update.
The link ‘follow profile’ for example is useless in this two-way situation, it is intended for master-slave configurations and acts on update.
The Group state is no help here either, because at any given moment member Items may be in various different states.
I assume you are using OH2 because you talk of PaperUI
rule "cross linked switches"
when
Item Switch1 changed or
Item Switch2 changed
then
Switch1.sendCommand(triggeringItem.state.toString) // allows to use state as command
Switch2.sendCommand(triggeringItem.state.toString)
end
Of course you can streamline with use of Group.
rule "cross linked switches"
when
Member of GroupX changed
then
GroupX.sendCommand(triggeringItem.state.toString)
end
A switch may get commanded to a state it is already in, who cares.
Well, you might if you want to avoid zigbee traffic and a lot of switches are involved; the rule can be enhanced by only commanding switches not already in the desired state.
The rules can be further enhanced by not trying to command UNDEF states, say when one of the devices is unplugged.
No sorry. I’m not that familiar with openhab. Until today i called it just the OH3 graphical interface and after reading I started to called it PaperUI in this thread. I’m using OH3.
For my understanding of your group rule example, I suppose this is not a ‘Group item’ but are 'members of a group" (gSwitches, gLights, …)?
I had the endless loop rule below but that was no luck, what’s the difference with your rule trigger? The trigger rule in my rule was named “when a member of X changed”, not “when a member of X updated”.
triggers:
- id: "1"
configuration:
groupName: Bijkeuken_light_group
type: core.GroupStateChangeTrigger
conditions: []
actions:
- inputs: {}
id: "2"
configuration:
type: application/javascript
script: >
var NewState = "OFF";
var OldState = "ON";
var ItemName = "test";
var MemberName = "test-member";
if(typeof event !== 'undefined')
{ NewState = (event.itemState );
OldState = (event.oldItemState );
ItemName = ( event.itemName );
MemberName = event.memberName;
}
events.sendCommand("Bijkeuken_light_group", NewState); //insert member state that has triggered the rule
var message = ItemName + " from state "+ OldState + " to state "+ NewState;
actions.get("mail", "mail:smtp:Gmail_send").sendHtmlMail("mail@me.com", "lamps: " + ItemName , message );
type: script.ScriptAction
Show us your events.log documenting that.
I ask because Zigbee Item states can mess about under some circumstances in OH3 (shouldn’t happen with zigbee2mqtt).
Make sure you have no profiles on your Item-zigbee channel links.
so what is different about that?
They appear to be different Items for a start.
Then, what is NewState, is it a string or a state object (I don’t know in javascript, or if sendCommand is smart enough to work with it)
Thank you for your reply.
I’ve filtered the event.log a bit and got this for the DSL rule:
2021-12-07 15:11:56.091 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Garagelight' changed from OFF to ON
2021-12-07 15:11:56.091 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item 'Bijkeuken_licht_groep' changed from OFF to ON through Garagelight
2021-12-07 15:11:56.091 [TRACE] [openhab.event.RuleStatusInfoEvent ] - Received event of type 'RuleStatusInfoEvent' under the topic 'openhab/rules/Groep_bijkeuken_lights/state' with payload: '{"status":"RUNNING","statusDetail":"NONE"}'
2021-12-07 15:11:56.091 [INFO ] [openhab.event.RuleStatusInfoEvent ] - Groep_bijkeuken_lights updated: RUNNING
2021-12-07 15:11:56.969 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Bijkeuken_licht_groep' received command ON
2021-12-07 15:11:56.970 [TRACE] [openhab.event.RuleStatusInfoEvent ] - Received event of type 'RuleStatusInfoEvent' under the topic 'openhab/rules/Groep_bijkeuken_lights/state' with payload: '{"status":"IDLE","statusDetail":"NONE"}'
2021-12-07 15:11:56.970 [INFO ] [openhab.event.RuleStatusInfoEvent ] - Groep_bijkeuken_lights updated: IDLE
2021-12-07 15:11:56.971 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Bijkeukenlicht' received command ON
2021-12-07 15:11:56.971 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Garagelight' received command ON
2021-12-07 15:11:56.972 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Bijkeukenlicht' predicted to become ON
2021-12-07 15:11:56.972 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Garagelight' predicted to become ON
2021-12-07 15:11:56.972 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Bijkeukenlicht' changed from OFF to ON
2021-12-07 15:11:56.973 [TRACE] [openhab.event.RuleStatusInfoEvent ] - Received event of type 'RuleStatusInfoEvent' under the topic 'openhab/rules/Groep_bijkeuken_lights/state' with payload: '{"status":"RUNNING","statusDetail":"NONE"}'
2021-12-07 15:11:56.973 [INFO ] [openhab.event.RuleStatusInfoEvent ] - Groep_bijkeuken_lights updated: RUNNING
2021-12-07 15:11:58.143 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Bijkeuken_licht_groep' received command ON
2021-12-07 15:11:58.144 [TRACE] [openhab.event.RuleStatusInfoEvent ] - Received event of type 'RuleStatusInfoEvent' under the topic 'openhab/rules/Groep_bijkeuken_lights/state' with payload: '{"status":"IDLE","statusDetail":"NONE"}'
2021-12-07 15:11:58.144 [INFO ] [openhab.event.RuleStatusInfoEvent ] - Groep_bijkeuken_lights updated: IDLE
2021-12-07 15:11:58.145 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Bijkeukenlicht' received command ON
2021-12-07 15:11:58.146 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Garagelight' received command ON
2021-12-07 15:11:58.146 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Bijkeukenlicht' predicted to become ON
2021-12-07 15:11:58.147 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Garagelight' predicted to become ON
I’ve re-enabled the javascript rule (had commented the code out for DSL rule test) and now it seems to be stable My eyes fall on the line “predict”, could this part of the ‘predicted state’ and trigger undesired Change events (NewState)?
I’m very confused now. I’ll stick to the DSL code for now, as that seemed to work flawless immediately.
This is why I asked for events log of the problem.
Predictions come from the autoupdate feature of each Item.
It’s essentially an internal guess of the likely result of a command, to speed up the command-response-newstate loop for a snappy UI.
Where it goes wrong is if device response is screwy.
Command ON → predict ON (hurrah)
Device responds “I’m OFF at the moment” → state changes back to OFF
Devices reports again “Now I’ve turned ON” → state changes again to ON
Note the multiple changes, each one kicking your cross-link rule with another round of commands.
This is especially a problem for devices that poll periodically for status - a read poll can be in progress at the moment you issue a command and turn in its “old” response just after the command. I’ve no idea if this is possible with zigbee2mqtt, does it poll? Devices on the real Zigbee binding can.
It also crops up for dimmers that take time to ramp from here to there, with multiple reports of new % brightness along the way.
If you have that problem and if you cannot circumvent it with careful binding configuration, you can turn off autoupdate for affected Items. This eliminates the interim “guess” state so that you only get one (possibly delayed) change in response to a command.
Thank you for your reply.
Hmm, indeed. Should I only add the “Force auto-update = false” Metadata to the switch Items (as they represent the device) or also to the ‘Group item’?
Autoupdate is individually applied to Items.
Autoupdate has no meaning for a Group type Item, because its state is controlled solely by member Item states, if at all.
I wouldn’t do any of that unless you have identified the problem - which is currently absent?
For now the problem is absent so I’ll leave the autoupdate as is.
If I’ll experience issues I’ll start experimenting by disabling autoupdate Metadata.
Thank you for your support
Best regards,
[edit] Well, still getting lots of (debug) emails when using the DSL rule.
Adding the autoupdate reduced this to TWO messages (a Switch1 event and a Switch2 event), so seems to be necessary.
.
My eyes fall on the line “predict”, could this part of the ‘predicted state’ and trigger undesired Change events (NewState)?