Honeywell T6 Pro Z-Wave Programmable Thermostat (TH6320ZW2003)

smitopher · December 15, 2021, 5:40pm

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 https://products.z-wavealliance.org/
I see that the thermostat is listed twice
https://products.z-wavealliance.org/products/2583 dated 2017-09-20
and
https://products.z-wavealliance.org/products/2893 dated 2018-04-13

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

apella12 · December 15, 2021, 9:03pm

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.

Bob

stefan.oh · December 15, 2021, 10:50pm

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.

smitopher · December 15, 2021, 11:40pm

@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.

smitopher · December 15, 2021, 11:54pm

From

This seems to imply that my desired use case is supported

smitopher · December 16, 2021, 12:02am

@chris
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?

apella12 · December 16, 2021, 12:57am

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

Bob

stefan.oh · December 16, 2021, 8:30pm

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.

chris · December 18, 2021, 6:15pm

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

smitopher · December 18, 2021, 6:31pm

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?

chris · December 18, 2021, 6:36pm

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.

smitopher · December 20, 2021, 6:39pm

@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

chris · December 20, 2021, 6:58pm

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

smitopher · December 21, 2021, 4:19pm

@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

Auto to Heat
Heat to Cool
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?

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

chris · December 21, 2021, 5:57pm

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).

smitopher · December 21, 2021, 6:25pm

@chris
network_dd8d87c1__node_9.xml (14.2 KB)

interesting

            <COMMAND__CLASS__THERMOSTAT__MODE>
              <version>1</version>
              <instances>1</instances>
              <control>false</control>
              <versionSupported>3</versionSupported>
              <modeTypes>
                <modeType>OFF</modeType>
                <modeType>HEAT</modeType>
                <modeType>COOL</modeType>
                <modeType>AUTO</modeType>
                <modeType>AUX_HEAT</modeType>
                <modeType>HEAT_ECON</modeType>
                <modeType>COOL_ECON</modeType>
              </modeTypes>
              <isGetSupported>true</isGetSupported>
            </COMMAND__CLASS__THERMOSTAT__MODE>

chris · December 21, 2021, 6:31pm

Yep. So, I would suggest the following.

Stop OH - or at least stop the ZWave binding.
Edit the XML to add AWAY to the list
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.

smitopher · December 21, 2021, 7:38pm

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.
openhab>

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

smitopher · December 21, 2021, 7:45pm

Set zwave loging to debug and tried again

openhab.log (164.3 KB)

That was noisy

chris · December 21, 2021, 8:55pm

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).