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.
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 @Ap15e 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?
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).