Framework for generic exposure of device configuration attributes #934
Replies: 13 comments 23 replies
-
|
That looks great only that some manufacturers is adding different functions in there devices or using other attribute with not exact the same function we have adding them then we have finding out how there is working. Firs priority is ZCL R7/8 and then i thing adding the no standard can coming later. I keep collecting info and trying documenting it for the future here: #823 (comment) Great work and hope its can coming in the future in ZHA also startup light level and color (temperature) for lights. |
Beta Was this translation helpful? Give feedback.
-
|
I aggree. I kept the manufacturer specific configuration in mind. The exposure should be configured in zha quirks like here . Just like the attributes it should be possible to add / remove / overwrite them. |
Beta Was this translation helpful? Give feedback.
-
|
Once the ZCL 7/8 PR that was merged into Zigpy is in HA the goal is to support this type of thing w/o having to explicitly specify things the same way that z2m does ("exposes") otherwise every device would need to be quirked. The part of this that is in Zigpy may be handled in HA itself (or the web socket server) I started the beginning of this type of thing w/ sirens. We already expose several selects for things like alert tone, volume and strobe. The goal is to extend the support w/ number fields and additional selects, switches etc. tied directly to ZCL commands / attributes. Currently things look like this: https://github.com/home-assistant/core/blob/cdd23abea7f8854d95c22a2dadeaffdbceeccc55/homeassistant/components/zha/select.py#L47 Next we'll tie these to ZCL commands for things like power on state etc. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks four your replies. My first approach actually was to expose all the attributes but there were too many attributes and they were causing a lot of traffic. I also thought about exposing attributes by default, if they have a class - wrapper with defined values. That could tackle most of them and should only be at least somewhat usefull attributes as someone actually took the time to write it. @dmulcahey I was inspired by the class you tagged and it was the basis of my development. The biggest issue I had was that it only catches the attributes that have not been claimed before, which in my case was none. Also this approach gives the quirks the possibility to disable / overwrite the exposure defined in an underlying cluster definition. @MattWestb startup leve, color and state are exposed by default. you will not be happy with the color-chooser, though. it just takes an integer, not a color.
Just random thoughts now
Now the question is: could this become a viable solution or will another approach be preferred leaving no room for this one. |
Beta Was this translation helpful? Give feedback.
-
Take a look at the sensor classes. They would end up looking like that. Lots of small extensions that just specify the attribute. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for taking so long to respond. Will it somehow be possible to add these outside of ZHA (eg quirks)? What would the strategy be for adding manufacturer specific configuration attributes? |
Beta Was this translation helpful? Give feedback.
-
|
Quirks for mfg specific attr and command defs |
Beta Was this translation helpful? Give feedback.
-
|
Okay, looks like you have this pretty much covered. May I ask, what is the state of development? Is there something I could help with? Also, is there a board or page where I could have picked up that you are already working on this issue? |
Beta Was this translation helpful? Give feedback.
-
|
There isn’t a board (this is something we need to get better with) As for help, We’ll take all the help we can get. If you have time ping me on discord and we can chat a bit. |
Beta Was this translation helpful? Give feedback.
-
@pipiche38 & @zoic21 Perhaps this discussion is also of interest to Domoticz and Jeedom host application implementations using zigpy? |
Beta Was this translation helpful? Give feedback.
-
|
From a Domoticz standpoint , we are not at that level and not impacted. When I did the first test, I was requesting to get the Bind and Configure Reporting also done at the quirk/zigpy level, but got a clear push back. |
Beta Was this translation helpful? Give feedback.
-
|
@pipiche38 take a look at: https://github.com/zigpy/zha-websocket-server timing just didn't line up when you folks were starting. this will provide a consistent application for anyone that wants to use it. |
Beta Was this translation helpful? Give feedback.
-
|
Related common question/request for ZHA is configuration of StartUp/PowerOn values for Zigbee lights and switches from Philips Hue, see: https://community.home-assistant.io/t/zha-hue-bulbs-restore-state-on-power-on/350548/ https://community.home-assistant.io/t/configure-ts0002-startup-behavior-and-switch-mode/410772 |
Beta Was this translation helpful? Give feedback.
-
|
@dmulcahey Branch: |
Beta Was this translation helpful? Give feedback.
-
|
Getting closer. I was messing with this weekend too. Nit: Keep the number entity stuff separate to make this easier to review. The cache update from attribute writes needs to be done in Zigpy. I’ll open an issue for that. I need to look closer at this to determine what the impact to the claiming process is. I’ll pull this down and poke at it in the debugger in a bit. If you’re on discord we can chat about this. |
Beta Was this translation helpful? Give feedback.
-
|
How can I find you on discord? |
Beta Was this translation helpful? Give feedback.
-
|
Same handle as here in the HomeAssistant server |
Beta Was this translation helpful? Give feedback.
-
|
FYI, spotted new related question in HA community if ZHA exposes "switch_type" for Aqara/Xiaomi switch module T1 DLKZMK11LM or not? https://community.home-assistant.io/t/aqara-switch-module-t1-rebound-switch/345580/ There is a related device support request asking for zigpy/zha-device-handlers#1231 I do not have that device but as I understand it, this "switch_type" configuration attribute allows you to change switch type from an ON/OFF rocker switch circuit-breaker type of switch to a NO (Normally Open) momentary push-button switch. That "switch_type" is exposed in Zigbee2MQTT: https://www.zigbee2mqtt.io/supported-devices/#e=switch_type https://www.zigbee2mqtt.io/devices/DLKZMK11LM.html Xiaomi DLKZMK11LM
|
Beta Was this translation helpful? Give feedback.
-
|
@dmulcahey has been working on exposing the configuration entities here: https://github.com/dmulcahey/home-assistant/tree/dm/zha-zcl-select Also, I have a similar PR pending here: zigpy/zha-device-handlers#1391 All three together make this setting available for Aqara H1 Switches but porting it for T1 should not be very difficult. |
Beta Was this translation helpful? Give feedback.
-
For reference, there is a similar request for "switch_type" configuration of Tuya TS0003 3 gang switch module (TZ3000_odzoiovu) here: |
Beta Was this translation helpful? Give feedback.
-
|
I have already implemented the switch type for the H1 you can use it as a reference (not merged yet ) zigpy/zha-device-handlers#1391 |
Beta Was this translation helpful? Give feedback.
-
|
Just want to mention that it seems to be only for the H1 with neutral, the H1 without neutral has a different signature for some reason and doesn't work with the handler from that PR. |
Beta Was this translation helpful? Give feedback.
-
|
FYI, tilt values window covering (blinds) device is another one needs exposing as reported by @cremor in zigpy/zha-device-handlers#1430
|
Beta Was this translation helpful? Give feedback.
-
|
While it would be nice to get those tilt values shown in the UI, I think a better solution would be to natively support tilt for covers in ZHA. Those Zigbee attributes are the default ones defined by the Zigbee standard, so HA/ZHA should support those and show them in the default cover UI elements, just like it does for Z-Wave. |
Beta Was this translation helpful? Give feedback.
-
|
Yes for comparison see some of the other components in Home Assistant core which already implemented tilt, like zwave-js and mqtt: Some other components that also already include tilt support for cover are; deconz, somfy, esphome, knx, rfxtrx, and many more: https://github.com/home-assistant/core/search?p=4&q=tilt |
Beta Was this translation helpful? Give feedback.
-
|
Hey, coming in as a bit of an outsider but if any further development has taken place to expose device configs, I was recently trying to change the speed on a aqara blind roller with HA but instead had to find right cluster to adjust it, so was curious what might happen with regards to this? |
Beta Was this translation helpful? Give feedback.
-
|
Configuration entities have been decided to be a zha/application specific thing only, which means they by design do not fit into the quirks. I think you will have to create a PR in Home Assistant to add a configuration entity. |
Beta Was this translation helpful? Give feedback.
-
|
FYI, there were some mentionings related to this in the latest "Building the Open Home" article as well as in "State of the Open Home 2022": https://building.open-home.io/innovation-versus-standards-in-the-open-home/ ("How a pet feeder shows that standards don't solve everything"). https://www.youtube.com/watch?v=D936T1Ze8-4&ab_channel=HomeAssistant (Nabu Casa user experience and frontend developers for example discussed their goal of making Home Assistant UI become more device-oriented in the future as opposed to being entities-oriented).
Meaning if wish to expose additional device configuration attributes by default then extending the device types in zha component is needed: https://github.com/home-assistant/core/tree/dev/homeassistant/components/zha i.e. submitting pull requests if you are a Python developer: https://github.com/home-assistant/core/pulls?q=is%3Apr+zha As per existing pull requests as examples: home-assistant/core#81520 (Add TI router transmit power config entity to ZHA ) and end users will need to start a new device support request(s): https://github.com/zigpy/zha-device-handlers/issues/new/choose and maybe also open a new topic under feature requests in the Home Assistant forum about exposing specific device(s) configurations(?): |
Beta Was this translation helpful? Give feedback.
-
Hi!
I developed a proof of concept for simple exposure of device configuration attributes here .
What I mean with that is for example the start up behaviour of lights.
My development is based on @puddly 's ZCLv7 development.
It exposes integer / enum type configurations as entities, that are configured in the cluster as follows:
and results in this:
I did this by extending the discovery of entities in zha integration and having integer/enum entities being created dynamically
https://github.com/dumpfheimer/core/blob/70816c9703c9b475a4ac4b50ad14788d1fb72096/homeassistant/components/zha/core/discovery.py#L131
This approach should be fully backwards compatible and enable zigpy and zha quirks to expose key configuration attributes very easily.
Feedback is very much appreciated.
Beta Was this translation helpful? Give feedback.
All reactions