Zigbee switches only contain client clusters that are meant to control server clusters on a different device/endpoint.
This device type -> cluster mapping can be found in https://www.nxp.com/docs/en/user-guide/JN-UG-3076.pdf.
The intended usage is of connecting client clusters to server clusters is described in https://products.currentbyge.com/sites/products.currentbyge.com/files/document_file/DT200-GE-Zigbee-Primer-Whitepaper.pdf
The lack of server clusters on switches has been verified using a GE ZigBee Lighting Switch 45856GE and a 45857GE dimmer.
Output from a 45856GE:
Device:
NWK: 0x0cd8
IEEE: 00:22:a3:00:00:1f:37:68
Endpoints:
1: profile=0x104, device_type=DeviceType.ON_OFF_LIGHT
Input Clusters:
Basic (0)
Identify (3)
Groups (4)
Scenes (5)
On/Off (6)
Metering (1794)
Diagnostic (2821)
Output Clusters:
Time (10)
Ota (25)
2: profile=0x104, device_type=DeviceType.ON_OFF_LIGHT_SWITCH
Input Clusters:
Basic (0)
Identify (3)
Diagnostic (2821)
Output Clusters:
Identify (3)
On/Off (6)
bellows 0.3.0 changes the API to have both, renaming the attribute which used
to be for input clusters in the process.
This is in preparation for remotes.
* Add support for Zigbee Home Automation
* Fewer magic numbers
* Make optional device config work
* Remove non-zha device_tracker stuff
* Always return boolean from is_on
* Only pass through JSON serializable discovery_info
* Update to bellows 0.2.4
* Fewer magic numbers in binary sensor
* Populate const structures from a function
* Update bellows to 0.2.6
* Fewer magic numbers in light
* Take all possible clusters when overriding
* Update bellows to 0.2.7
Igor Bernstein
Russell Cloran
Russell Cloran
Fabian Affolter