@jaminh I now have better access to one of these thermostats and have been playing around with it some more. Thus far, I have not been able to get it to change from “base=1” to “base=0”, do you have any idea what setting might affect that? I’ve looked at all the different options for the thermostat and nothing seemed like an obvious problem.
I actually have more values now, but its still missing the heating one!
<!-- This thermostat's setpoint descriptions are 1 based, not 0 -->
<CommandClass id="67">
<Compatibility>
<Base>0</Base>
</Compatibility>
</CommandClass>
I’m not sure what the base of the command class means, but I guess it makes sense that it wouldn’t work if its only compatible with 0 and my config is set to 1.
Right, I am pretty sure that base setting has to do with whether the indexes are started at 0 or 1. So your thermostat may be reporting the index for heat but home assistant is interpreting it as something else because the index is off by one. I don’t know why you ended up with the wrong value if it is correct in the openzwave config though.
That would make a lot of sense, since the first value I have is 2, which is the cooling entity, but it would be 1 if was base 0 instead of base 1, which would make it the heating entity which I’m looking for.
I tried manually changing the file myself which, unsurprising, got overwritten when I restarted Home Assistant. As far as you know is this strictly a Hass problem or could there be something wrong with the devices? Like they’re reporting something back to Hass incorrectly?
We can see the base value in the file is wrong so I assume the device is fine. If you are changing the file manually you would have to stop Hass first before modifying the file because as you found out Hass writes that file out when it stops the Z-Wave network on shutdown. I don’t think you should have to manually change that file though, I would recommend trying to remove the device, restart Hass, make sure the device has been removed from the file, re-add the device, restart Hass again, then check to see if it has the config correct in the file. If that doesn’t work maybe check to make sure you don’t have the openzwave library installed in multiple places or something, maybe the device config was updated in the wrong place? I would save manually updating the file as a last resort.
Hate to say it, but manually updating the file seems to have worked haha. I tried removing, restarting, re-adding, and restarting but it ended up with the same entities there unfortunately.
I’m not sure if manually updating the config will have any other side affects, but I was at least able to set the target temperature remotely for the heating mode!
If anyone else runs into similar issues, I followed basically what @jaminh said:
For what it’s worth it looks like other people ran into this issue and it sounds like someone else got it to work Honeywell T6 Z-Wave thermostat. That thread also has a much better description of the index issue than I provided.
Interesting, I’ll have a read through that as well. I can always just fall back to this manual edit of the file if need be, it would be nice to have it setup “properly” though, so I’ll give that a shot.
Did you change the zwave config files in the location you referenced “/share/open-zwave/config” or in the openzwave library location (likely something like “/srv/homeassistant/lib/python3.7/site-packages/python_openzwave/ozw_config/”)? I thought I may have remembered people having issues using the config_path setting in the past, could that be the issue?
I didn’t change the config files in the location I referenced and it seems the /src directory is empty, so I’m not sure where else there might be zwave config files. I don’t know for sure that the config_path was working properly to read the config from /share/open-zwave/config but I assumed it was because after I added that it was able to properly name devices that previously we just named “unknown”.
So I found another set of configs in the path /usr/local/lib/python3.7/site-packages/python_openzwave/ozw_config/. I’m thinking about trying something similar to what the person did in the other thread you linked in that folder, removing the config_path from my configuration.yaml and then trying to exclude/include the thermostat again. Only problem is, that directory seems to be only inside the docker container and doesn’t show up in Configurator for whatever reason. So if I want to do that I need to figure out how I’m going to copy the new config in.
The config file for this thermostat is part of OZW 1.4, but is not included with Home Assistant. If you remove your usage of config_path and rely on the files in the docker container, then try to re-include your thermostat, it will show up as “Unknown”.
If your plan is to edit config files, you would want to continue using config_path so you don’t need to copy the files in to the container every upgrade.
If you want to force this behavior permanently, instead of modifying zwcfg*.xml, you can hardcode this into the th6320zw2003.xml config file in your config path, then refresh it from the control panel, or exclude/include. OZW will override the detected values with what is defined in the xml file. You can change the base number, and/or force the setpoint values. Here is an example (there are several): https://github.com/OpenZWave/open-zwave/blob/3d6374c831998595744cc34ef862a80ee51973c9/config/thermofloor/heatit056.xml#L27
OpenZwave was updated to version 1.6 which included a change to the format of the config files. HomeAssistant still requires version 1.4, so if you are pulling config files from the OpenZwave you have to use the 1.4 branch (https://github.com/OpenZWave/open-zwave/tree/1.4/config).
@jaminh that was it, problem solved! The open zwave config that I pulled down originally was from master and so was the 1.6 version but I needed the 1.4 version. After excluding, restarting, including and restarting with the 1.4 version of the config setup it is indeed working as expected
