Blue 2-1 as hub-less scene controller (zigbee scene recall?)

Switches General Discussion
,
1

I’m interested in the ability to use the multi-taps to trigger other zigbee devices without the use of a hub as the name implies. My initial research would seem to indicate that I’m out of luck with the current firmware but in that case this may turn into a feature request.

The challenge I’m trying to solve at the moment is if I can setup a poor man’s LZW36 alternative. The idea is to put a zigbee dimmer module and a zigbee relay module in the fan canopy; dimmer to the light, relay to the fan. By binding the blue 2-1 to the dimmer module I have lighting figured out and it will work without even with the hub being offline (eg after a power outage and HA server needs a restart). It would therefore be great to setup a scene (or two) to turn on(off) the relay module/fan on, eg setup the fan to come on with a triple tap of the up paddle.

In researching the topic and zigbee commands, unfortunately I doubt this is currently implemented in the firmware of the switch. Perhaps it is there but I haven’t found anything in Z2M to indicate I can configure such a feature.

From what I gather zigbee has scenes which are basically memorized settings (eg on/off state and dim level) that are given a sceneID. Groups can also have scenes ascribed to them, I assume the groupID is just a modifier to the ‘save slot’ of the sceneID. Then to activate a scene you would have a scene controller send a scene recall command. This command is sent to either the deviceID or the groupID, and therefore a device listens for the recall command and the scene number and activates the stored settings when the deviceID or groupID matches the device. Short commands that travel the network fast and it is the devices responsibility to remember the settings which for a color changing lightbulb could be a larger amount of data (color & dim level & transition speed etc etc).

I know that most current smart home implementations are moving away from using ‘local’ scenes since a quick booting hub can often cover the responsibility and provide more sophistication and flexibility to ‘scenes’. Also device/group binding will cover 99% of use cases where zigbee network responsiveness is required and where ‘hub scenes’ tend tend to reach their limit.

There may be some cluster commands or other signaling commands that could set the recall settings for a multi-tap sequence but again my reading between the lines of the documentation, the SmartThings example, etc would indicate that this isn’t currently an implemented feature.

So in the case I’m requesting adding a new feature to the switch, here’s the suggestion I’ve come up with so far. t would add a lot of config variables to the already extensive list, but I could imagine some parameters like the following for some/all of the multi-press combinations:

