Improve support for ELKO Super TR thermostat

[SwoopX]

Improve support for ELKO Super TR thermostat (#1291, #3123)

Enablement of sensor bindings is not included, but covered by a different PR (#3409).

• Correction of manufacturer specific attributes
• Bindings: heating setpoint, thermostat mode, device on/off, floor temperature, child lock, heating active/inactive
• Introduce state/floortemperature, state/heating and config/temperaturemeasurement to REST API
• state/floortemperature provides the floor temperature in addition, analog to the already given temperature (Int16)
• state/heating indicates if heating is active/inactive (Bool)
• config/temperaturemeasurement sets the mode of operation and allows to set the following string values: air sensor, floor sensor, floor protection
• The manufacturer specific attribute 0x0406 (Device on) is mapped to state/on

[arnerek]

I use the Elko Super TR in regulator mode, i.e. I create my own thermostat by having a zigbee thermometer in the bathroom where the heating is applied. In this mode the local heatsetpoint attribute is the load in %, i.e. 500 is mapped to 5%.

I noticed that the Rest API is not allowing me to set a lower set point than 5% and higher than 30%. I have tracked the problem to this PR: #3155. (thermostat.cpp)

Should this sanity check be dependent on the device? I noticed that the attributes 0x0003 (abs min heat setpoint limit) and (0x0004 (max heat setpoint limit) change depending if I use regulator or thermostat mode, but I don't know if all manufacturers use these attributes. Should I make a new issue since this is not only related to Elko Super TR device support?

[SwoopX]

What sanity check? The PR doesn't include anything you're referring to as far as I can tell. Each thermostat handles the min/max values differently and the attributes you mentioned are not responsible for setting the boundaries. So bottom line is: it's a zoo out there.

[arnerek]

I was referring to this line:
if (!ok || heatsetpoint < 500 || heatsetpoint > 3000)

[SwoopX]

This is irrelevant as it applies for on-device schedules only.

[arnerek]

Ok. Sorry, I did not trace to the correct section. I am guessing the sanity check of requests are within resource.cpp?
Still, I am not able to set e.g. heatsetpoint: 5000 (50% load), but I guess my use of this is a real corner-case and not a problem for many users.

[SwoopX]

Erm, that's gonna be funny. Setheatpoint is degrees, not percent. In that sense, you' try to set the thermostat to 50° 😂

Maybe I can discuss with the others

[oywino]

The great work that you have done, have brought us all a long step further. Fantastic!
But there are still some loose ends; The ELKO Super TR is still "invisible" in the Phoscon UI, and as a consequence of that (i think) it doesn't show up in the available device list in node-red-contrib-deconz OUT node.
The author of the node-red-contrib-deconz Pallette says that this is not something he can control as he only gets his device list from Phoscon. If it isn't in Phoscon, then - sorry. So his advice is for us to issue a new device request in Phoscon.
Well, I tried to follow that path, and it eventually just took me back here again. So I'm running in circles now.
The ELKO Thermostat is listed as a supported device for deCONZ, but how can you make it become visible in Phoscon also?
Obviously, Phoscon does playa role in the equation, because the only way to add the Thermostat to deCONZ is through Phoscon. This lead me to believe that Phoscon is aware of its existence (how else can it be able to add it?), but for some reason it doesn't show up in the sensor list in Phoscon.
Can that be fixed ? Please ?

[SwoopX]

So his advice is for us to issue a new device request in Phoscon.

Correct. But note that this is the deconz rest api plugin repo, so you need to raise it at the phoscon-beta repo. Technically, the device is ready for use.

[oywino]

OK, so I have now files a new Device Request in the phoscon-beta repo here:
https://github.com/dresden-elektronik/phoscon-app-beta/issues/248