According to the Zwave database, I should have 3 channels: barrier_state, alarm_access, and alarm_burglar. No matter what I do, I only have the two alarm channels, and I am unable to control the garage door opener with zwave.
It appears to include securely, correctly. I’m pulling my hair out why barrier state is not showing up.
I’m not sure what logs or other information might be helpful, but here’s what was in my openhab.log related to the Thing:
2021-03-12 06:57:23.988 [INFO ] [mmandclass.ZWaveSecurityCommandClass] - NODE 7: Using Scheme0 Network Key for Key Exchange since we are in inclusion mode.
2021-03-12 06:57:24.174 [INFO ] [alization.ZWaveNodeInitStageAdvancer] - NODE 7: SECURITY_INC State=COMPLETE
2021-03-12 06:57:24.631 [INFO ] [ommandclass.ZWaveVersionCommandClass] - NODE 7: Command Class COMMAND_CLASS_BASIC has version 0!
So, I followed those steps, installed the new snapshot, and I understand the binding won’t show up, but my controller is now showing as uninitialized.
I tried restarting the openhab service and restarted the ubuntu server, to no avail. I watched the openhab / event logs and don’t see the zwave module ever mentioned.
edit: I thought it could have been a permission issue, since the .jar was owned by root and was chmod 600, but to no avail. Still sitting there uninitialized.
mrunne:/usr/share/openhab/addons$ ls -al
total 3488
drwxr-xr-x 2 openhab openhab 4096 Mar 12 22:39 .
drwxr-xr-x 4 openhab openhab 4096 Feb 8 23:15 ..
-rw-r--r-- 1 openhab openhab 70 Jan 27 20:42 README
-rw-r--r-- 1 openhab openhab 3558176 Mar 12 22:39 org.openhab.binding.zwave-3.1.0-SNAPSHOT.jar
Yeah, uninstalled it through the UI. I tried both the regular jar and the SOURCE jar (I don’t know the difference).
It feels like openHAB just doesn’t see it at all, which is why I checked permissions on the jar. I have a standard repository install of openHAB 3 on Ubuntu.
@kuantek - I bought the same Garage Door controller and battled with similar problems for quite a while… I did ended up getting the barrier_state channel to show up hours of frustration, but still couldn’t get the device to work as expected. This was a couple months ago though; things may have changed since with OH v3 updates and the Z-wave DB too. Few things to consider:
Have you cleared the openHAB cache after uninstalling the old and switching to the SNAPSHOT version of the binding? As I recall that made a difference with which channels became available.
Delete and recreate the Thing whenever looking for new channels.
Be sure to factory reset AND exclude the GC with each attempt - that was finicky and required multiple tries in some cases.
Be sure its included in ‘secure mode’, as you already noted it is.
In my case, Exclusion via openHAB 3.x wasn’t working correctly and I had to resort to doing it via the Z-Stick disconnected from my openHAB server.
Playing with the Z-Wave Serial Controller settings (i.e. network inclusion mode options) might have helped me along the way.
I did have to resort to using another tool (ZenSys) to manage the Aeon Z-Stick directly to forcibly remove otherwise ‘dead’ nodes (i.e. many old GC devices).
You may notice others reporting success with these similar Garage Controllers have a slightly different model number. This particular one is quite new!
@Bruce_Osborne - thanks to you and Chris for all of your hard work with adding this, and the many other various devices to the Zwave DB!
@kuantek - hopefully something here helps you move forward with getting it working. If you do, please report back; I might order it again. Hardware wise it seemed quite solid, and other HA solutions were reporting great success with it as well.
Quick update: I hadn’t had time to work on it much, I was never able to get a snapshot of the binding to work.
That being said, I have updated to 3.1.0 Milestone 2 (from 3.0.1) and the barrier_state channel is now correctly found in the Thing. I haven’t used it yet, but I do want to thank you all for your tips and advice. It was all very helpful!
Final update, and a last question that is related to the garage door opener itself and not openhab, so I’m not expecting much, just maybe someone knows how this works.
I have it all linked up, and it I can trace the connectivity all the way through. I send a command, it updates appropriately, the opener blinks, etc. (For future reference if anyone looks this up for help, I used these rules and mappings)
The final bit is that when the command is sent from the GD00Z-8-GC to my Liftmaster 8155, the Liftmaster claims there is a short in the line. Do you guys think that is a problem with the Zwave device? Or is the Liftmaster just not compatible?
Sounds like your making good progress! I didn’t try upgrading my OH3 to the latest Milestone while trying to make this work; looks like that could have been part of the problem…
Because of the above hurdle, I didn’t get into the hard wiring the unit, but maybe something to try - have you tried reversing the two wiring connections from the GC to the Liftmaster? Do so at your own risk of course, but sounds like it could be reversed polarity of the wiring here if the Liftmaster is still reporting a short!
Final final update. I was right, the MyQ compatible openers do not use a dry contact normally open button. To workaround this, I bought a $12 liftmaster button and wired the GD00Z-8-GC to the button and wired the back of the button to the garage door, and all is now working.
Looks like it was a combination of the database (3.1.0 Milestone 2 fixed that) and the device itself being incompatible directly with the garage opener.
