Expose a sensor entity for each unique node with a "config/battery"
Closed this issue · 23 comments
I have a device in deCONZ that behaves as a bridge, representing different physical devices as endpoints with their own sets of clusters. The deCONZ REST API creates a sensor node for each of these endpoints (in this case they're ZHAThermostats) like this:
{
"35": {
"config": {
"battery": 70,
"heatsetpoint": 2300,
"offset": 0,
"on": true,
"reachable": true,
"schedule": {},
"schedule_on": false
},
"ep": 1,
"etag": "982d9acc38bee5b251e24a9be26558e4",
"lastseen": "2021-02-15T12:23Z",
"manufacturername": "Danfoss",
"modelid": "0x8030",
"name": "0x8030",
"state": {
"lastupdated": "2021-02-15T12:23:07.994",
"on": false,
"temperature": 2307
},
"swversion": "YYYYMMDD",
"type": "ZHAThermostat",
"uniqueid": "58:8e:81:ff:fe:6b:98:8c-01-0201"
},
"36": {
"config": {
"battery": 86,
"heatsetpoint": 2300,
"offset": 0,
"on": true,
"reachable": true,
"schedule": {},
"schedule_on": false
},
"ep": 2,
"etag": "62f12749f9f51c950086aff37dd02b61",
"lastseen": "2021-02-15T12:23Z",
"manufacturername": "Danfoss",
"modelid": "0x8030",
"name": "0x8030",
"state": {
"lastupdated": "2021-02-15T12:23:22.399",
"on": false,
"temperature": 2316
},
"swversion": "YYYYMMDD",
"type": "ZHAThermostat",
"uniqueid": "58:8e:81:ff:fe:6b:98:8c-02-0201"
},
"37": {
"config": {
"battery": 86,
"heatsetpoint": 2350,
"offset": 0,
"on": true,
"reachable": true,
"schedule": {},
"schedule_on": false
},
"ep": 3,
"etag": "f50061174bb7f18a3d95789bab8b646d",
"lastseen": "2021-02-15T12:23Z",
"manufacturername": "Danfoss",
"modelid": "0x8030",
"name": "0x8030",
"state": {
"lastupdated": "2021-02-15T12:23:25.466",
"on": false,
"temperature": 2337
},
"swversion": "YYYYMMDD",
"type": "ZHAThermostat",
"uniqueid": "58:8e:81:ff:fe:6b:98:8c-03-0201"
},
"38": {
"config": {
"battery": 85,
"heatsetpoint": 2300,
"offset": 0,
"on": true,
"reachable": true,
"schedule": {},
"schedule_on": false
},
"ep": 4,
"etag": "eea97adf8ce1b971b8b6a3a31793f96b",
"lastseen": "2021-02-15T12:23Z",
"manufacturername": "Danfoss",
"modelid": "0x8030",
"name": "0x8030",
"state": {
"lastupdated": "2021-02-15T12:23:41.939",
"on": false,
"temperature": 2333
},
"swversion": "YYYYMMDD",
"type": "ZHAThermostat",
"uniqueid": "58:8e:81:ff:fe:6b:98:8c-04-0201"
},
"39": {
"config": {
"battery": 83,
"heatsetpoint": 2300,
"offset": 0,
"on": true,
"reachable": true,
"schedule": {},
"schedule_on": false
},
"ep": 5,
"etag": "1f7cd1a5d66dc27ac5eb44b8c47362fb",
"lastseen": "2021-02-15T12:23Z",
"manufacturername": "Danfoss",
"modelid": "0x8030",
"name": "0x8030",
"state": {
"lastupdated": "none",
"on": false,
"temperature": 2325
},
"swversion": "YYYYMMDD",
"type": "ZHAThermostat",
"uniqueid": "58:8e:81:ff:fe:6b:98:8c-05-0201"
}
}Each node has a "config/battery" entry for the battery level of the device represented by the endpoint.
Currently, the integration seems to just take the value for the first node and expose that to Home Assistant as a sensor with the battery level for the whole "device". Since each node has distinct "ep" and "uniqueid" entries, would it be possible to instead create a sensor with the battery level per-node - just like it creates climate entities per-node?
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
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.
Whats the difference between the different modelids? And is it certain no other Danfoss devices expose these modelids?
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.
So our should be 30 and 31 having battery?
So our should be 30 and 31 having battery?
0x8030, 0x8031, 0x8034, and 0x8035 will have battery.
So a combination of manufacturer danfoss and those modelids should be sufficient I guess
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 🤷♂️
All modelids are strings in deconz. But thanks 👍🏻
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?
Probably an old structure of the company
Would a better solution to this be to get the REST API to output
ZHABatterynodes 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.
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?
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
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?
Decide on the path first because changing it down the line means I would need to change stuff a second time
I've created a draft PR to solve this. Can you try it out?
Just got a chance to try the PR. Looks great! All battery levels are exposed individually:
Thanks for this 😄
Can you make the automatic naming of the endpoints don't keep the same name? Right now they have the same name.
Have you gotten anywhere with which path regarding config/battery or zhabattery
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.
Fix has been merged in HASS. Closing this since I see it as solved. Thanks for reporting!
@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.