GoControl GD00Z-8-GC Discovery

Tags: #<Tag:0x00007f433ea07548>

I’m trying to discover a GoControl GD00Z-8-GC Smart Garage Door Controller so I can start the process of adding the device to the database. Attached is what was logged. Any help would be appreciated.

openhab.log
Added new thing ‘zwave:device:c39c2b54:node62’ to inbox.
NODE 62: SECURITY_INC State=FAILED, Reason=GET_SCHEME
NODE 62: Device discovery could not resolve to a thingType! Manufacturer data not known.

events.log
Discovery Result with UID ‘zwave:device:c39c2b54:node62’ has been added.
Discovery Result with UID ‘zwave:device:c39c2b54:node62’ has been removed.
‘zwave:device:c39c2b54:node62’ changed from UNINITIALIZED to INITIALIZING
‘zwave:device:c39c2b54:node62’ changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
‘zwave:device:c39c2b54:node62’ changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE
Thing ‘zwave:device:c39c2b54:node62’ has been updated.

The binding does not know the manufacturer data. This happens when a device has communications problems with the binding. For mains devices, it may require to be excluded and re-included, or it may be that it’s simply out of range. If this is a battery device, then it might be as simple as waking up the device.

However, the controller offline status seems to indicate that there may be a problem with the USB link in the controller, so you would probably be advised to check the logs - enable debug logging as per the binding docs.

1 Like

OH2 seems to be communicating with the node be errors out. Here are the logs with debug enabled.

openhab.zip.log (331.5 KB)
events.zip.log (21.1 KB)
network_dbdf63df__node_62.xml (3.1 KB)

It looks like the issue is probably related to the NIF. The device doesn’t report many CCs in the NIF, so the discovery is not discovering them.

Probably more CCs are supported, but this will require a binding code change to resolve.

Chris, how can I get the binding change in the development pipeline?

Please try the latest snapshot of the binding and let me know if it’s any better (or worse :wink: ).

I loaded the OH 3.0 Snaphot on Docker (openhab/openhab:snapshot) with a seperate z-wave stick for testing. That seems to have the same issue. I’m guessing you wanted me to just upgrade the binding which I can test next with debug on. Can you please point me to instructions on how to just upgrade the binding?

Yes, that is expected - it’s basically the same code you were already running.

Same result…

network_dbdf63df__node_63.xml (3.7 KB)
logs.zip.log (494.0 KB)

Well, this is a bit sad. The new code is working, but the device is ignoring the commands.

The binding sends the request to get the manufacturer data - the device responds with the ACK to say it received the request, and then doesn’t send a response. This is repeated 3 times, and the binding then gives up, but this leaves the device unidentifiable.

I think, unless there’s been a recent change to the ZWave spec, that not supporting this feature makes the device non-compliant to the ZWave standard :frowning: . OH relies on this to work out what the device is, so we’re a bit screwed.

I just checked the ZWave spec, and it states that supporting the manufacturer specific command class is mandatory -:

Now it’s possible I guess that the device isn’t responding unless it is securely included, so you could try a secure inclusion to see if this works.

I think I did the secure inclusion correctly; if you could confirm that through the logs I’d appreciate it. Same result but it does look like it logged more data… Should I reach out to the manufacture and if so what specifically should I ask for?

openhab.zip.log (481.6 KB)
network_dbdf63df__node_65.xml (3.7 KB)

It doesn’t look like the device was securely included.

I think there’s another device with the same problem - a Zooz device that I think is probably just a rebadged version of this device. @Bruce_Osborne is expecting one of those in the next day or so, so hopefully he can also try this out.

1 Like

Chris, just to validate. To do a secure include:

  1. I go into the z-wave binding (Paper UI -> Configuration -> Things)
  2. Click the plus sign ( + ) at the top left corner.
  3. Follow the include instructions on the z-wave device.

You must also ensure that the device is reset, or at least excluded, before trying to join securely. There are timing constraints - the device can only be securely included within 15 seconds of the initial inclusion into the network. From the log you provided, I couldn’t see the actual inclusion of the device, so I’m guessing this constraint might not have been met.

I’ve been having this problem today while attempting to add this garage door opener. My openhab.log keeps showing the same messages no matter how many times I do it. The device is not installed in the ceiling yet, it is in the same room as my openhab laptop (running 2.4.0, apparently).

2020-12-02 15:33:42.885 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:e96ab58b:node28' to inbox.
2020-12-02 15:33:47.949 [INFO ] [mmandclass.ZWaveSecurityCommandClass] - NODE 28: Using Scheme0 Network Key for Key Exchange since we are in inclusion mode.
2020-12-02 15:33:48.136 [INFO ] [alization.ZWaveNodeInitStageAdvancer] - NODE 28: SECURITY_INC State=COMPLETE
2020-12-02 15:33:48.390 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 28: Device discovery could not resolve to a thingType! 014F:4744:3531::3.0
2020-12-02 15:33:48.936 [INFO ] [ommandclass.ZWaveVersionCommandClass] - NODE 28: Command Class COMMAND_CLASS_BASIC has version 0!

Is my zwave add-on out of date? If so, is it possible to update it without updating my entire openhab version?

Thanks,
Neil

Check the version of zwave binding by running the following in the Karaf console…

list -s | grep zwave

If there was a recent update to the device database, then you can wait for 2.5.11 or use…