[DEPRECATED] Enhanced GoControl GC-TBZ48 Z-Wave Thermostat Driver

🚧 Developers
81

Assuming that is the case overall... I'll believe it when I can reproduce it. I don't doubt you are seeing that on your device, don't get me wrong. I just don't know if it is a device-wide problem, or something specific to your thermostat. Like I said, it isn't even supposed to send config param 21 and 22 reports by default.... :man_shrugging:

In the many hours of testing I've done on this thermostat, I've never seen it not send a report when I was expecting it to... BUT, I also don't put my fan in/out of auto/on normally either. I did when I tested the driver, but never have since then.

Yes, if the normal thermostat reports don't always send when they should, then I will use the config reports to augment it. Not a hard change - other than making sure I don't get duplicate events since now I'm looking for updates in two different reports.

At a minimum it would be trivial to dump the mechanical status and SCP to state variables.

82

I was starting to wonder that myself. To implement the remote sensor, I regularly update the calibration value of the temperature sensor, maybe I will try stopping that and see if that helps...

83

I doubt that's it. I update the SensorCal every minute on 3 of 4 thermostats.

Well, I used to do it 1/minute, but I recently changed my app to only update it on temperature sensor change.

We'll figure it out!

84

I updated the driver to dump the reports into a state variable.

I'm not in front of my thermostat, though, so I can't tell for sure if those report values are a bit map or individual states. If a bit map, then a number will show up in the variable instead of text. If that happens, let me know and I'll fix that later too.

85

Missing two braces for switch statements... I get these error but I have to run for now...

dev:4492020-01-16 15:04:16.014 debugIn parse, error in zwave.parse. Description = 'zw device: 0D, command: 7006, payload: 16 01 91 , isMulticast: false'. Error = 'groovy.lang.MissingMethodException: No signature of method: user_driver_Botched1_Enhanced_GoControl_GC_TBZ48_513.updateDataValue() is applicable for argument types: (java.lang.String, java.lang.Integer) values: [scpStatus, -111]'.
dev:4492020-01-16 15:04:16.004 debug---CONFIGURATION REPORT V1--- Thermostat sent parameterNumber:22, size:1, value:-111
dev:4492020-01-16 15:04:16.002 debugParsing 'zw device: 0D, command: 7006, payload: 16 01 91 , isMulticast: false'
dev:4492020-01-16 15:04:16.000 debugParse...START
dev:4492020-01-16 15:04:15.107 debugIn parse, error in zwave.parse. Description = 'zw device: 0D, command: 7006, payload: 15 02 00 21 , isMulticast: false'. Error = 'groovy.lang.MissingMethodException: No signature of method: user_driver_Botched1_Enhanced_GoControl_GC_TBZ48_513.updateDataValue() is applicable for argument types: (java.lang.String, java.lang.Integer) values: [mechanicalStatus, 33]'.
dev:4492020-01-16 15:04:15.088 debug---CONFIGURATION REPORT V1--- Thermostat sent parameterNumber:21, size:2, value:33
dev:4492020-01-16 15:04:15.011 debugParsing 'zw device: 0D, command: 7006, payload: 15 02 00 21 , isMulticast: false'
86

OK, I should have that fixed.

And it obviously is a bit map, so I hopefully fixed that too in v1.6.0c.

87

I can now see it in device details data :smile:, made a couple changes: changed left shift values from 1..9 to 0..8 and commented out two line trowing errors, not very familiar with this language yet...

    if (cmd.parameterNumber == 21) {
def mechStatus = ""
if ((config & (1L << 0)) != 0) {mechStatus += "MECH_H1,"}
if ((config & (1L << 1)) != 0) {mechStatus += "MECH_H2,"}
if ((config & (1L << 2)) != 0) {mechStatus += "MECH_H3,"}
if ((config & (1L << 3)) != 0) {mechStatus += "MECH_C1,"}
if ((config & (1L << 4)) != 0) {mechStatus += "MECH_C2,"}
if ((config & (1L << 5)) != 0) {mechStatus += "PHANTOM_F,"}
if ((config & (1L << 6)) != 0) {mechStatus += "MECH_F,"}
if ((config & (1L << 7)) != 0) {mechStatus += "MANUAL_F,"}
if ((config & (1L << 8)) != 0) {mechStatus += "reserved,"}
//mechStatus = mechStatus[0..-1]
updateDataValue("mechanicalStatus", mechStatus)
}

