Newer HAOS install via VM on Synology and TubesZB PoE Z-Wave controller. I installed 2 of these GD00Z-4 garage door opener controllers that I’ve had for many years on a previous hub. Upon initial s/u of Home Assistant, I added both of these and everything seemed to work fine. When first included, the light was blinking and beeping was going non-stop. I turned both of those off via the UI and even opened and closed both doors using HA w/o issue.
A week or so later I needed to close a garage door so I busted out my HA app and attempted to close it. Clicked the down arrow and… nothing. Same deal with the 2nd opened too. So both of these worked fine after initial install but seem to have quit working and I’m not sure why. I also can no longer manually turn the strobes or audio beeps on either that I also tested to have control of previously. It’s like the entire thing just stopped listening to commands sent via HA and I’m not sure why or how to correct.
I’m not above replacing them with newer Zooz hardware but I’m really not a fan of throwing out perfectly good devices if they just need a little software love to make work reliably. Is there something known with these device specifically that can be easily fixed or does anyone have any tips for trouble shooting? I did some searches but nothing I found applied to my specific problem. It seems that lots of people had issues including them in years past but I didn’t have any problems at all with initial inclusion.
Yes, upon including them when I first s/u my HAOS system and was adding Z-Wave devices I tested them both and both worked fine. Both open and close commands. States showed open/close properly too so the devices themselves were receiving/processing commands and reporting states properly.
Under device statistics it looks like it’s still connected based on device statistics:
Is there a better way to determine connectivity or does this verify enough for this trouble shooting process?
Not sure what you mean by connections. These have both been physically connected to the openers w/o issue for many years now so I’m 100% sure it’s not a hardware connectivity issue. The doors still operate as expected using the wall buttons, etc. When I try to trigger the control via the HA app though nothing happens at all no clicks or anything the log shows “Garage Door Opener Double Last seen changed to March 4, 2025 at 10:47 AM
10:47:07 AM - 13 seconds ago” but I don’t see anyting about failure or error but I’m also equallly sure there’s probably a better place to review this informaiton more fully. Like I said, HA n00b in learning.
No, it’s not my only Z-Wave device. I’ve got over 50 Z-Wave devices that all worked fine on my previous hub (VeraPlus) and all seem to work fine now save for a few smaller issues here and there that are user error as I try to continue setting things up initially and learn how HAOS works.
That commands dropped - guess why nothing’s responding…
Those Linear GDOs will lock in and stay that way once they get a good route - but I had hell getting mine to lock in too. Sounds like some strategic route repairs will help. Are you using builtin Zwave or are you using ZWave JSUI?
Ah, I’m glad I posted that then. This could also coincide with another issue (or issues I should say) that I’m currently tracking down. I just didn’t realize it before this post.
My Z-Wave controller for my system is the TubesZB PoE controller and I’m running Z-Wave JS UI. I also have a short list of issues I’m trying to work through with that, some seem to have self-corrected so I’m not really sure yet what all is going on there.
I did recently force a route update because the routes that JS UI showed made no sense. I had devices that were about 10ft away from my TubesZB going 25ft away, then some 50ft away, then another 15-20ft back to the controller. It made no sense to me why some of my older 500/700 devices were trying to mesh when a direct route made far more sense. I wanted to manually tell these devices to skip the 2 or 3 hops and just communicate directly but I didn’t see an option. I think I saw a video once where someone was doing exactly this via the JS UI network graph (where I first saw these weird hops, confirmed via Z-Wave Add-on device metrics) but I don’t see that option.
As it happens, one of those 3-hop routes that was unnecessary included one of the two Linear garage door controllers as it’s first hop. I may have b0rk things in my efforts to optimize them. I was trying to figure out why none of my Z-Wave devices were showing up as the 800LR version of comms (even though my TubesZB has the latest 800LR PGIO radio) and all showed basic Z-Wave w/the green icon even though around half of my devices are of the newest 800LR variant. As soon as I got all of my hardwired (mains powered I guess some call it) devices migrated over to HAOS I ran a route rebuild hoping it would optimize things but it appears as though maybe I just made things worse? It also took forever, if that’s any indicator.
I individually ran rebuild route for both garage door openers, both returned a successful completion indicator after a very short period but behavior remains the same for both devices. Neither one responds to any commands.
You may have to look upstream - if they cant connect, what do they connect to - is that route good. You’ll need to look at the route all the way back to the controller. It may not be THAT route that’s borked.
I’m confused, both of those show a good direct route back to the controller. What else is to know if there’s nothing upstream from the device in question and the device connects directly to the controller (no hops) and shows a green comms connection?
I thought of something last night that I believe to be related:
While diagnosing an issue with one of my Z-Wave deadbolts, I was following the steps outlined by another user that were posted and one of them was to refresh the “S0 Legacy” key within the JS UI Z-Wave settings.
As I was processing the steps I immediately knew I screwed up right when I tapped that refresh w/o first at least copying the key that was in there. Not something I would normally do but it was a looong day of trying to correct the issue I was having. I know, I know… excuses.
I went on to exclude, factory reset and then include that deadbolt afterwards though and it’s still not responding… same as these garage door openers now. I would have thought that, even if I reset the security key that the device was looking for that an exclude/include cycle would rectify things. Especially when I did it again with a successful factory reset of the device in the middle. No such luck.
I noticed that, in my list of devices, I’ve got four devices showing the same an orange check for “Security” and it just so happens that these are the four devices that aren’t stating their status and aren’t processing commands that I issue. I think I’ve narrowed down the potential cause, but how do I go about fixing it now?
It seems as though excluding, factory resetting and including again didn’t help with the deadbolt so I’m not sure it would help with the garage door openers either. Is there something I need to fix within the JS UI interface before running that or ??
Not entirely sure what that means but they’re ancient so, probably. I know that when I initially installed them back in the day I had to run the Vera Plus out to each one on a ladder. I was surprised this time 'round w/the TubesZB that I was able to include both w/o taking the Z-Wave radio to their location.
I did the exclude via VeraPlus and then just added them to HAOS and it they just worked. It wasn’t until I messed with the S0 key and/or forced an entire network rebuild that things got wonky.
The fact that these two Linear openers as well as the two deadbolt locks I’m having issues with are S0 leads me to believe that it’s the whisper mode of which you speak and my guess is that they broadcast a super low power signal during pairing as some sort of security to prevent other devices from trying to pair before the 5-digit DSK feature of the newer Z-Wave protocol.
As I’ve been in this home automation thing for decades now I’m not really up on all of the latest but that’s my guess on that and if it will help alleviate this issue, I’ll gladly get out the ladder and my 100ft network cable to move my TubesZB PoE controller around as I exclude/include these devices.
Is that the solution here? Put my TubesZB PoE on a long network cable and travel it to each of these four devices (Schlage deadbolts x2 & Linear garage openers x2) while I exclude and include them again?
If the garage door openers worked the first time, they should work again w/o traveling the controller though, right? Is a factory reset even necessary (much more work created for the deadbolts specifically) or just exclude/include again? If so, why did none of my trouble shooting work for the deadbolt as I did all of this already and the result is still the same?
Trying to get my head around all of this so I can lay out the most efficient path forward to correcting these issues.
The most efficient thing for hose GDOs is to exclude and reinclude.
Every time you mention them there’s more information.
Yes. If they’re that old they are whisper mode. They REQUIRE to be paired within 1 ft for the exact reason you mentioned. If that DID NOT happen at first (which leads me to believe was the case now because all that racket - beeping) happens when these things get a bad include.
So I suspect you included them kinda sorta halfway enough to get a response. Silenced the racket and left them overnight?
Or the S0 key.
Or.
It could be any one o f those and now the troubleshooting chain is so long, the answer to. Yojr question is now get a ladder. Yes. You will require it.
That all makes sense. I just didn’t want to do a bunch of extra work that wasn’t necessary. It’s also a tad chilly right meow out in the garage which is where the openers and one of the deadbolts is so the less time I can be out there, the better.
I just can’t understand why my front door deadbolt still doesn’t work properly if excluding and including is all that’s required at this point as I effectively did that previously and that one still doesn’t work.
The other issue that I’m having is that whenever I unplug my TubesZB Z-Wave PoE dongle I get red “controller has become unresponsive” errors in my Z-Wave JS UI dashboard. Aside from the controller being permanently located in a spot that makes it difficult to get to to plug in elsewhere so that I can locate it closer to the devices, the errors I get simply from unplugging it and plugging it into another port on my switch isn’t very confidence inspiring.
I was previously grappling with errors in my HAOS settings screen regarding a “port” issue and Z-Wave JS UI that mysteriously resolved itself and all of this may be related as well.
Update, I think I managed to correct all of the issues within this thread save for the one deadbolt that’s no longer functioning properly. So I’m basically back where I was before I refreshed that S0 key. Both garage door openers and the back door deadbolt were all excluded/included flawlessly. Updated a few of my Mushroom Dashboard cards to reflect the new entity names and I’m back up and running.
The only issue I have remaining that still feels kind of related is that front door deadbolt that just mysteriously gave up the ghost. I need to see if I can get to the bottom of that as it has worked great for me for many years and I’d hate to spend over $200 just to get the lock/unlock controls working again. That feels like something unrelated to this as I think it’s the deadbolt itself and now the connection/security which was the topic if this thread. I’ll continue trouble shooting to see if I can resolve this but thanks for all of those who took the time to help me out.
For anyone else who maybe finds this via the search “Controller is Unresponsive” from within Z-Wave JS UI; I had to reboot my VM via VM Manager within Synology. I was reading some posts online of others who were experiencing weirdness and possibly even related bugs that were patched in previous versions of Z-Wave JS UI. Since I had tried unplugging/plugging the controller back in and also attempted HAOS reboots among other things, I thought I’d go ahead and try a reboot of the VM itself. Once it came back up, the error was gone and my Z-Wave network was accessible once again.
