Does anyone know how to find the same configuration files in Hass.io?
I do not have the same directory structures; I cannot find */python_openzwave/ozw_config/*.
Any update on this? I’m looking to move to hass.io (currently stuck back on a Python 3.4 AIO), but I use the GC-TBZ48 thermostats and want to ensure I can get them working again in hass.io
I had the same problem with the GC-TBZ48, but solved it a different way. Originally, it had extra climate controls (eco, away, etc) that didn’t do anything. The cool worked, but I was unable to change the heat. I modified the above request because I use docker, and using the above links prevented control of things like the fan and temperature sensor.
I stopped hass. In the hass config folder, I edited the zwcfg_xxx.xml file. Searched for the node block that contained the “linear” manufacture. I deleted all the items between the “<CommandClasses>” and “</CommandClasses>” block. I then replaced it with a mixture of the above linked zwcfg and the above linked. Gist https://gist.github.com/watermark/0127bc4758a696508aeeecd760185b9d. After making those changes, I had full control over the cool, heat, mode, fan speed, and had the temperature sensor. I’d imagine some of the items in my gist are specific to my setup, so it may be best to only use the command classes.
I figured I would share my experience with this thermostat. I found one for sale locally for $40 in a sealed box so figured I would see how it works.
I first tried setting it up on battery power and not even connecting it to my HVAC system. I couldn’t get the two to talk reliably. It seemed changes made locally were pushed to HA but not the other way around. I tried hooking it up to see if that improved things but no dice.
Fast forward two weeks and I am re-running the wire from my HVAC to the thermostat and re-wire it to utilize the C wire (now the thermostat is powered). Figured while everything was in pieces I would try this thermostat again.
It works great once powered. Changes made show up quickly at the thermostat and as of this AM my ‘away mode’ automation worked. Given that the code is very similar to the AM automation I assume my PM automation should start warming the house back up before we get home.
One thing I haven’t gotten my head around is why are there two separate climate entities for heat and cool?
Why is a good question, but from what I have heard the only time you need to use the other one is when setting both temperatures for auto mode. So if the operation mode is set to auto you will only be able to adjust the auto range by setting the heat on the heat climate and the cool on the cool climate.
I am hoping at some point either I or someone else modifies HomeAssistant to use the operation_mode to set the set point and only expose one entity for the thermostat set point.
Maybe both setpoints on one scale similar to a nest just a high and a low setpoint with the current temp in the middle and current setpoint when you’ve got it grabbed with the mouse.
Setting the temperature on the cool instance will set the cool temperature even when on heat mode. It is the opposite when on the heat instance. I can’t get an instance to set the temperature depending on the active mode.
Same here, just noticed it recently as I was setting up some winter heating automations.
I am not using Lovelace yet, but I bet the thermostat entity in the ui can be swapped in/out based on operation mode so it could kinda be hidden that there are two. Still doesn’t help with automations though.
Yes, I think you can achieve this in Lovelace using the entity-filter card, I might just do that for simplicity and remove the Auto mode as you would have to show the 2 entities to control both temperatures.
Another issue I’ve found, if anyone has a solution, I’d love to hear it.
I have the temperature setting 5 degrees up/down when no one is home. Based on other automatons, I have the temperature setting back to a comfortable temp when we are heading home. The problem I’m hitting is that the thermometer is using aux heat to get the temperature back up instead of using the heatpump (because of the temp difference). Aux heat is more expensive to use than the heat pump, and should only turn on when it’s so cold outside that the heatpump cannot keep up. A normal programmable thermostat that works off a basic timer has a “recovery” mode to set the temp back to comfortable, and does not use aux heat to do so.
The only thing I can see to fix this is to use automatons to slowly step up the temp, or to set the aux heat threshold higher on the thermometer (in advanced settings). Setting the aux heat threshold isn’t ideal because when it get’s really cold, aux heat will take much longer to kick in making my house cold. Slowly stepping up the temperature complicates the automation significantly. To my knowledge, I do not believe there is a way to set the aux heat threshold via zwave, which might have also been a possible solution if this was possible.
Hey guys! As you may be aware… the GC-TBZ48 thermostat creates 2 separate entities, one for cool and one for heat… I couldn’t stand having two separate cards to control one thermostat so I created a custom Lovelace card based on the native card that allows you to control both the heat and cool entity on the same card!
Amazing. I will set this up later tonight hopefully. My current setup is using conditional cards to show/hide two different thermostat cards based on the operation mode. This is waaaay better! Thanks for all the hard work.
Not sure if this would be something that ever gets merged in to the base product considering it seems to be pretty specific, but maybe there are other thermostats with the same problem? But if that were the case I think it would be even more important for this to get fixed in openzwave. Until then, this is a great solution! Thanks so much.
Not sure how many thermostats have this “issue” which I’m not real sure that it is really an issue as having two separate entities allows you to set up a range in the Auto mode, so I don’t think this needs to be fixed on openzwave. Let know how the installation works out for you!
Still think while it’s operation mode set to “heat” only the heating entity should be controlled, and vice versa for cooling. Shouldn’t really affect the auto mode.
I agree that it might not be considered an issue, but when using this thermostat with Wink I was provided one entity to interact with. Now this was abstracted via the Wink API, but it was easy. If the thermostat was set to auto, it functioned like your card. If set to heat it only adjusted the heat set point. If cool just adjust the cool set point. It would be nice if openzwave provided that same abstraction.