Get Elko Thermostat to show temperature for floor sensor

[corvy]

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

#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: <verified 00=local sensing mode, 01=remote sensing mode, 03=floor max temp mode>
0x409 (encoding:29 value: <verified remote/floor temperature sensor measurement>
0x415 (floating encoding:10, value: <verified heating active/inactive> 00=idle 01=heating

[stale]

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 #3123 (comment) 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: #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.

[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:

deconz-rest-plugin/rest_sensors.cpp

Line 1229 in b059f4b

sensor->modelId().startsWith(QLatin1String("Zen-01"))) // Zen

[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

[ebaauw]

I am not going to support the current implementation of state.floortemperature and config.temperaturemeasurement in Homebridge Hue, see issue linked above. I think the device should be exposed as a thermostat with state.temperature reflecting the temperature used by the thermostat in its current heating mode. If needed additional ZHATemperature sensor could be exposed for the two sensors, independent of the heating mode.

[oywino]

@ebaauw, what exactly do you mean "not going to support..." ?
Mine seem to work perfectly - as far as I can tell, with both, either - or floor temperature and air temperature control.
Are you going to change "something" in the deconz implementation for this sensor so that these things stop working?

[ebaauw]

what exactly do you mean "not going to support..." ?

See the linked issue for Homebridge Hue: it ignores state.floortemperature and config.temperaturemeasurement.

Mine seem to work perfectly - as far as I can tell, with both, either - or floor temperature and air temperature control.

Homebridge Hue supports it as any thermostat alright. The issue, I understand, is that deCONZ reports the air temperature sensor as state.temperature, when the device is actually using the floor temperature sensor when in floor heating mode.

Are you going to change "something" in the deconz implementation for this sensor

No, I don’t have access to this device.

[corvy]

I have this device if I can help assist. søn. 8. aug. 2021, 12:40 skrev Erik Baauw ***@***.***>:

…

what exactly do you mean "not going to support..." ? See the linked issue for Homebridge Hue: it ignores state.floortemperature and config.temperaturemeasurement. Mine seem to work perfectly - as far as I can tell, with both, either - or floor temperature and air temperature control. Homebridge Hue supports it as any thermostat alright. The issue, I understand, is that deCONZ reports the air temperature sensor as state.temperature, when the device is actually using the floor temperature sensor when in floor heating mode. Are you going to change "something" in the deconz implementation for this sensor No, I don’t have access to this device. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3123 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABBYNEAZIZ57ZUL5EULAULT3ZNKDANCNFSM4PWT2QAQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[torandreroland]

I created issue 5208 to follow up this.