#Minimum API functionality for complex entities
bleak plover
For more context, I was looking into the unifi access integration and it seems that the API doesn't allow for locking individual doors. The integration now implemented it as a button (unlock) + binary sensor (status). Is this the expected outcome?
random mural
I think so, yes. The lock entity doesn't have supported features for lock/unlock.
Only for open.
So it becomes a bad experience if the lock always errors on lock or unlock.
Me and Joost talked about this a couple of weeks ago I believe, in another thread.
bleak plover
Got it. Also, I just checked again and it also doesn't support reporting the lock state, only if the door is opened / closed. So only 1/3 features are supported required for the lock.
random mural
bleak plover
I feel like this could be documented in the devdocs. Not only for locks but for all complex entities and also what should be done if the API doesn't support the minimum requirements ('split into these basic entities with this device class').
Having Claude scan the integrations quickly there are other lock platforms which don't support all functions:
- kiwi: doesn't support locking
- xiaomi_aqara: only supports reporting the state
- subaru: doesn't support reporting the state
- igloohome: doesn't support reporting the state (assumed state) - I think this might actually be ok.
I would assume that there are more examples for other complex entities.
wet sedge
Personally I rather see we fix the supported features in the lock entity and use it even only for a state rather than just a sensor. Mainly for the reason of standardization and the component is responsible of what a state can be and/ or actions.
Would say the same for climate and any other “complex” models