Honeywell T6 Pro Z-Wave Programmable Thermostat (TH6320ZW2003)

I’m trying to Implement Home/Away switching
The channels available seem incomplete

There is no channel that reports/sets Home/Sleep/Away mode. Thermostat mode for “Auto” is “3”, not mapped to a text value.

When I look at
I see that the thermostat is listed twice dated 2017-09-20
and dated 2018-04-13

The later entry seems to have more features.
Could the Z-Wave database OH uses need to be updated?

It is possible but could require advice from @chris . I noticed both listings in the alliance use 0011:0008 and that is also the ID of the entry in the database (so must be the one you are currently using). I think the concern could be that older device does not have the channel, so could mess things up for some. It also seems both use the same zwave 6.71.01 version (if I’m reading correctly) There has to be some way to identify the difference.

On a separate (I have a different device), but related comment. I created a House Mode item (Normal, Vacation, Party, Weekday Holiday, etc.) and with Cron wrote rules on how I wanted the thermostat to run in each mode.


are basically scenes. These are not reported by the thermostat. You define when one of these scenarios is the current one, depending on various information, e.g. time of day, presence status etc. And accordingly the thermostat needs to be told what it needs to do to match the scenario.

You have 4 setpoints in your device according to the sceenshot. These are basically predefined scene settings. In my case I have only two setpoints that I can configure. One for heating and one for a lower setting, e.g. to reduce the temperature during the night. There is a “furnace” setting as well, but it is not a setpoint that can be used for a longer time rather than a valve opening of 100% for a short period of time (it is a fixed setting in the firmware of the thermostat, if set to use it, it falls back to “heating” after a few minutes). And there is a setting to prevent frozen pipes. So basically I have four setpoints as well, logically. With “thermostat mode” I select which of the setpoints is currently the relevant one. When I am present it is “heating mode”, so setpoint heating defines the temperature I want to have in my room. If I am absent it is the mode I set for the freeze prevention etc.
In essence I determine the scene (leaving the premises, coming back, time of day etc.) and set the thermostat mode accordingly.

@stefan.oh @apella12
I COULD configure the Thermostat to be completely controlled from OH… but that would be hard.

What I want is to configure the schedule, and set the Away/Home/Sleep setpoints in the Thermostat and trigger Away from a presence trigger in OH.


This seems to imply that my desired use case is supported

This seems to imply there should be a “Away/Home/Sleep channel”

Z-Wave controllers from various manufacturers may or may not support the Z-Wave
Thermostat General V2 Device class used by the T6 pro Z-Wave Thermostat. If
your controller does not support full thermostat device class functions,

What are your thoughts?

Oh come on !! I’ve seen a number of posts from you, you are not a noob. You do it once in a rules files or once on the device, plus then you are not limited to three. Anyway whatever. Good luck


The term “thermostat” seems to have different meanings, depending on ones location. Here it is basically something you put onto a heating valve in order to control the flow of hot water into a radiator. Your device is something totally different. I was not aware of this. My apologies, my answer does not fit.

I have added AWAY and AUTO as options, so this should be displayed ok once this flows through.

1 Like

This should allow me to configure OH exactly how i want. Manage presence and temp override a setpoint. The Thermostat will manage the schedule and setpoints.

OH 3.2 is now frozen, I presume it will be in the next OH 3.3 snapshot?

I don’t know that I understand “exactly what you want” so I can’t say. It will allow you to set the mode to AWAY or AUTO - I don’t know what this does in the thermostat.

I will try and do one last update of the database.

@chris I updated my OH first to 3.2 release and my Thermostat had no channels, I updated to the 3.3 snapshot and It’s still the same.

Is there a problem with my OH update?

src/main/resources/OH-INF/thing/honeywell/th6320zw_0_0.xml was deleted in PR 1702 Database update by cdjackson · Pull Request #1702 · openhab/org.openhab.binding.zwave · GitHub

It didn’t get included in the last update so will be in the next snapshot tonight or tomorrow.

@chris The latest snapshot has the updates

I then tested by sending mode updates thru the Menu UI
I tested changing Thermostat mode by cycling through

  1. Auto to Heat
  2. Heat to Cool
  3. Cool to Auto

The Thermostat showed exactly what I expected with the setpoint and mode updating on the Thermostat display set point, mode, and “Auto Change On” for Auto mode

I then tried to set the Mode to Away

There was no change. Here is the debug log.

events.log (214.4 KB)

In the log I see this

2021-12-21 09:40:41.223 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Command received zwave:device:a9db510670:node9:thermostat_mode --> 13 [DecimalType]
2021-12-21 09:40:41.224 [DEBUG] [lass.ZWaveThermostatModeCommandClass] - NODE 9: setValueMessage 13, modeType empty false
2021-12-21 09:40:41.224 [ERROR] [lass.ZWaveThermostatModeCommandClass] - NODE 9: Unsupported mode type 13
2021-12-21 09:40:41.224 [WARN ] [nverter.ZWaveThermostatModeConverter] - NODE 9: Generating message failed for command class = COMMAND_CLASS_THERMOSTAT_MODE, endpoint = 0
2021-12-21 09:40:41.225 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: No messages returned from converter

The Honeywell install guide says that “Away mode” is triggered by the z-wave controller.
What are your thoughts?

The Thing config
Schedule Type is “1” (Single schedule)
Auto Changeover is “1” (manual states this is On/Off. I presume “1” is On)

When the binding interviews the device, it reads out the list of modes supported by the device. What we see here is a statement that the binding thinks that mode 13 (AWAY) is not supported by the device. Can you post the XML file for this device (it’s in the userdata/zwave/xxx folder - where xxx is the controller name).

network_dd8d87c1__node_9.xml (14.2 KB)



Yep. So, I would suggest the following.

  1. Stop OH - or at least stop the ZWave binding.
  2. Edit the XML to add AWAY to the list
  3. Restart and try to send the AWAY command.

This should remove the “unsupported” error that you had, and the binding will try and send the command to the device and we can see what happens.

Sending the command

                           _   _     _     ____
   ___   ___   ___   ___  | | | |   / \   | __ )
  / _ \ / _ \ / _ \ / _ \ | |_| |  / _ \  |  _ \
 | (_) | (_) |  __/| | | ||  _  | / ___ \ | |_) )
  \___/|  __/ \___/|_| |_||_| |_|/_/   \_\|____/
       |_|       3.3.0-SNAPSHOT - Build #2652

Use '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
To exit, use '<ctrl-d>' or 'logout'.

openhab> openhab:send Thermostat_Thermostatmode 13
Command has been sent successfully.

Nothing happens on the Thermostat display

Event Log

2021-12-21 13:33:07.741 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Thermostat_Thermostatmode' received command 13
2021-12-21 13:33:07.745 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Thermostat_Thermostatmode' predicted to become 13
2021-12-21 13:33:07.752 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_Thermostatmode' changed from 3 to 13
2021-12-21 13:33:09.393 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Thermostat_Thermostatmode' changed from 13 to 3

The thermostat resets itself back to Auto

No messages in the openhab.log

Set zwave loging to debug and tried again

openhab.log (164.3 KB)

That was noisy

Thanks, I think this confirms that the device doesn’t support the AWAY mode -:

  • It doesn’t report this mode as part of the interview
  • When the binding commands this mode, and then reads the mode back, it has not been set, but reported back as mode 3 (which is AUTO).