Hi, I’m new to OpenHAB but technically literate. I setup a RPi 4 OH3 Z-Wave build using an Aeotec USB Z-Wave Gen5+, an Aeotec Multisensor and two Trane XR524 thermostats.
My Multisensor is working fine, updating in OH3, but the thernmostats aren’t. They rarely update the temperature sensor, for example right now one says in OH3 that it’s 71.6 but on the Thermostat screen I see 74.
Network map seems fine, all devices see each other bi-directionally, in theory everything should be working fine.
Any pointers on what I should look at? I’ve put Zwave in debug and the only strange message is one that says Transaction not completed, as this example below for TID 136:
openhabian@openHABianDevice:~ $ cat /var/log/openhab/openhab.log | grep "136"
2021-01-18 22:13:59.136 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 69: [WAIT_RESPONSE] priority=Get, requiresResponse=true, callback: 56
2021-01-18 22:13:59.136 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2021-01-18 22:24:18.136 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2021-01-18 22:24:34.136 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 95: Advanced to WAIT_DATA
2021-01-18 22:40:17.136 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2021-01-18 22:50:17.155 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 3: Added 136 to queue - size 6
2021-01-18 22:50:17.654 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 136: [WAIT_RESPONSE] priority=Get, requiresResponse=true, callback: 123
2021-01-18 22:50:17.663 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 136: [WAIT_RESPONSE] priority=Get, requiresResponse=true, callback: 123
2021-01-18 22:50:17.669 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 136: [WAIT_RESPONSE] priority=Get, requiresResponse=true, callback: 123
2021-01-18 22:50:17.671 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 136: [WAIT_RESPONSE] priority=Get, requiresResponse=true, callback: 123
2021-01-18 22:50:17.674 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 136: Advanced to WAIT_REQUEST
2021-01-18 22:50:17.676 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 3: TID 136: Transaction not completed
2021-01-18 22:50:17.688 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 136: [WAIT_REQUEST] priority=Get, requiresResponse=true, callback: 123
2021-01-18 22:50:17.690 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 136: [WAIT_REQUEST] priority=Get, requiresResponse=true, callback: 123
2021-01-18 22:50:17.691 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking TID 136: (Callback 123)
2021-01-18 22:50:17.694 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Correlated to TID 136: callback 123
2021-01-18 22:50:17.700 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 136: Advanced to WAIT_DATA
2021-01-18 22:50:17.701 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 3: TID 136: Transaction not completed
2021-01-18 22:50:17.728 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 3: notifyTransactionResponse TID:136 DONE
Thank you @Bruce_Osborne , that log viewer seems useful. I’m still not sure what is happening , but it gives a clearer view by grouping things together.
It seems everything is communicating, but some strange findings.
For example I learned that the thermostat seems to be responding in Celsius even though it is configured in Fahrenheit and the Thermostat screen shows Fahrenheit.
OK, so it seems the Celsius or Fahrenheit setting for the temperature of the Thermostat is something I configure in OpenHab, specifically Parameter 4 of XR524.
So I went into the UI and changed it from 0 (Celsius) to 1 (Fahrenheit), Saved, restarted OpenHab from command line (services openhab stop then start), ran a script I created to get the item state then print the temperature to log, and… it comes as Celsius
Stopped OpenHab again, went to look into the jsondb, org.openhab.core.thing.Thing.json, found that “config_4_1” was set to 0 , so I stopped OH, changed it to 1 in both Thermostats, restarted OH, ran my script, and… I get a Celsius temperature printed to the log, and, if I go in Things it shows the parameters as 0, even though if I check the file it is “config_4_1”: 1 . Seems like some kind of bug that whatever is configured in jsondb isn’t properly read .
Can my problem be that I’ve configured everything through the UI and the UI + jsondb is just too buggy still?
At least by looking at the logs through the log viewer I can see my original suspicion that the nodes weren’t communicating correctly was wrong.
Has someone experienced something similar which was resolved by dumping the UI + jsondb completely and configuring all through files in etc? I haven’t tried that, can do it, but just don’t want to spend the time doing it if I don’t have to.
Hi @chris , it seems you are one of the experts in ZWave binding, so Id like to ask you a question in the context of this thread.
I have a thermostat configured (in the hardware) to use Unit Farenheit, I have OpenHab configured to use Imperial units, but somehow when I run the script below and look at zwave binding logs I see Celsius:
Script:
var logger = Java.type('org.slf4j.LoggerFactory').getLogger('org.openhab.rule.' + ctx.ruleUID);
logger.info('thermostat2_sensortemperature');
logger.info(itemRegistry.getItem('thermostat2_sensortemperature').getState());
Okay, so I dug deeper and checked the source code at github and in ZWaveMultiLevelSensorCommandClass.java I see that because I’m getting these log lines I can be 100% sure my Thermostat is sending temperature sensor value in Celsius, even if its screen says it is operating in Fahrenheit:
So I guess this problem is not in anything Openhab, nor is it fixable in Openhab.
I will try to run one of the Thermostats in Celsius and see what the hell happens in Openhab. I’ll report back on what I find out.
I wonder if a firmware update on the Thermostat could fix it, but it seems you can’t do that for a Trane XR524 without buying equipment for Nexia bridge, which I’m not intending to do.
Might have to swap these for another brand/model. Problem is I liked their looks.
So, this is what I found out as I changed the Thermostats to Celsius and then back to Fahrenheit…
When I go to the XR524’s setup and change it’s base unti to Celsius, without changing anything in OpenHAB, like magic it starts to report more frequently or with better granularity. See the Grafana chart below. I flipped it to Celsius close to midnight on 27/Jan. Visible change.
Flipped it later back to Celsius and got granular measures again.
So… I don’t know, but, based on my experience I think the Trane XR524 operates internally in Celsius, and then converts to Fahrenheit with zero decimal point math. That is a plausible explanation why Celsius has such granularity (1 decimal point precision) whilst Fahrenheit doesn’t.
I am going to keep these Thermostats because family is Celsius-enabled, it might even be good for the kids to practice their Celsius, and I like the clean looks.
But if you’re wanting a thermostat for OpenHAB and Fahrenheit only operation, I think Trane XR524 is not for you.
I know this is old, but I am also seeing this behavior and curious if there was a solution.
But I am also posting to contribute to the overall community knowledge.
My thermostat displays 75F
Openhab displays 73.4
zwave logs show this
Sensor Type = Temperature(1), Scale = 0
23 °C [QuantityType]
From standard for Multi sensor
SDS13781-Z-Wave-Application-Command-Class-Specification
4.68.6 Multilevel Sensor Get Command
Scale (2 bits)
This field is used to request a node to report a reading with a particular scale for the actual Sensor Type
Celcius (C) 0x00
Fahrenheit (F) 0x01
logger.debug("NODE {}: Creating new message for command SENSOR_MULTILEVEL_GET", getNode().getNodeId());
ByteArrayOutputStream outputData = new ByteArrayOutputStream();
// Pre v5 does not have a sensortype argument
if (getVersion() >= 5) {
outputData.write(sensorType.getKey());
outputData.write(0); // first scale
}
tldr;
It looks to me, like there has to be, as part of polling a get command issued, which requests a temperature scale to use. It also looks to me that binding openhab uses for the z-wave binding, always issues 0 (C) for the scale to use. Follow ups could include, is F supported as a scale and will scale handling be supported in the binding. Additionally, it is worth investigating if precision is somehow lost. (multilevel sensor report supports precision)
Having same problem, I dug a little deeper. (I am seeing 75 on thermostat and 73.4 in openhab
The payload line helps confirm, the thermostat when sending IS sending in 1 decimal point of precision, and the zwave binding and openhab are processing correctly. It looks to me like when the thermostat itself is set to F but asked (via multisensor v5 protocal) to report in C, it must be doing that math less precise. Perhaps tweaking the binding get to ask for F somehow would help precision for this device… but if this is the only device affected by that it would add some complexity…
Anyway here is the Payload and how it breaks it down, showing the binding is performing the report part the way the thermostat sent.
So I’m not the maintainer, but it looks parameter 4 sets degrees C (0) or Degrees F (1). The Get just uses that.
/**
* Gets a SerialMessage with the SENSOR_MULTILEVEL_SUPPORTED_GET_SCALE command
*
* @return the serial message
*/
public ZWaveCommandClassTransactionPayload getSupportedScaleMessage(SensorType sensorType) {
logger.debug("NODE {}: Creating new message for command SENSOR_MULTILEVEL_SUPPORTED_GET_SCALE",
getNode().getNodeId());
if (getVersion() < 5) {
return null;
}
return new ZWaveCommandClassTransactionPayloadBuilder(getNode().getNodeId(), getCommandClass(),
SENSOR_MULTILEVEL_SUPPORTED_GET_SCALE).withPayload(sensorType.getKey())
.withPriority(TransactionPriority.Config)
.withExpectedResponseCommand(SENSOR_MULTILEVEL_SUPPORTED_SCALE_REPORT).build();
}
The overall conversation for multisensor on the v5 and above flow is significantly more complicated than the v1-v4 flow, so it may be easier said than done You can see the two flows, and the one where scale (in this case 0-C vs 1-F) is sent
The binding code seems greatly simplify the v5+ flow, by following the same conversation pattern as the v1-4 flow, and sending 0 as default scale. (C in this case)
public ZWaveCommandClassTransactionPayload getMessage(SensorType sensorType) {
if (isGetSupported == false) {
logger.debug("NODE {}: Node doesn't support get requests for MULTILEVEL_SENSOR",
this.getNode().getNodeId());
return null;
}
logger.debug("NODE {}: Creating new message for command SENSOR_MULTILEVEL_GET", getNode().getNodeId());
ByteArrayOutputStream outputData = new ByteArrayOutputStream();
// Pre v5 does not have a sensortype argument
if (getVersion() >= 5) {
outputData.write(sensorType.getKey());
outputData.write(0); // first scale
}
There is probably no one size fits all quick fix to the binding.
We also don’t KNOW yet that requesting scale of 1 rather than 0 will help the resolution. I suspect strongly that is the case.
I plan to see if I can compile the binding and test that, but that is a stretch goal for me.
If it works out that it helps resolve the issue… then its time to see if the binding can have the whole multi conversation handled different. But that would also mean the binding would have to have some knowledge about what scale is prefered. (Does openhab save that? does it send that to the binding)
(Perhaps a middle ground like setting a value in karaf the way we do log level…)
OpenHAB has what amounts to Metric or Imperial default for units of measurement. That does include temperature, so some users will have C and others F.
No idea if you access that from binding.
Note that individual Items may have a default unit set, which overrides the system default. How would you deal with that …
I think you might be making a nightmare trying to automate this device setting.
My java reading skills are less than yours, but the command you referenced is for versions that do not support the scale, but the IF reference does seem confusing. There are two multilevel sensor GET messages, one supported, one not. The class code by my eye does seem to have the flow as in your diagram. 0x03, 0x06 for the scale, then 0x01, 0x02 for the report
private static final int MAX_SUPPORTED_VERSION = 10;
private static final int SENSOR_MULTILEVEL_GET = 0x04;
private static final int SENSOR_MULTILEVEL_REPORT = 0x05;
// v5
private static final int SENSOR_MULTILEVEL_SUPPORTED_GET_SENSOR = 0x01;
private static final int SENSOR_MULTILEVEL_SUPPORTED_SENSOR_REPORT = 0x02;
private static final int SENSOR_MULTILEVEL_SUPPORTED_GET_SCALE = 0x03;
private static final int SENSOR_MULTILEVEL_SUPPORTED_SCALE_REPORT = 0x06;
The parameter 4 can be simply changed (for a test) on the UI page for the device. Might want to try that before going through all the other work.
Bob
edit maybe I was wrong on the 06 being the count. In this case maybe it is the report 0x06
edit2: No I think 6 is the count, 05 is the report
The binding just never does the V5 flow. ( I checked the logs of the conversation, so getsupporteded scale is just never called. Just the Sensor Get, and waits for Sensor Report.
So It does a V4 get for V4
And if it is a V5+ sensor, it just adds an extra 0, in order to specify the first scale should be returned on the report.
Added this to see what it looks to me is happening.
We will need @chris to take a look.
I’m also assuming you have looked at your device and OH is IDing it as v5? I did not see that anywhere in the posts
Yes the trane xr524 multi sensor is v5 (I got this from the xml created in /var/lib/openhab/zwave )
And fully agree that when time comes Chris should take a look, any changes there would affect any device that uses multi sensor. But before pressing that, I am want to be able to say that changing the value to 1 will actually report in F at a greater precision that what reporting in C does for this one thermostat.
Reporting back on findings to share with community.
(My goal here was not full automation of all things in house, but rather have a smart thermostat I could access remotely without being connected to some cloud service, but wow has this proven interesting.
I was NOT able to compile the z-wave binding into a jar (my skills are just not that good yet)
I was able to make a change to just one line in the function getMessage, in the class ZWaveMultiLevelSensorCommandClass, and export that class into a Jar. and copy that class into the binding I was already using in the addons directory that I was testing XML updates for this thermostat.
I have confirmed that if we request Fahrenheit, this thermostat will return Fahrenheit. (and interestingly it does so with less reported precision, but it nets out after conversions)
So small victory for me, Openhab will match what my thermostat display has.
Below are logs, breakdowns of the payload for the get and report commands.
Clearly what I did is a hack, and wont work globally for everyone for all multilevel sensor devices, but here is a data point on this thermostat and the bindings implementation for multi level sensor
2022-02-05 12:41:16.369 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 2: Sending REQUEST Message = 01 0B 00 13 02 04 31 04 01 08 25 05 FD
31 04 01 08
31=COMMAND_CLASS_SENSOR_MULTILEVEL
04=SENSOR_MULTILEVEL_GET
01=Air Temperature
08= 00001000 = 000 01 0000 1 = F
2022-02-05 12:41:16.440 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0B 00 04 00 02 05 31 05 01 09 48 83
31 05 01 09 48
31=COMMAND_CLASS_SENSOR_MULTILEVEL
05=SENSOR_MULTILEVEL_REPORT
01=Air Temperature
09= 0000 1001 = 000,01,010 => Precision 0 decimal point, 1 F, 1 bytes
48 = 72 => 72.0
NODE 2: Updating channel state zwave:device:1e1d67f3a4:node2:sensor_temperature to 72 °F [QuantityType]
public ZWaveCommandClassTransactionPayload getMessage(SensorType sensorType) {
if (isGetSupported == false) {
logger.debug("NODE {}: Node doesn't support get requests for MULTILEVEL_SENSOR",
this.getNode().getNodeId());
return null;
}
logger.debug("NODE {}: Creating new message for command SENSOR_MULTILEVEL_GET", getNode().getNodeId());
ByteArrayOutputStream outputData = new ByteArrayOutputStream();
// Pre v5 does not have a sensortype argument
if (getVersion() >= 5) {
outputData.write(sensorType.getKey());
outputData.write(8); // second scale
}
, but it gives a clearer view by grouping things together.
, so I stopped OH, changed it to 1 in both Thermostats, restarted OH, ran my script, and… I get a Celsius temperature printed to the log, and, if I go in Things it shows the parameters as 0, even though if I check the file it is “config_4_1”: 1 
. Seems like some kind of bug that whatever is configured in jsondb isn’t properly read 
.
