Expose a sensor entity for each unique node with a "config/battery" about deconz HOT 23 CLOSED

Just got a chance to try the PR. Looks great! All battery levels are exposed individually:

Thanks for this 😄

from deconz.

Fix has been merged in HASS. Closing this since I see it as solved. Thanks for reporting!

from deconz.

So a combination of manufacturer danfoss and those modelids should be sufficient I guess

from deconz.

Decide on the path first because changing it down the line means I would need to change stuff a second time

from deconz.

Yes, because other devices with multiple endpoints report battery on all end points. This one is the odd one out at the moment. It could be as simple as having some logic based on modelid, typically I like to avoid managing special cases as it makes it harder to maintain over time. This one might be easy enough though

from deconz.

To make special cases even more troublesome, this particular device can expose 6 different modelIds - still manageable, but not nice 😞 They can be 0x8020, 0x8021, 0x8030, 0x8031, 0x8034, or 0x8035.

from deconz.

Whats the difference between the different modelids? And is it certain no other Danfoss devices expose these modelids?

from deconz.

0x8020 and 0x8021 are 24V-powered in-room thermostats, with and without a floor measurement, respectively. 0x8030 and 0x8031 are the battery-powered counterparts. 0x8034 and 0x8035 are in-room thermostats with a dial, instead of a display, with and without a floor measurement, respectively.

No other Danfoss devices expose these modelIds.

from deconz.

So our should be 30 and 31 having battery?

from deconz.

So our should be 30 and 31 having battery?

0x8030, 0x8031, 0x8034, and 0x8035 will have battery.

from deconz.

So a combination of manufacturer danfoss and those modelids should be sufficient I guess

Yeah, that should do it. I just wanted to point out, because I think it's a little crazy, that the modelIds are actually strings - even though they look like hex numbers 🤷‍♂️

from deconz.

All modelids are strings in deconz. But thanks 👍🏻

from deconz.

Would a better solution to this be to get the REST API to output ZHABattery nodes for each endpoint? I guess I would also need to remove the "config/battery" entries for the HA integration to pick the new nodes up, right?

from deconz.

Probably an old structure of the company

from deconz.

Would a better solution to this be to get the REST API to output ZHABattery nodes for each endpoint? I guess I would also need to remove the "config/battery" entries for the HA integration to pick the new nodes up, right?

Well I think deconz should go that direction in general. In this case they would still have the same unique id right? So it would still require some special treatment.

from deconz.

Well I think deconz should go that direction in general. In this case they would still have the same unique id right? So it would still require some special treatment.

It's me adding support for this device to the REST API. I'm following what it does for the other Danfoss device that it already supports, the Ally TRV, and not exposing ZHABattery sensors. Maybe it's not a great example to follow? For the TRVs, there are ZHATime sensors exposed that I haven't found to be particularly useful. While other well-supported devices (for example, Philips Hue stuff with batteries) do expose ZHABattery sensors - that's why I was asking.

Regardless, I see your point about those ZHABattery sensors having the same uniqueids and still requiring special treatment. Maybe for now it's best to keep it simple and just go by the config/battery entries?

from deconz.

It's probably gonna evolve to moredevicew exposing the zha battery so if it's how it should be you should do it. If deconz devs think confug/battery is better go with that

from deconz.

The config/battery gets created for sensors with batteries - whether there is a ZHABattery sensor or not. This is true also for the Philips Hue devices, for example. Their motion sensors expose ZHAPresence, ZHATemperature, and ZHALightLevel sensors - all with a config/battery entry - and a ZHABattery sensor (of course, without a `config/battery’ entry).

I’ll talk to the deCONZ devs about the ZHABattery sensor, but since it seems the config/battery entry will be there regardless, could you still special-case it for this device?

from deconz.

I've created a draft PR to solve this. Can you try it out?

from deconz.

Can you make the automatic naming of the endpoints don't keep the same name? Right now they have the same name.

from deconz.

Have you gotten anywhere with which path regarding config/battery or zhabattery

from deconz.

Can you make the automatic naming of the endpoints don't keep the same name? Right now they have the same name.

You can't really see it in the screenshot, because the names are so long, but they don't have the same names. Every name has the endpoint number correctly appended and can be renamed just fine:

Have you gotten anywhere with which path regarding config/battery or zhabattery

I've asked, but haven't received any guidance yet. From looking at the REST API code, config/battery seems to be the way to go - which is what the PR you put up handles. ZHABattery entries are used only for a handful of special cases. The ones I have created in my deployment turned out to be created by me when I was experimenting with creating sensor nodes, so I need to recant the statement I made before about Philips Hue products exposing them - they don't.

from deconz.

@hanskroner Can you please guide me how / or when to add the zigbee modul through the phoscon App.
Right now I just plugged in the master controller(not installed) in with the zigbee module to see if deconz finds it. Will the module show us as a device exportable to HA or when I pair it with the thermostats.

from deconz.