Would this be manufacture specific extensions? The install guide definitely has AWAY as supported.
I will reach out to Honeywell support
No - this is standard.
Maybe there are different firmware versions of this device - that’s no uncommon - make sure you have the manual for your firmware version.
@chris
I’m getting very little help from Honeywell. They keep telling me to go to my installer.
Reading the install manual, I notice that it does not refer to “Away” as a mode, rather as a schedule “Period”
Perhaps “Away” is not a mode but part of some z-wave schedule api?
Honeywell/Resideo WILL NOT provide any direct homeowner support for this thermostat. They will only refer you to a “Pro Installer”. Most Pro Installers have no interest is servicing or supporting a single residential thermostat. I found ONE HVAC contractor that is a “Pro Installer” that offered to research this for me and was actually quite open to helping. I found one other HVAC contractor that while not a “Pro Installer”, offered to try to get me the Honeywell Z-Wave reference.
This thermostat is quite full featured and has full local control. I really did not want to go with a Nest or Ecobee. I hope that I can get this last “Away” Schedule period trigger resolved, then I will feel I have implemented a good solution.
I will update this thread with my experience.
1 Like
Something I learned today
My HVAC contractor came by and we were discussing my Thermostat.
We tried setting the Thermostat mode in OH web UI to “Economy Heat”
That set the Thermostat display to
- Period Away
- Cool setpoint to the value configured in the thermostat for AWAY
- Heat setpoint to the value configured in the thermostat for AWAY
- Mode to Heat
- Auto changeover set to not enabled
We tried setting the Thermostat mode in OH web UI to “Economy Cool”
That set the Thermostat display to
- Period Away
- Cool setpoint to the value configured in the thermostat for AWAY
- Heat setpoint to the value configured in the thermostat for AWAY
- Mode to Cool
- Auto changeover set to not enabled
We tried setting the Thermostat mode in OH web UI to “Auto”
That set the Thermostat display to
- Period Home (This is during the configured HOME period)
- Cool setpoint to the value configured in the thermostat for HOME
- Heat setpoint to the value configured in the thermostat for HOME
- Mode was not changed from the previous value
- Auto changeover set to enabled
My HVAC contractor opined that this is in line on how the commercial Honeywell systems work. According to him, the commercial systems presence setup do not have upper/lower setpoints with auto changeover for when occupancy is configured for empty. There is either HEAT or Cool mode and the setpoint for that mode.
I did not like that answer but it matched the observed behavior.
Interesting items in the manual.
- Connecting this to Z-wave network turns off programing of the thermostat (let the controller program…not the local program)
- There may be a way to enable that further in a menu item
- Home/Away (Energy Saving) Looks to me like “Away” is ESM or energy saving mode, possible that is some config parameter rather than a command. (I have not checked if there are any specs on all of the config parameters.)
Or those are the “Away” modes energy saving
You can re-enable on thermostat scheduling after connecting to zwave.
There is no “Away” mode, just the “HEAT_ECON” and “COOL_ECON” modes with NO “AUTO_ECON” mode 
. These modes display as “AWAY” on the thermostat and use the “AWAY” set points for the single mode “ECON” modes.
That there is no econ upper and lower setpoints in an AWAY mode is the only real drawback.
I successfully used the GPSTracker Binding and the OwnTracks app on my phone to define a geofence and switch between AUTO and HEAT_ECON modes where AUTO follows the schedule I programed into the thermostat schedule. I have not bothered to make the rule smart enough to choose between HEAT_ECON and COOL_ECON
If you think that is a STUPID restriction, I agree. But I already bought it. At least it has NO cloud connection.
Ahhh I see your use case. Needed when there could be large temp swings while away.
I hit this thread because I was thinking about switching from the trane xr524 (long story about multisensor v 5) and thought maybe I could be helpful, seem not.
(and in general I dont think this thermostat is for me)
Btw, really interesting solution you came up with regarding geofencing. Nice
Hello,
I’m not sure if my issues with the " Honeywell TH6320ZW T6 Pro Z-Wave" are related to this discussion. I’m using this thermostat without any problems since 2 years in OH. Last week I’ve updated from OH 3.1.0 to OH 3.2.0 (via official docker image) and the thermostat does not longer work in OH. My thing is shown status online, but I can’t use any item/channel (I’ve configured everything via files).
After digging around, I’ve tried to do a new additional Z-Wave scan and I found my thermostat with the same nodeId in the inbox with the hint “Unknown Device: Z-Wave Node 026 (0039:0011:0008:1.3)”, so I can’t see any channels etc.
My things file entry is:
Thing honeywell_th6320zw_00_000 tkitc_thermostat "Thermostat Kitchen: node26" @ "kitchen" [ node_id=26 ]
My item file entries are:
Number:Temperature aKITC_Thermostat_Setpoint_Cooling_Temp "Thermostat Kitchen Setpoint Cooling Temperature" <temperature> {channel="zwave:honeywell_th6
320zw_00_000:myzwave:tkitc_thermostat:thermostat_setpoint_cooling"}
Number:Temperature aKITC_Thermostat_Setpoint_Heating_Temp "Thermostat Kitchen Setpoint Heating Temperature" <temperature> {channel="zwave:honeywell_th6
320zw_00_000:myzwave:tkitc_thermostat:thermostat_setpoint_heating"}
Number aKITC_Thermostat_Mode_Value "Thermostat Kitchen Mode Value" <temperature> {channel="zwave:honeywell_th6320zw_00_000:myzwave:tkitc_thermostat:the
rmostat_mode"}
Number aKITC_Thermostat_FanMode_Value "Thermostat Kitchen FanMode Value" <temperature> {channel="zwave:honeywell_th6320zw_00_000:myzwave:tkitc_thermost
at:thermostat_fanmode"}
Number:Temperature vKITC_Thermostat_Current_Temp "Thermostat Kitchen Current Temperature" <temperature> {channel="zwave:honeywell_th6320zw_00_000:myzwa
ve:tkitc_thermostat:sensor_temperature"}
Number vKITC_Thermostat_Current_Humidity "Thermostat Kitchen Current Humidity" <temperature> {channel="zwave:honeywell_th6320zw_00_000:myzwave:tkitc_th
ermostat:sensor_relhumidity"}
Number vKITC_Thermostat_Operating_State_Value "Thermostat Kitchen Operating State Value" <temperature> {channel="zwave:honeywell_th6320zw_00_000:myzwav
e:tkitc_thermostat:thermostat_state"}
Number vKITC_Thermostat_Fan_State_Value "Thermostat Kitchen Fan State Value" <temperature> {channel="zwave:honeywell_th6320zw_00_000:myzwave:tkitc_ther
mostat:thermostat_fanstate"}
Number vKITC_Thermostat_Battery "Battery Thermostat Kitchen" <battery> (gBattery) {channel="zwave:honeywell_th6320zw_00_000:myzwave:tkitc_thermostat:battery-level"}
Is it an issue of OH 3.2? Or does my thermostat behave wrong?
Thanks,
Frank
Ok, thanks! But does this belong only to OH 3.3 snapshot build? Is it possible that these problems also occur on OH 3.2? I ask, because all my (>50) other Z-Wave devices are working without any problems after updating from 3.1 to 3.2.
Also the status in the thing basic web view shows “online”!
I think it was determined that the issue may have been present in OH 3.2
I’m currently running 3.3 M1
ok, thank again. I will follow the other discussion from now on. Very interesting to read about is validation issues…
Also likely is that the device was missing from the database at the time 3.2.0 was put together (based on the last approval date in the DB). Once a device is modified it is removed from the binding until approved, then it is back. Use the latest snapshot with your 3.2 setup. See if that works.
Bob
1 Like
I found the following information at open smarthouse about the thermostat:
Last Approval 2021-12-20 18:54:08 OH-SNAPSHOT
But anyway, I will try what you’ve suggested. Just to make sure how to do it, because I’ve never changed an included bundle in OH (I think I should not try to change something on the filesystem level. Instead I should use the OH client console!?)
I found in the client console the following entry:
287 │ Active │ 80 │ 3.2.0 │ openHAB Add-ons :: Bundles :: ZWave Binding
Do in need to do a bundle:uninstall and a bundle:install with the new version? Or is something like bundle:update and/or bundle:refresh required?
I already have downloaded the new jar file org.openhab.binding.zwave-3.3.0-SNAPSHOT.jar and placed it on a location where the OH process inside the docker container can access it.
Probably the easiest to try is the bundle:uninstall but I have not tried that before. Also using the UI to uninstall the binding should work. Then drop the new binding in the addons folder. Wait 30 seconds and pray. With the Rpi I need to add feature:install openhab-transport-serial, but I understand that may not be required with docker.
Bob
Ok, I solved it. I’ve stopped the 3.2.0 bundle via CLI and installed and started the 3.3.0-SNAPSHOT bundled via CLI. After a restart of the OH docker container the the new bundle is active and the problems are gone 
The old bundle is still in the bundle:list with the status Resolved but not longer with status Active - I think I can leave it like that.
Thanks a lot for your help!
Frank
Glad it worked. The key was the date. 3.2.0 release was right around mid-December. A DB entry can be in the modified state for a day or several days depending on how busy Chris is.
Bob
Ok, thanks for the explanation. Now I know what to if such problems may occur in future versions again.
The OH community is doing such a great job! Thanks to all!