Add toggle support for groups

[d0b3rm4n]

This allows to change a group from on to off ja vice versa with the same button event.

Works for me with Xioami (lumi.sensor_switch.aq2) switches to use the same button event to toggle the light state.

[d0b3rm4n]

update for the docs in dresden-elektronik/deconz-rest-doc#1

[ebaauw]

I really like the idea of adding support for toggle to deCONZ, not just for groups, but also for lights. This would make the rules for stateless switches so much easier.

I’m afraid this implementation might not be very robust, depending on the timely correctness of state.any_on. I would suggest to send a ZigBee Toggle command, instead of trying to figure out whether to send On or Off. The value ofstate.on or state.any_on and state.all_on will/should be updated by the fast-polling of the light(s) anyway.
This would also enable the flip-flop effect when only half the lights in a group are on.

[manup]

Indeed, it's a tricky case, state.any_on might not be correct and sending ZigBee toggle to a group might not result in what the user expects, since every light will toggle based on it's current on state.

[ebaauw]

It does make a great effect for Xmas

[d0b3rm4n]

well I was not sure how welcome my patch would be, so I started with the group, which I use.

If it's welcome I can add the same to the light API.

True on very fast on/off/on cycles, it skips sometimes a press, but under normal use (go into a room, pick up something and leave) it works well for me.

[doctorjames]

@ebaauw I've similarly manually made pairs of rules that toggle groups on/off from a hue tap depending on whether any lights in the group are currently lit (this is just a carry over technique from when I was previously using the Hue hub). It seems to work pretty well.

If one was to also create a BIND connection between the tap and the zigbee toggle of all the lights in the group, would this result in a straightforward race between the direct zigbee binding and the event being processed via rules within deConz (which presumably the bound zigbee command ought to almost always win)?

I'm wondering out loud whether the click could simultaneously be processed by a rule that sends an explicit "OFF" with a condition being that any of the lights in the group were on: I'm guessing that the tap event ought to be seen by deConz before it could get around to polling the lights that have simultaneously been toggled by the zigbee binding, and thus the rule processing will believe them to still be on. If so, then in most cases the rule's "OFF" action won't do anything noticeable, but if you'd got into the situation where not all lights in the group had come on originally, it would force off everything, including any lamps that had unintentionally been toggled to on.

I hope that made some sort of sense!

[ebaauw]

If one was to also create a BIND connection between the tap and the zigbee toggle of all the lights in the group

You cannot bind a single command - you can only bind a cluster. It’s up to the switch which commands are sent, the Hue dimmer sends On and Off, the Trådfri remote sends Toggle.

would this result in a straightforward race between the direct zigbee binding and the event being processed via rules within deConz (which presumably the bound zigbee command ought to almost always win)?

Define “win”. The direct connection would arrive first, the command from the rule second, so that will stick with the lights. If the commands arrive quickly after each other, the light probably won’t even show anything for the first command.

[doctorjames]

You cannot bind a single command - you can only bind a cluster. It’s up to the switch which commands are sent, the Hue dimmer sends On and Off, the Trådfri remote sends Toggle.

Ah, I see - this is where my understanding is evidently lacking due to only having used the API provided by Hue before. The only switches I have are Hue Taps which as they use the Zigbee Green Power protocol don't appear as live devices in the deConz UI to explore. Are they even able to be bound to anything, or do they always get handled via the rules? (Please feel free to just point me at some documentation; I've just not found anything about this level of the system yet). If they can be bound, do you know what commands they send?

Define “win”. The direct connection would arrive first, the command from the rule second, so that will stick with the lights. If the commands arrive quickly after each other, the light probably won’t even show anything for the first command.

By "win" the race, I meant arrive first, which concurs with your clarification. With a switch sending toggle this should provide a more robust toggling-off when the coordinator is available, with a functional fallback when not. Unfortunately if we can't dictate the direct sending of on/off/toggle this is of more limited use.

[ebaauw]

The Hue tap switches use a different protocol, ZigBee Green Power. They broadcast a ZGP command, that needs to be picked up by a ZGP sink and translated into a regular ZigBee command. If memory serves, button 1 is meant to be mapped to Toggle (or was it Off?) and buttons 2 to 4 to Scene recall. The buttonevent values you see in the API are actually the ZGP command codes. Both the Hue bridge and deCONZ gateway act as ZGP sink, but neither sends out ZigBee commands on receiving a ZGP command.

To use the tab in a mesh network, ZGP proxies need to forward the ZGP command to the ZGP sink (by unicast). Hue lights can act as ZGP proxy, IKEA and OSRAM lights cannot (look for the green power endpoint in the deCONZ GUI). However, ZGP proxies need to be configured, which deCONZ currently doesn’t, see ??? (I thought there was an earlier issue on this, but cannot seem to find it). Meaning Hue tap switches only work when in direct range of the gateway.

I wouldn’t be surprised if the Hue lights can actually be configured as ZGP sink as well (enabling standalone use of the Hue tab). Looking into the ZGP stuff is somewhere at the very bottom of my todo list.

[doctorjames]

Thanks for the explanation!

I saw you mentioned on another issue about wishing for a FAQ. Perhaps it's worth creating one on the github wiki pages? At the very least it would relieve the burden of duplicate questions which you end up shouldering! At the moment the github issues seem to be the best source of technical information thanks in a large part to your interactions.

Possibly a separate glossary page would be useful too. E.g. what is a "cluster", ZHA, ZLL, ZGP, Green Power, etc. (ideally with links to external documentation if there is any that's public to relieve effort). Maybe a page for snippets of contributed examples of API usage and useful sets of rules would be good too.

In the meantime I added your answer above (with a check of the tap event codes) to the existing Sensors Wiki Page