First I wanted to say thanks for all the input and work everyone has done. I was wanting a new thermostat and not a wi-fi one. The Gocontrol GC-TBZ48 is quite cheap in comparison and works perfectly after following the setup described here with one exception. I wanted to detail that exception for other users. I am running a raspberry pi setup and I had to add the tbz48.xml and update the manufacturer_specific.xml under the .homeassistant/python-openzwave/openzwave/config directory instead of the one detailed above. Again, thanks for all the work.
I know this is kind of an old topic but It looks like the official config for this thermostat is still not in the open-zwave mainlines. I have not updated open-zwave in a while. Is this configuration still needed? If so does it make send to have it supported in open-zwave officially?
Itās the first search result for āzwave thermostatā on amazon. Iād think itās got to be a pretty popular item.
Just closing the loop on this one. It looks like a proper configuration was added to the OpenZWave repo in June: https://github.com/OpenZWave/open-zwave/blob/master/config/linear/GC-TBZ48.xml
This config seems to expose a number of useful configuration parameters for the thermostat, and remove the extraneous interfaces (like āAway/Econ Coolingā). I donāt think this is yet available in the version of openzwave that ships with HomeAssistant, but should be soon. Iām using the development branch (for Secure Barrier supportā¦) and the new config is working beautifully.
If we currently have manual edits to the xml files will the future version automatically update these? Just curious
Feel like Iām late to the game here guysā¦ Anyways, just got one of these GC-TBZ48ās working with HA 57.2. Tried following the instructions on this post, but OZWCP isnāt being used in current versions of HA (I could be wrong here, thatās just what Iāve heard, since zwave is now built-into HA). Anyways hereās how I did it, in case anyone needs it in the future.
With HA runningā¦
Remove the thermostat, via the UI, configuration -> zwave -> remove node
On the thermostat, menu -> zwave -> remove (or delete)
Complete stop HA. This depends on how you have it running, but I completely stopped the service, and verified it was stopped, with: ps -ef |grep hass
From the command line: sudo su - [home-assistant user] (āhassā in my case)
cd to your main config directory, wherever that is.
cd to: deps/lib/python3.5/site-packages/python_openzwave/ozw_config/
Follow @DGAzrās instructions above.
vi manufacturer_specific.xml
under:
<Manufacturer id="014f" name="Linear">
add this line:
<Product type="5442" id="5436" name="TBZ48" config="linear/TBZ48.xml"/>
:wq (save and quit the file)
Create the TBZ48.xml file:
cp remotec/zts-110.xml linear/TBZ48.xml
log out of the home-assistant user account (just type āexitā)
Start home-assistant
Once again, Iāve got it running as a service, so yours might be different:
sudo service home-assistant start
Re-add the thermostat, via the zwave UI in HA:
configuration -> zwave -> add node
On the thermostat:
menu -> zwave -> install (I think)
Should say ādoneā when itās added.
Go back to āOverviewā in the UI, hopefully find your āclimateā card, and 4 entries
Hereās my main heating item:
āLinear TBZ48 Heating 1ā
But you should have 3 others, Linear TBZ48 Cooling 1, Linear TBZ48 Cooling Econ, Linear TBZ48 Heating Econ.
Take off your jacket, and select āLinear TBZ48 Heating 1ā, and adjust that temp!
Side note: Your type=ā5442ā id=ā5436ā might vary, a bit, but this was mine as of 11/11/17.
Anyways, hope this helps someone! Cheers
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/*
.
core-ssh:/config# pwd
/config
core-ssh:/config# ls
OZW_Log.txt custom_components groups.yaml options.xml scripts.yaml zwcfg_0xf6d8e866.xml
automations.yaml customize.yaml home-assistant.log pyozw.sqlite secrets.yaml zwscene.xml
configuration.yaml deps home-assistant_v2.db scenes.yaml tts
core-ssh:/config# ls deps/lib/python3.6/site-packages/*
deps/lib/python3.6/site-packages/nanoleaf:
__init__.py __pycache__ aurora.py setup.py
deps/lib/python3.6/site-packages/nanoleaf-0.4.0.dist-info:
DESCRIPTION.rst INSTALLER METADATA RECORD WHEEL metadata.json top_level.txt
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.