Hi,
I am using some Zigbee switch modules that allow to define the state of the bulbs connected to it after a power cut.
You can see in the following link that they have the property “power_on_behavior” which seems that can be configured using zigbee2mqtt:
Can this property be accessed from openhab using the Zigbee binding?
I’m not familiar with this device. If it is using the standard Zigbee function to do this, then it will be available in the binding (it will be a configuration on the channel). If it uses custom TuYa functionality (as I suspect it might) then it will not be possible.
Thanks for the reply @chris
As you can see in the following screenshot the device is detected as “Generic Zigbee Device”:
An this is what is shown in the Channel tab:
Should this parameter “power_on_behavior” appear in this channels list?
I am not an expert on zigbee2mqtt software, but it seems that this parameter can be accessed from it (no need to use the Tuya app):
Thanks!
That’s correct - nearly all devices will be detected in this way as the binding uses a generic type, and then dynamically creates channels and configuration based on what features the device supports.
No - it is not a channel - it is a configuration of the ON/OFF channel. But it will only appear if the device supports the standard mechanism for setting this configuration.
That doesn’t mean that the device is using the standard feature to do this. Someone may have added extra code to support such features - this can also be done in the zigbee binding.
And where this should appear? In the “Thing properties” section or in “Configuration” section from my first screenshot?
Can you point me on how to start with this extra code? (a link with some example will do)
Thanks a lot!
Neither. I’m not in front of a system right now, but from memory you need to click on the channel, and then somewhere there is an option to configure the channel.
Well, then first is to work out IF if it needed. Do you know WHAT is required yet? Does this device already support the standard features - if not how is it configured? You need to know this - or at least “I” need to know this to answer your question.
Yes, you are right, in the “Channel details” as @anon71759204 pointed out.
What do you mean by standard features? The device is working, is that enough to assume that it supports the standard features? Can I get some info to help you with that? I am used to the zigbee command from the console, I already tried to get info from teh device (fingerpint…) but no luck.
By the way, those devices are designed for Zigbee 3.0 but I am using the CC2531EMK coordinator with 2.0 firmware, do they need a Zigbee 3.0 coordinator to have this “power_on_behavior” configuration?
Thanks!
Is there an option to set the ‘power_on_behavior’?
Zigbee is a standard - it defines a lot of functions, and there is a standard function for this defined in the standard. Unfortunately, a lot of the Chinese devices like to do their own thing and have custom functions to set these features, and in that case the binding won’t know how to manage this.
No - the device might support some parts of the standards, but then implement other parts as custom functions - this is common for the Chinese devices.
You might be able to find it buried in the zigbee2mqtt code. Otherwise it requires sniffing the network to find out what’s going on, and this is quite a large task.
My guess is that they are not zigbee 3 devices - again the Chinese like to make these statements without certification. I could of course be wrong…
The main change with Z3 is the joining - here security was improved to fix some loopholes and Z3 devices generally won’t work with an HA1.2 coordinator for this reason. Typically this manifests as the device joining, and then leaving after 10 seconds or so when it finds out that the new security features aren’t implemented. If your device works with an old coordinator, then probably it is not Z3.
Other than that there is no major change between HA1.2 and Z3.0 - the Cluster Library is basically the same (this is the standard that defines all the application level functions such as the power on behaviour we are talking about here).
Finally I have been able to configure the parameter as follows:
The device now works as expected. I know that this is not the best solution but at least it is working.
