GC-TBZ48 thermostat remote sensor setpoint

Hardware Home Automation
,
1

I have a GoControl GC-TBZ48 Thermostat that generally works well. I was looking at the “thing configuration parameters” and noticed parameters 43/46 which allow for a remote sensor node/temperature to be set. I’ve always been curious about using multiple sensors to read temperatures around the house and this seems like it’ll be a good way to integrate it.

Being that its just 1 node value that it allows and I may have multiple, and the other sensors aren’t going to be zwave but most likely zigbee/matter devices, it wont quite work using the node id value. I see that it might be possible to set thing parameters from a rule (will take average for example) using the rest endpoint (seems kinda ugly). Is there a newer/better way to do this? Is it frowned upon to constantly update parameter values? Here’s the AI remote regarding the sensor setpoint:

GoControl GC-TBZ48 Remote Sensor Configuration
The GC-TBZ48 supports using an external remote temperature sensor by configuring two key Z-Wave parameters:

  • Parameter 43: Remote Sensor 1 Node Number
    Set this to 1 to enable the use of a remote temperature sensor. This tells the thermostat to expect temperature data from a specific device on the network.

  • Parameter 46: Remote Sensor 1 Temperature
    This parameter receives the actual temperature value from the remote sensor. To keep the thermostat using the remote temperature instead of its internal sensor, you must update this value at least once every 5 minutes. If not updated, the thermostat reverts to using its internal temperature reading.

Note: This feature is not documented in the official user manual but is confirmed functional in smart home platforms like Home Assistant (via Z-Wave JS) and Hubitat. Automation scripts can be used to send the average temperature from multiple sensors (e.g., a whole-home average) to Parameter 46.

2

Really Parameter 46 should be exposed as a Channel, not a parameter. I think this only requires a change to the zwave devices database to make happen. That’s the correct long term solution.

In JS Scripting

things.getThing('uid:of:thing').setProperty('name', 'value');

I imagine you can find the name of the parameter from the code tab of the Thing. You may need to set it to something first though.

That’s not really what parameters are for, and it’s kind of weird that something like this would be exposed as a parameter. 43 makes sense as a parameter but 46 should be a Channel linked to an Item.

One real downside I can think of is every time you update the parameter it’s going to cause OH to write out the JSONDB. Which in this case means it will be written out every five minute which will pretty much destroy any utility you’d get out of the automated backups of the JSONDB.

I don’t know if updating a Thing’s parameter like this causes it to briefly go offline and reset itself. That will be something to look out for.

3

I’m almost sure that when a parameter is exposed as a channel with the zw binding, that the UI page parameters are not affected (They will be stale). However, don’t really have a set-up to test ATM. I also don’t have any knowledge of JSONDB effect. However, if you manage to actually change the parameter on the UI page, it will go briefly offline and change the JSONDB.

4

thanks, i’ll try this out over the week. i’m gonna be struggling over some ikea matter devices i got last week with my new sonoff mg24 (not going well so far)