org.openhab.binding.zwave
org.openhab.binding.zwave copied to clipboard
Thermostat Setpoint Set Command - Values send in bytes
See discussion in thread: https://community.openhab.org/t/heatit-z-trm3-temp-setpoint-not-working/97063/66
- OH2 Version: 2.5.10
- Binding Version: Relevant for all versions
If the problem is associated with a device, please provide the following -:
- Device name: Heatit Z-Trm3
- Device version: Firmware 4.0
- Link to database: https://opensmarthouse.org/zwavedatabase/1238
- If the device is not in the database, provide a link to the manual.
- If there is an XML being generted for the device (in the /userdata/zwave folder), please provide it. network_c3a89bd6__node_5.zip debug2.log
I think there might be a bug in the binding. See debug log file. The binding sends temperature values as 1 byte temperatures information, despite the device requesting it to be sent as two bytes. See Z wave specification (https://www.silabs.com/documents/login/miscellaneous/SDS13781-Z-Wave-Application-Command-Class-Specification.pdf) 4.113.2 Thermostat Setpoint Set Command Specifically it states that:
Value (N bytes) This field is used to advertise the actual setpoint value to be set at the receiving node. The length of this field MUST be according to the Size field value. The first byte MUST be the most significant byte. This field MUST be encoded using signed representation and comply with Table 10, Signed field encoding (two’s complement representation).
However, as as the debug files shows the OH binding sends the set point temperature as one byte. 01 10 00 13 05 09 60 0D 01 01 43 01 01 01 17 25 B8 55
According to the Z wave documentation as mentioned above per 2020-07-06 the correct information would be to send two bytes signed encoding as indicated by Table 10. Corresponding to 01 10 00 13 05 09 60 0D 01 01 43 01 01 01 E6 25 B8 55
The Hex values indicates that the binding is only sending one byte information.
However, this is way out of my knowledge and comfort zone. I'm just trying to understand why it doesn't work. So please correct me if I'm wrong.
The binding is sending the data correctly formatted - as per the spec as far as I can see. You state that "the device requests it to be sent as two bytes" - how does it state that this must be sent as two bytes? As far as I can see there is no way to know what format the device requires, and the device should implement the specification which should allow 1 or 2 (etc) byte commands - so long as the length is specified in the command.
Or is this wrong now?
This is my understanding of the device spec.
It advertises the required size according to the specs. See first point under 4.113.2. "A supporting node MUST support the same format of Precision, Scale and Size fields values as it sends in the Thermostat Setpoint Supported Report Command." Thus it sends the expected format in the supported report command.
I.e. If thermostat setpoint support report command returns that it doesn't support one byte size, then according to the spec it should ignore one byte values. According to the product manual(database: https://opensmarthouse.org/zwavedatabase/1238) the supported values for the setpoint is between 50 and 400. I.e. a HEX value of 17 (23) is ignored as neither matches the byte size, or the accepted range of values as advertised by the setpoint supported report command by the device. However, I do not know where I can find the results from the Setpoint Supported Report Command in OH, so please advice. According to the producer statement in a Norwegian forum, it reports two bytes in the Setpoint Supported Report .
1 byte is simply not supported by the thermostat. And the Setpoint Supported Report Command is the item that should present this information to the OH binding. Additionally, there is no requirement in the spec stating that it the device is required to support one byte size commands.
I have only looked into the temperature value. I'm not certain if any of the other fields have similar issues.
So my question is then how does the OH binding implement the results from the Setpoint Supported Report Command from the device?
@DoleoR just FYI, HeatIT do provide a firmware for the thermostat that fixes this issue - so it works with open-zwave and openhab. I do believe that you might have a point though, as the standard firmware works with other z-wave gateways.
If I get some time in the coming months I will take a look if no-one else looks at this first.
Great. Appreciate it
Any updates on this? Or is there any thing I can do to contribute?
I found the documentation from HeatIt, and their perspective on the Zwave standard compability of setpoint command class, see attached. Test of thermostat Setpoint Command Class.pdf
This issue has been mentioned on openHAB Community. There might be relevant details there:
https://community.openhab.org/t/z-wave-heatit-z-trm3-floor-thermostat/120755/13
Any updates on this?
I just had a quick look at this -:
It advertises the required size according to the specs. See first point under 4.113.2. "A supporting node MUST support the same format of Precision, Scale and Size fields values as it sends in the Thermostat Setpoint Supported Report Command." Thus it sends the expected format in the supported report command.
This is incorrect it seems. The supported report command does not provide this information. There is a new capabilities command that has this information and this is not currently supported in the binding so it will need to be updated with this command, iterating over all setpoints as part of the initialisation.