(multi-press#)EnableSceneRecall - enable the ‘local automation’ of sending scene recall commands to the zigbee network via this switch

(multi-press#)SceneRecallGroupID - the groupID of the scene you wish to send the recall to. Technically devices can also get directly addressed but for the sake of ease of configuration, a groupID may be setup/required in all cases, even for single device scenes. I believe some other zigbee based devices already have this sort of setup with stuff having to be a member of a group for the scene recall style stuff to work.

(multi-press#)SceneRecallSceneID - the number of the scene for the given group you wish to recall.

For 14 different multi-press combinations, that would add up to a fair few additional config parameters, but there are already a fair few for the LED bar parameters so…

Perhaps the question would be is there enough programming and memory space left on the microcontroller to be able to handle A) the zigbee scene recall code and B) the additional configuration parameters.

2

From my understanding of the scene cluster (which is not implemented on the Blue 2-1 fyi I was wrong :slight_smile: ), and the commands you’re referencing, this wouldn’t work the way you’re hoping. This was covered pretty succinctly here but to copy the relevant piece -

"This cluster allows to store specific device configurations called scenes. When a device is told to store a scene it saves its state (light on or off) and the group in which it is part of. This is done with the add scene command.

Whenever a controller wants a group of devices set a specific device configuration for a group of physical devices, then the controller will use the ‘recall scene’ command directed to the group ID intended for that group of devices."

This means that while the switch would be able to store if the load is supposed to be on or off, it’s not going to be aware of or care about the state of the relay module controlling the fan. I believe this is also part of why scenes being handled by the hub is preferable as it matches up closer to what your expectations are.

3

That is true, I agree, and probably why most manufacturers (namely other zigbee ecosystems eg IKEA I think?) don’t bother with the scene cluster. I read into zwave a lot about 10 years ago and remember a lot of documentation about setting up ‘hub-less scenes’ and the button combos/etc required were daunting, but to be fair they did accomplish basic automation and before the omnipresence of hubs/HA/etc.

But it may not particularly matter if the switch/controller is aware either. I think part of what you’re getting at is whether a ‘scene button’ would act as a toggle or as a trigger. With the toggle, it requires the controller to be aware of ‘I triggered this scene, it’s currently on, if the user presses the scene button again I have to set all my scene devices to zero so the scene turns off.’ A scene button acting as a trigger by comparison just sends out the command ‘go to your saved state xyz’ blindly, has no ability to ‘turn the scene off’ and is I believe what the recall function will accomplish as I’ve come to understand it.

But in the context of the blue 2-1, I don’t think it particularly matters, or I should say a hinderance. With the constraint that the recall command is not state aware, I would then implement the workaround with ‘triple tap up’ turns the scene on (in this case only turning on a relay that controls a fan) and ‘triple tap down’ turns on another scene (in this case a scene with the fan relay off). Since the blue 2-1 has many multi-press options, having up/down on/off scene combinations is intuitive enough for the user for the given application. As mentioned, maybe these scene recall options are only available on the up/down multi-presses because of the need to program an ‘on scene’ and an ‘off scene’.

Is this an elegant solutions? no. Would a LZW36 (or similar?) be FAR more elegant? Yes, but they’re currently unavailable with no ETA. Can a hub do the same job? Yes, and more capably. Does this require a fair bit of specific knowledge and configuration relative to the complexity of the automation trying to be accomplished? Yes, but for individuals like myself it’s flexible enough to give a lot of control once you understand. Would it be hard to implement in the blue 2-1 software? hopefully not, hopefully that ‘complexity’ is passed on to the need for on & off scenes.

Truthfully the only reason I’m pursuing the concept is that I’m sticking with the adage ‘a switch is a switch first, smart second’ and don’t want to setup basically functionality (turning a room light & fan on and off) that requires automation through the hub; this is a ‘single wire’ ceiling fan/light situation that the LZW36 was designed to address so options/solutions are very limited/out-of-stock/discontinued.

Just making a case for why it could be useful to some users. Curious if others have similar ideas/needs for hub-less automations.

4

I may be misunderstanding here and definitely tracking that there may be a way to do this, but I don’t think the scene recall feature allows it if that makes sense? Basically my understanding is that the device is only aware of it’s own stored scenes, not that it’s going to broadcast the scenes to other devices. Similarly with a group of devices it calls out using a controller to send that message to the group of devices (in which case you’re likely talking the coordinator and hub).

That said, I know it’s possible to use the switch as a coordinator, though I’m not sure how that would end up working and how you would be able to set up the groups, etc but I could maybe see a way to do what you’re talking about with that route. Additionally, in that scenario you’d lose the ability to put the switch (and other devices) in your other network as well so not sure that really gains much compared to the loss of larger control?

Edit - also to correct from my prior post, the Scenes cluster was actually implemented on the 2-1 for what it’s worth.

5

I think we agree, just getting hung up on the details. I’ll try writing instructions to see if that logical progression helps:

  1. Program you fan relay with a groupID (lets say g01), and in that groupID setup two sceneIDs, one with the relay on (s01), one with the relay off (s02).
  2. Program blue 2-1 switch ‘triple up’ button press to send the recall function with packet info (g01,s01).
  3. Program blue 2-1 switch ‘triple down’ button press to send the recall function with packet info (g01,s02).
  4. Press ‘triple up’ will send recall packet to fan relay (only member of g01), tell the fan relay to recall s01, which is fan relay on.
  5. Press ‘triple down’ will send recall packet to fan relay (only member of g01), tell the fan relay to recall s02, which is fan relay off.

I don’t think the documentation indicates that any particular device (eg coordinator) must be the issuer of a recall command, though the ‘server’ and ‘client’ nomenclature can be a a bit back and forth in the cluster library doc:

3.7.2.4.7.2 Effect on Receipt 37 4760
4761 On receipt of the Recall Scene command, the device SHALL perform the following procedure:
4762 1. The device verifies that the Group ID field contains a valid group identifier in the range 0x0000 –
4763 0xfff7. If the Group ID field contains a group identifier outside this range, the status SHALL be
4764 INVALID_VALUE and the device continues from step 5.
4765 2. If the value of the Group ID field is non-zero, the device verifies that it corresponds to an entry in
4766 its Group Table. If there is no such entry in its Group Table, the status SHALL be INVA4767 LID_FIELD and the device continues from step 5.
4768 3. The device verifies that the scene entry corresponding to the Group ID and Scene ID fields exists in
4769 its Scene Table. If there is no such entry in its Scene Table, the status SHALL be NOT_FOUND
4770 and the device continues from step 5.
4771 4. The device retrieves the requested scene entry from its Scene Table. For each other cluster on the
4772 device, it SHALL retrieve any corresponding extension fields from the Scene Table and set the
4773 attributes and corresponding state of the cluster accordingly. If there is no extension field set for a
4774 cluster, the state of that cluster SHALL remain unchanged. If an extension field set omits the values
4775 of any trailing attributes, the values of these attributes SHALL remain unchanged.
4776 5. This command does not result in a corresponding response command unless:
4777 the command is unicast, and an error occurs during its processing, a Default Response SHALL be
4778 generated with the Status code set to the error status.
4779 OR
4780 the command is unicast, no error occurs, and a Default Response is requested, a Default Response
command SHALL be generated with the Status code field set to SUCCESS.
38 4781
4782 If the Transition Time field is present in the command payload and its value is not equal to 0xffff, this field
4783 SHALL indicate the transition time in 1/10ths of a second. In all other cases (command payload field not
4784 present or value equal to 0xffff), the scene transition time field of the Scene Table entry SHALL indicate the
4785 transition time. The transition time determines how long the transition takes from the old cluster state to the
4786 new cluster state. It is recommended that, where possible (e.g., it is not possible for attributes with Boolean
4787 data type), a gradual transition SHOULD take place from the old to the new state over this time. However,
4788 the exact transition is manufacturer dependent.

from here

The approach I’ve described probably does put a lot of onus on the user to set things up correctly as ‘off scenes’ seem a bit counterintuitive, but it should A) make Inovelli’s life easier and thus more likely to implement, and B) allows for the greatest flexibility without assuming what a user would want to configure (what if someone doesn’t want/need an ‘off’ scene?).

Also some other refs:

zigbee2MQTT documentation:
To recall the scene send a command to zigbee2mqtt/[GROUP_OR_DEVICE_FRIENDLY_NAME]/set with payload {“scene_recall”: SCENE_ID} where SCENE_ID is a number (e.g. 1).

And some random SiLabs documentation:
EMBER_AF_DOXYGEN_CLI_COMMAND_SCENES_RECALL zcl scenes recall [groupId:2] [sceneId:1] [transitionTime:2]

1 Like
6

This sounds a lot how the RGBGenie remote works. It joins your network, builds groups through touchlink, and allows you to save/recall scenes using those devices. However, without a coordinator and full network, it can only control a single device.

How complex can ad hoc Zigbee controls get without a controller? eg, the Tradfri switches I’ve played with can bind multiple devices into a single group, but I’m unaware of any devices which can control multiple targets without a controller.