Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Battery levels as own entites #1827

Open
embeddeddev opened this issue Sep 6, 2019 · 5 comments

Comments

@embeddeddev
Copy link

@embeddeddev embeddeddev commented Sep 6, 2019

Unfortunalety the battery levels of devices like Philips motion sensor and Xiaomi/Aqara ambience, door/window and vibration sensors are modelled only as attributes of their sensor values/entities like temperature and humidity so they aren't directly accessible as own entities in Home Assistant and need to be integrated complicatedly and error-prone by using template sensors.

Contrary ZHA component of Home Assistent directly exports these battery levels correctly as own entities.

In addition current implementation provides the values redundantly but in fact its only one unique device attribute which should be exported as such one.

Looking forward to receive a reply.

@erikced

This comment has been minimized.

Copy link

@erikced erikced commented Sep 6, 2019

How to expose battery levels in HA should probably be discussed pydeconz instead of here.

@embeddeddev

This comment has been minimized.

Copy link
Author

@embeddeddev embeddeddev commented Sep 6, 2019

Thx for the hint!

@embeddeddev embeddeddev closed this Sep 6, 2019
@ebaauw

This comment has been minimized.

Copy link
Contributor

@ebaauw ebaauw commented Sep 6, 2019

I’m all in favour of exposing the battery (or rather: the Power Configuration cluster 0x0001) as a separate resource, but I’m not sure whether we should do that before API v2.

Technically we could introduce a ZHABattery sensor type, exposing the battery as state.battery with a corresponding state.lastupdated (a long-time wish of mine). It would also enable us to expose the battery for devices that are currently exposed a /lights resources (like the IKEA FYRTUR). On the downside, this would almost double the amount of /sensors resources.

@manup, what do you think?

@embeddeddev

This comment has been minimized.

Copy link
Author

@embeddeddev embeddeddev commented Sep 6, 2019

Hi @ebaauw, thx for your reply and your support!

Indeed it double's the number of sensors for single sensor devices, but in reality it IS a sensor w/ important information. ZHA already grabbed this issue and provides battery levels for all battery based sensors (even if no Power Configuration cluster visible in deCONZ GUI!?)

Related to @erikced's reply I opened an mirror issue on pydeconz. Now I am really unsure to which this topic has to be associated to due to my lack of technical knowledge on internals.

@embeddeddev embeddeddev reopened this Sep 6, 2019
@ebaauw

This comment has been minimized.

Copy link
Contributor

@ebaauw ebaauw commented Sep 6, 2019

Exposing it thru the REST API is one thing, actually using it in apps or plugins to home automation systems is another. That needs to be discussed in their respective repositories. We’d keep the current config.battery around, at least for a while for backwards compatibility, and probably forever in Hue compatibility mode.

manup added a commit that referenced this issue Sep 9, 2019
Add `RStateBattery` resource, see #1827.
manup added a commit that referenced this issue Sep 9, 2019
Add `ZHABattery` and `CLIPBattery` sensor types, with `state.battery` and `state.lastupdated` and without `config.battery`, see #1827.

For now, a `ZHABattery` sensor resource will only be created for IKEA FYRTUR and KADRILJ smart blinds.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.