Deconz-rest-plugin: Get Elko Thermostat to show temperature for floor sensor

[corvy]

This is a feature request to fully get this device supported:

https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1291

From a developer of Homey I found that the floor sensor is attribute 0x409, but this does not show in REST. Local Temperature is always the air temperature. Would that be possible?

What information would be needed to get this done? Thank you!

Device
Screenshots

[olekenneth]

Also missing state/operation. Home Assistant always says it's off.

[chairman2s]

@olekenneth I have the same problem. Are you using the api? Mine just appeared in HA but after a while it's gone. Then I must go into VNC and it comes back....

[SwoopX]

It might take a bit time to realize that since we have 2 challenges here. One is the extention of the API, the other one that deconz currently misbehaves if there's more than one manufacturer specific attribute with the same ID. The one coming first gets precedence (which shouldn't be).

You only need the attribute to be read, right?

[corvy]

Yes that's right. The thermostat is set to heat based on the air or floor sensor. If we could read this then we could get proper reading of current status. Setting the target works no matter what sensor is selected.

[kojax-net]

This device has many vendor specific attributes. A developer of a smartthings app has listed them here:
https://github.com/nilskaa/Smartthings/blob/master/devicetypes/Elko%20Super%20Thermostat%20-%20vendor%20specific%20attributes.txt

