Hello,
First of all, thanks in advance for any assistance or suggestions. I searched and found a little info on this but not this scenario. I replaced my old GD005-Z about 4 months ago that worked in ST and for about a year once I migrated to HE. Was having many tilt switch status issues so decided to replace the 5 year old GD005-Z with a new GD008-Z (z-wave plus) Go Control. It worked perfectly for about 4 months, then similar results. Could open/close the door via HE but status always showed door closed even after a "refresh" on the device page. Excluded then Included back into HE with my HUB within 1-2' of the Go Control. Now I can still open/close the door, still having status issues but now a "Refresh" will query to update the actual status. Any insight will be greatly appreciated. Screen shots below of the device.
First thing I usually check is the battery in the tilt sensor, then reset/repair the sensor device with the opener. There's a way to do that, listed in the docs, not that difficult. I assume you tried that, but since you have a new GD008, shouldn't be an issue.
I have a couple of these (GO-CONTROL), earlier versions though. I seem to recall that only CLOSED and OPEN generated events, but CLOSING and OPENING could be polled on a refresh. I may be wrong there, but if I remember correctly I built my RM code around something similar. The details I have posted below all center around that same opener. The code is hidden in the detailed section under several related rules.
The opener is at a remote property, but I can pull some additional details on the device this evening, possibly run a couple checks, and provide more info.
I have the same GoControl device and have the same issues...was really disappointed and the tech support was non-existent.
I got around it by getting a garage door tile sensor (Amazon Link) and connecting to Hubitat.
- I renamed the GoControl device to Garage Door Controller
- I created a virtual Garage Door Controller...setting the transition time to 30 seconds
- I then created a WebCore rul (couldn't figure out how to do in Rule Machine) to update the virtual controller status based on the contact sensor
- I control the garage door and display status using the virtual controller
I have the older version and have had constant false reports from it. The 2 am ones were always fun... no support, nothing I could do fixed the problem. Battery changes, re-pair, had no long term effect.
I had a ZWave Tilt Sensor long before I got the Linear GDO and I completely switched over to using that for REAL status. I let the GDO tile in a dashboard reflect the Linear's state, but it has NO access to my Alert rule(s). The Ecolink Tilt Sensor (I've replaced it after a drop with the ZWave + version) is the only accurate info I alert from.
I have a pair of the GoControl GD00Z-8-GC units. No issues on a C7.
One thing comes quickly to mind... If memory serves, the -8 units require pairing with S2 to support spontaneous events. I do not see that you have them paired as S2. S0 perhaps?
S2 pairing should look like this:
- deviceType: 18244
- zwaveSecurePairingComplete: true
- inClusters: 0x5E,0x55,0x98,0x9F
- zwNodeInfo: D3 1C 84 04 40 07 5E 55 98 9F 68 23 F1 00 85 5C 59 66 22 71 5A 73 6C 7A 72 86
- secureInClusters: 0x85,0x59,0x66,0x22,0x71,0x5A,0x73,0x6C,0x7A,0x72,0x86
- deviceId: 13617
- S2: 132
- manufacturer: 335
I'm pretty sure I have an earlier version than the -8, but mine is also S2 secure paired. Here's the device info, similar to @dennypage:
I did have to take into account timing delays in my rules which interact with the GDO, mainly activation delays (including warning before movement, and approximately 7 seconds to fully open on my door). My code included a check to follow-up on the on the motion (opening/closing) to see if the door responded. That also helped account for if an order was sent within 30 seconds of the last movement which the GDO will ignore.
Note the challenges some have had and list previously. The only issues I've had is occasionally have to repair the sensor with the control unit, and I've had to replace a couple controllers that stopped working completely. Since it's been working fine.
As for the events themselves, OPEN/OPENING/CLOSED/CLOSING are all triggering individual events. OPEN/CLOSED are triggered both as contact sensor events, and door events.
Here's a sample event log:
Interesting. Did I somehow miss a step during the inclusion to enable the S2 enrollment? Is there a prompt or check box etc that I missed?
A S2 value of 128 means S0. I believe that Is a S0 only device paired on a C7.
To my knowledge, the -8 is the first (and currently only) S2 capable version.
That is certainly possible, I don't know. I did notice the difference between S2: 128 and S2: 132. I assumed it was the secure key bit length, which I understand is 128 bit in S2., just a guess. I confess I don't fully know the difference between S0 and S2, I presume S0 is just normal un-keyed pairing.
I have Kwikset z-wave locks which I'm fairly certain are S2 secured, which are also showing S2: 128. I'm also going by the earlier entry in the same section which states:
zwaveSecurePairingComplete: true
zwaveSecurePairingComplete indicates that some form of security is present, S0 or above.
I’m not knowledge on the various Z-Wave locks, but I am confident that 128 means the device is paired with S0, regardless of its capabilities.
Thanks, learning more each day! I did notice the locks on my C-5 hub all are missing the S2 line. Generally familiar with secure pairing as I ran into issues in the past, but never dug into it any deeper.
Yea, that’s because the C5 itself isn’t S2 capable. 
dennypageRegular
I have a pair of the GoControl GD00Z-8-GC units. No issues on a C7.
One thing comes quickly to mind... If memory serves, the -8 units require pairing with S2 to support spontaneous events. I do not see that you have them paired as S2. S0 perhaps?
Well isn't that a hoot...Just realized my HE is a C5.. Would I be wrong in the presumption that I would be able to restore a current backup of this C5 to a new C7 and avoid starting from scratch again?
i put a camera in the garage so i could remotely make sure teh door was still closed in the empty house due to false reports. I've had regularly to go open and close the door multiple times when i get to the previouisly empty house to ge tit to resync.. I believe part of the problem is the garage is usually and the edge of your mesh and signal issues or a afailed sensor it was relaying through.
I ahve since replaced all but 1 iwith the newer 008 zwave plus models and have had less iseeuse. but still not 0.
I think it's just poor engineering in their code. There's a lot of metal in my environment and I can easily deduce it's a factor. For Me. The Linear tilt sensor is a foot away from the main Linear GDO, but it's on a metal door, with metal tracks.
I tested my GDO without the tilt sensor attached to the physical door, and the GDO seemed unaffected. Obviously I didn't get Events BUT from that I took it upon myself to conclude that the Linear Tilt sensor is just pass through. They don't clean up the signal or debounce... garbage in = garbage out.
Since relegating the Linear tilt sensor to be ignored for anything important, and using the Ecolink Tilt sensor as the primary, I've never had a false alarm... and the battery life is astounding.
C5 to C7 shouldn’t be a problem.
You can do this, but it isn't just a simple matter of backup and restore. Zigbee devices need to be paired again, which isn't too bad. The real issue Zwave doesn't transfer the radio info over via the backup. So you have to go through a convoluted process to exclude/include your devices. It can be done, but can be tedious.
The Hub Protect can migrate your hub, and it does bring over the Zwave devices. So that is the easiest path to switch. It still cannot transfer Zigbee radio, but those devices join fairly easily once put into pairing mode.
Yes, a very good option. One thing to note is that if you migrate to a C7 via this route is that all devices will be enrolled with the same security model they had prior to migration. So if you have S2 capable devices that are enrolled as S0, you will want to exclude and re-pair them after the migration.
