[deconz] Issue with Danfoss Ally thermostat

[SecurityAddicted]

Expected Behavior

Hello,
I have a set of Danfoss Ally radiator thermostat configured with deCONZ.
The valve position value reported by the REST API ranges from 0 to 100, however the deCONZ binding shows it from 0 to around 39%, but I think it should just report the value as is as it maps correctly as percentage.

Current Behavior

The deCONZ API shows a percentage value of 100%:

but the binding reports it as 39%:

Item declaration in OH2.5:

Possible Solution

I think the problem resides on the following line:

openhab-addons/bundles/org.openhab.binding.deconz/src/main/java/org/openhab/binding/deconz/internal/handler/SensorThermostatThingHandler.java

Line 156 in 05cadda

updateQuantityTypeChannel(channelUID, newState.valve, PERCENT, 100.0 / 255);

Context

Trying to activate the boiler based on valve opening (not the best thing to do tho, the device exposes a "Heat Supply Request" attribute which is not available on this binding, I'll open a feature request later)

Your Environment

Tested in both OpenHAB 2.5 and 3.1.

[SecurityAddicted]

Anyone on this please? Thanks.

[J-N-K]

Difficult. According to the test API-response (which I believe is a real-world example), the Eurotronic thermostats report 0-255, so the code would be ok. I'll try to check that with the Deconz people.

[danieldemus]

The zigbee spec is wonderfully ambiguous, but says the value is reported as an 8-bit value "in percent" ZigBee Cluster Library Specification page 373, section 6.3.2.2.1.8 :-0), so I can understand the danfoss interpretation. The question is how other thermostat makers have interpreted this. Table 6-11 actually contains a specification of the range as 0x00 – 0x64, so the correct implementation is the danfoss/ubisys one. Thsi should be the normal default usage, while 0x0-0xFF is the exception.
According to page 5 of this document Danfoss Ally eTRV1.18, Zigbee Cluster Specification the min/max range of the 0201/0008 attribute (PIHeatingDemand) is 0x0 to 0x64. So 0 to a 100.
Here Eurotronics Spirit they only mention the values 0 and 255, ie. open/closed?
Over at https://github.com/Koenkk/zigbee-herdsman-converters, it's these danfoss ones and the ubisys h1, which deconz apparently doesn't support yet, that seem to have exceptions.
deconz just passes the value through, so these should be treated as special cases.

[jlaur]

Maybe worth to mention that there is also (or might be) interpretation/mapping within deCONZ, see for example dresden-elektronik/deconz-rest-plugin#5943.

[danieldemus]

The attribute in dresden-elektronik/deconz-rest-plugin#5943 is danfoss specific. The PIHeatingDemand attribute, which is the source of the valve value in deconz, is specified in the zigbee specs. The few cluster documents I have been able to find for other thermostats agree on the 0-100 range, so I'd have to say the eurotronic spirit implements this attribute incorrectly, probably because the eurotronic specific Set Valve Position attribute accepts 0-255.
You can see here https://github.com/dresden-elektronik/deconz-rest-plugin/blob/6026819eb9ee50815c69be6f3d2b06637aa70ef2/thermostat.cpp#L432-L472, that the value is just copied from the zigbee message to the valve value.
It would be better to assume most products follow the specification and only make exceptions for the ones with errata.

[J-N-K]

This needs to be fixed in deconz IMO. We discussed a similar issue in the developer chat in deconz and came to the conclusion that the deconz API should normalize values.

[danieldemus]

Agreed, but it should fixed in deconz to normalize so that it conforms to the zigbee specification 0x00-0x64. Which means openhab should expect 0-100 as the value. I assume more thermostats follow the specification than not.

I made a suggestion of how to handle this in #14259.
Until deconz is fixed it would be better to normalize to the standard in openhab, than have incorrect readings.

The answer and precipitous closing of dresden-elektronik/deconz-rest-plugin#6641 doesn't make me optimistic.

[J-N-K]

Fixed in #14622