if (cmd.parameterNumber == 22) {
def scp = ""
if ((config & (1L << 0)) != 0) {scp += "STATE_HEAT,"}
if ((config & (1L << 1)) != 0) {scp += "STATE_COOL,"}
if ((config & (1L << 2)) != 0) {scp += "STATE_2ND,"}
if ((config & (1L << 3)) != 0) {scp += "STATE_3RD,"}
if ((config & (1L << 4)) != 0) {scp += "STATE_FAN,"}
if ((config & (1L << 5)) != 0) {scp += "STATE_LAST,"}
if ((config & (1L << 6)) != 0) {scp += "STATE_MOT,"}
if ((config & (1L << 7)) != 0) {scp += "STATE_MRT,"}
//scp = scp[0..-1]
updateDataValue("scpStatus", scp)
88

@JasonJoel, I think @christi999 is seeing the same thing I sent you that pull request on GitHub about with regards to fan state and operating state. I think there needs to be an extra call to the Thermostat to get the status back early as it doesn't report it on it's own.

89

Maybe I'll go back and look at what you said... I am still not "getting it" I guess. I have tried 20 different things so far since getting home and I can never get things out of sync/incorrect on mine.

My fan state always shows running when running, idle when idle... So I'm missing something somewhere.

My logs... Every time... on, running, auto, idle, :

12%20PM
Screenshot 2020-01-16 at 4.34.12 PM.png477×626 19.3 KB

90

@Ryan780 I can't make mine do it, but I agree your pull request would likely resolve it in any case so I'll add it.

Thanks.

EDIT: One thought... I wonder if our reporting is setup differently... That might be it, because fan state is not something it is setup to report by default. I might have changed mine!

I wonder what your guys' config parameter 23 value is?

91

OK, I just merged @Ryan780 changes into v1.6.1. it will do a fan state refresh when changing fan modes. That might fix what you saw.

Side note, though, I would still love to see what some of your parameter 23 values are if you get time to switch to Basic Zwave Tool and check. If not, no worries!

92

Cool...i will check when I can.

And remember, when I sent you the PR, I wasn't able to get this to repeat a second time but I had the event logs to prove it happened the first time. that's why I wasn't so insistent about the change...I couldn't get it to repeat. But now that someone else saw it too...that means it's gotta have a probability that's higher than I thought. I'll pull param 23 sometime tonight.

93

I think the thermostat state matters when you switch the fan mode to get the problem, Have you tried this?

Switch to FanOn during Heating state then
Switch to FanAuto only after the thermostat state is FanOnly

Mine stays in FanOnly state, never moves to idle.

94

Thanks, and no problem. Looking at my test thermostat, I have ALL reports turned on, and that is definitely not the default... lol.

So more data will be interesting. It would be easy enough to force the reporting to something more (maybe all?) in Confgure if that is what is different.

95

Trying that now. Will report back.

EDIT: Mine sticks in Fan Only mode too. That's definitely a thermostat firmware bug, as it reports nothing back on thermostatoperatingstate - and I have every report bit turned on. I think I can work around it with the mechanical and SCP reports though.

Good catch. I never would have found that one!

96

Excellent! or not. I also had 2 other instances where the thermostat state was stuck to "heating" while it was actually not heating. I think it happened because I changed the fan state just after I had saved parameters and configured... I might be able to reproduce if needed.

97

OK... I think the change I made will fix that too (or at least I'm very optimistic it will!). Any time it gets an SCP status report that is zero, it sets the thermostatOperatingState to "idle".

Also, I changed it so that when you save preferences, it turns on autosending of ALL reports. That is how mine are all setup already, so I don't think that will be an issue for anyone. If it impacts those running without C Wire (aka on batteries), I'll go back and make it more granular.

v1.7.0 posted. You don't have to re-save preferences unless you specifically want the new reporting configured. The state sync fix happens without re-saving.

Thanks all!

v1.7.0 changes (in addition to the fanstateget commands added in 1.6.1):

  • Set thermostatOperatingState to idle when SCP report=0 to fix some out of sync issues with that variable.
  • Added in mechanical status and scp status state variables (can see granular system status in there including Min Run time and Min Off Time flags).
  • When parameters are saved the driver now sets the thermostat report autosend bits (param 23) to -1 which = send all reports
98

Edit - I'm an idiot... I forgot I'm already forcing the reporting to "all" in the CONFIGURE section.. No need to check your parameter 23, as it will be the same as mine if you have ever hit the CONFIGURE button...

I'm going to upload a v1.7.1 removing it from parameter save section. No need to update the driver if you already installed 1.7.0 though.

1 Like
99

It's possible I'm missing something, but does this driver support battery level? I can see the battery level when I use the built in driver, but as soon as I switch to this one the battery state disappears.

100

It should show in the event log it after the thermostat reports a battery level the 1st time. Not sure if it will show as a state or not.

As you can see below, I got lazy and left the battery reporting on, even when it is hard wired. It reports 1x/day by default. So you should see it in the device event log at some point:

14%20PM
Screenshot 2020-01-25 at 3.07.14 PM.png1385×502 35.3 KB