I think these attributes are the most important, and should also be implemented:
0x403 (encoding:30, value:
0x409 (encoding:29 value:
0x415 (floating encoding:10, value: 00=idle 01=heating

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[corvy]

I would like to keep this issue open. It is very much wanted still!

[gesv]

I would like to keep this issue open. It is very much wanted still!

I couldn't agree more. Please keep this issue open until the issue is fixed.

[t112013]

Please keep this alive.
this is something we need 👍

[Mimiix]

@SwoopX Is this added?

[SwoopX]

No, this is a bit complicated as I explained. Clusters have been added to general.xml and are basically available. However, this currently works only if you manually place the Elko specific attributes above all other manufacturer specific attributes for the thermostat cluster.

Extending the API where required is still open...

I already placed the backlog label to keep this one open.

[arnerek]

I have moved the Elko manufacturer specific attributes in general.xml and restarted deCONZ service.

I have not been able to read the attributes as they are all grey in deCONZ. Anyone succeed to read the ELKO specific attributes? I am particularly interested in the "Heating active/inactive" attribute

[arnerek]

According to the text file in https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3123#issuecomment-670978296 the attributes are e.g. 0x403 while in the general.xml this was added to 0x4003. Is this by intention/correct?

[arnerek]

I finally managed to get deCONZ to read the ELKO specific attributes by modifying the latest general.xml:

1. Changing the attributes from 0x400x to 0x040x as specified in the resource further up in this issue. Since it is not the 4000 series of attributes it does not need to be moved further up either.
2. Removed mfcode="0x1002" from each of the _attribute_ but kept it in attribute-set. Without doing that, deCONZ replied with “unsupported attribute”

[arnerek]

I have made a pull request for the heating status: https://github.com/dresden-elektronik/deconz-rest-plugin/pull/3311.

I have not included the floor sensor as it needs to check some logic whether you use the Air sensor or if you use the floor sensor.

[SwoopX]

Hm, I'd wish the vendors would more tightly adhere the specs as manufacturer specific attributes start from 0x4000 onwards and those before are standardized (or at least are supposed to be)...

Thanks for raising the PR, but I got even more changes ready for the device not yet pushed to a branch of mine. Would it be ok for you to close the PR while I take over your attribute reporting?

[arnerek]

Sure, I thought raising a PR was the easiest way to share the changes!

[SwoopX]

Ok, I guess I'm almost done. However, I wonder if 0x0415 should be mapped to state on. As I see it, this attribute indicates if the device is currently heating, so calling the state heating would probably more appropriate. In addition, we have 0x0406 (Device on), which might be the better fit for state: on in this particular case.

What do you think?

I'm also not too sure if 0x0403 should be reported as state. It looks more like this has to be configured based on the given situation?

[arnerek]

I think your suggestion is much better. I was not aware of the heating attribute.

I checked the 0x0406 attribute and that can be used for turning the thermostat off and on.

This specific github issue is to include floor sensor measurement. I don’t have a floor sensor myself. I use the air sensor and the temperature is already available in the rest api. If floor sensor is enabled (0x0403 = 1), the attribute 0x409 could replace the local temperature measurements? I think the people using floor sensor should have their opinion here.

How easy is it to add extra attributes in the api? Maybe it is easier to just include floor sensor temperature as extra attribute? In this context I will also suggest to include 0x0408 as average power consumption.

[kojax-net]

I also agree, 0x0406 should be mapped to on/off and 0x0415 to heating/idle.

I don’t think 0x0408 attribute is power consumption directly, but rather time spent in “heating” state (0x0415) last 10 minutes. It seems to be a number between 0 and 2000, changing every 10 minutes. So if the thermostat has been on(heating) for 5 minutes in the last 10 minutes interval, this attribute will be 1000. Then time spent in heating state will be (1000 / 2000) * 600s and power consumption can be calculated based on the kW-rating of your heating cables.

[SwoopX]

Thanks for the feedback so far. I now have mapped device on/off -> state and heating on/off -> heating. I like the idea of "reusing" temperature depending on where the temperature is actually measured (air or floor) very much. However, I hope this would not cause any trouble not having both values available...

What's then still pending is making the temperature sensing via 0x0403 configurable via API. For this, I'd prefer to reuse mode although the settable values are unique for this device.

@arnerek It depends on the attribute how much effort it is to add it to the API.

[arnerek]

The devices have lcd screens where you choose between air or floor sensor. I would expect that this is something you do once, but of course it is nice to have the possibility to configure via rest api

You are suggestion to use e.g mode: heat, floor sensor and mode: heat, air sensor or something like that? How will that influence e.g. HA integration?

It might be a possibility that some want both measurements. As I said, I have only the air sensor so I already have the measurements I need.

[SwoopX]

You are suggestion to use e.g mode: heat, floor sensor and mode: heat, air sensor or something like that? How will that influence e.g. HA integration?

Kinda. It would be mode: air sensor, floor sensor or floor protection. I'm just lacking a proper name for that, maybe just call it temperaturemeasurement?
No clue if that would have any impact on HA as I don't know if it expects the "typical" zigbee values here.

[kojax-net]

Is it possible to report both temperature measurements in 0x0409 and 0x0000 through the api?

As far as I understand, the temperature state will be dependent on the value in 0x0403. If it is 02, temperature measurement should be from 0x0409, and if it is 01 or 03, temperature measurement should be from attribute 0x0000. Still, I hope both temperature measurements can be available through api.

[SwoopX]

Yes, you can also have both temperature values. So air would then be temperature and floor floortemperature. Seems like the safer variant.

[arnerek]

Great! Looking forward to the next release 👍

[arnerek]

There is a pull request here with the fixes included:
https://github.com/dresden-elektronik/deconz-rest-plugin/blob/2baf9573f18035fc182fa67fa8c4662e2fa50bd2/general.xml

I hope the pull request mentioned above is included in the beta release of deconz which is normally released 15th of each month, i.e. in two days!

[oywino]

@arnerek As far as I can see, the section referred to as "ELKO specific thermostat attributes" (#3213) has been added to deCONZ 2.05.84, but still all these attributes are greyed out in the 0201 Thermostat Cluster.
Am I missing something?

[arnerek]

Yes, the added Elko attributes were incorrect (0x4000) while the general.xml in the pull request use the correct (0x0400) attributes

[oywino]

Indeed! Replacing the general.xml with the one from the pull request did make a difference. Now I can see a few additional attributes. But then what? How do I get HA to show floor temperature and not air temperature?

[arnerek]

Ive done some more debugging. The extra attributes never ended up in the RestAPI. I tracked it down to this test in thermostat.cpp: https://github.com/dresden-elektronik/deconz-rest-plugin/blob/5d8aa096242dd69977ccf105cc22c3f816644a31/thermostat.cpp#L600

zclFrame.manufacturerCode() == VENDOR_EMBER

This is not true for some reason. After removing this for the Elko attributes the “floortemperature”, “heating” and “on” state attributes are correctly reported in the API.

[Mimiix]

@SwoopX

[oywino]

Great work @arnerek !! How can we implement your discoveries? Do we have to await a new PR to be released on the 15th ?

[arnerek]

It is @SwoopX that is doing the hard work. It is really appreciated!

I now have the following remaining issues:
1) The config of "on", "locked" is not doing anything. The config section of the Rest API changes, but the device is not changed, neither the "state" ("on" attribute)
2) I can't see any "mode" attribute, I am not sure if it should be there?

{
"config": {
"heatsetpoint": 500,
"locked": true,
"offset": 0,
"on": true,
"reachable": true,
"schedule": {},
"schedule_on": null,
"temperaturemeasurement": null
},
"ep": 1,
"etag": "8a4a56e949ae694ace65cd58ceb2d17e",
"lastseen": "2020-10-29T20:28Z",
"manufacturername": "ELKO",
"modelid": "Super TR",
"name": "Super TR",
"state": {
"floortemperature": -9990,
"heating": false,
"lastupdated": "2020-10-29T20:28:04.875",
"on": true,
"temperature": 1840
},
"type": "ZHAThermostat",
"uniqueid": "00:0d:6f:00:15:55:29:4f-01-0201"
}

[arnerek]

I progressed some more:
1) config of "locked" is now working. The attribute Id should be 0x0413 in https://github.com/dresden-elektronik/deconz-rest-plugin/blob/5d8aa096242dd69977ccf105cc22c3f816644a31/thermostat.cpp#L668 and https://github.com/dresden-elektronik/deconz-rest-plugin/blob/5d8aa096242dd69977ccf105cc22c3f816644a31/rest_sensors.cpp#L1388

The "on" attribute is still not working...

[SwoopX]

Please remove what you did here https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3123#issuecomment-718922994for all the 4 or 5 Super TR attributes as I did in the last commit.

Already prepared the attribute change for the child lock locally.

[arnerek]

Thanks. I already removed the check for all Elko attributes, but that did not solve the problem.

I will continue debugging more this evening. Should "mode" be visible in the "config" section? I see reporting of this attribute in the logs, and the string is also set correctly.

With the PUT request for the "config"/"on" attribute, I don't see logs of ZclWriteAttribute. For Child lock the API is entering that function and correctly setting the child lock.

[SwoopX]

That is the "mode" temperaturemeasurement, isn't it?

Regarding the on/off, I'll have a look. We've changed the "usual" behaviour.

[arnerek]

I was thinking on System mode: Attribute 0x001C https://github.com/dresden-elektronik/deconz-rest-plugin/blob/5d8aa096242dd69977ccf105cc22c3f816644a31/thermostat.cpp#L13

[SwoopX]

That one is not exposed 🤷‍♂️ So, apparently you wanna have it, right?

[arnerek]

Ok, Thanks. I thought it should be there for all thermostats, but it is not important for me. Maybe Home Assistant / other integrations are dependent of this?

The only remaining issue is the "config"/"on" requests, otherwise the device is working perfect now

[SwoopX]

Well, the "mode" pretty much depends on you. If you say it's usable and you wanna have it, it's not a big deal...

Btw, "on/off" would not work via config, that can be ignored. Would be in state, but I'm not sure if that would do either.

[arnerek]

Maybe it could be exposed then to be compliant with the other thermostats? The reporting is already in place and working.

[SwoopX]

We typically expose the working capabilities for thermostats. E.g. for the Danfoss, it has the mode attribute, but it's non-functional and therefore not exposed. Unfortunately, there's no "standard" for thermostats in that sense, except for exposing temperature and heatpoint.

[arnerek]

Then I think it makes sense to not expose it. This thermostat has only on / off functionality and if the "config"/"on" is working all will be good!

EDIT: I noticed your edit in the previous post. If the "config"/"on" is not going to work, what is the best way of turning the thermostat on/off? Can the "System mode" be used for that?

[SwoopX]

Dunno, that's what you'd need to find out. Meanwhile, I'll see if that can be done with state/on and if we want that.

[arnerek]

Yes I will check this later this evening. I think you are correct, i.e. even with the device off the system mode remains at "auto". I will confirm this later today.

Deconz Home Assistant integration is using the mode parameter to turn on/off device:
pydeconz.errors.RequestError: /sensors/49/config/mode parameter, mode, not available

[oywino]

@arnerek, is it possible to send you a DM ?

[arnerek]

I have tested some more. System mode is not changing when device is turned off. The Deconz Home Assistant is relying on the "mode" parameter, so I am suggesting that attribute 0x0406 (Device on) is mapped to both "on" and "mode" (with "heat" / "off")

[SwoopX]

Thanks. Now, before I do the changes, how does it look like the other way around? So, setting 0x001C to off and heat, would that change attribute 0x0406 in thermostat cluster?

Just seen that config/mode has not been exposed, but all other necessary preparations in the code are available.

[arnerek]

I tried that but I am not able to change value in deconz. After the attribute is read the enumeration list in deconz is disabled.

[arnerek]

I could not change attribute 0x001C with Deconz, but with use of a modified Rest API I could change the attribute, (which again was confirmed with readings in Deconz).

It is what you assumed, attribute 0x001C is simply ignored by the device. I tried 0x00 and 0x01, but no change. I think it safe to say that the 0x0406 needs to be mapped to the "mode" parameter.

[SwoopX]

So, but setting 0x0406 truns the thermostat on or off?

You might want to give it a try with a branch of mine having mode exposed for the device and the previous corrections included.

git clone --branch enhancements https://github.com/SwoopX/deconz-rest-plugin.git enhancements

[arnerek]

Yes, setting 0x0406 is turning the thermostat on/off.

I actually tried your branch already to test the 0x001C attribute as I could not change this with Deconz. I included "Super TR" for testing purpose here: https://github.com/dresden-elektronik/deconz-rest-plugin/blob/b059f4baf87338df0000daba4706700425a3cad4/rest_sensors.cpp#L1229

[SwoopX]

Alright then. I'll see if I can update the code for further testing. Will let you know when ready.

[SwoopX]

@arnerek Code is ready so would appreciate if you could give it a go.

[arnerek]

@SwoopX Working great! Thanks for the great work in implementing this 👍

[arnerek]

I just discovered this one: https://github.com/SwoopX/deconz-rest-plugin/blob/c3ce518b176b9103fb3ff322bd47615999c09cfc/thermostat.cpp#L479 This should be removed as the reporting has been removed?

[SwoopX]

Shouldn't cause any harm, but yeah, probably better. Done.

[arnerek]

Not any harm but the mode parameter changed between auto and heat every 5 minutes which is unnecessary. Thanks!

[SwoopX]

Sounds like fubar reporting for that one 😂

[corvy]

You guys are heroes @SwoopX and @arnerek ! Thanks for the great work, looking forward to testing this :D