Virtual Garage Door Similar to RBoy App on STS

I apologize in advance if this has been covered as I assume others have figured this out but I can't find it reading through the threads. All threads seem to be about how to use commercial units like GoControl.

I'm coming from STS and was using the RBoy app to control my garage door which leveraged a dry contact and tilt sensor (both Z-Wave) and consistently worked without any issues. Is there something similar for Hubitat?

I found one app that someone contributed but it requires a STS multi-purpose sensor for tile but I have found that to be very un-reliable as I have a strong Z-Wave mesh but not a lot of Zigbee (so the problem was with my mesh, not the contributors code).

What is STS?

Typo, smartthings...

Doh!

Yeh, sorry.. was supposed to be ST for Smartthings.

1 Like

For those of us who aren't familiar with the RBoy garage door app, could you explain what it does? I must be missing something, since assuming your dry contact has a Z-Wave interface, you should be able to expose that as a button (or switch) you can push (or turn on), and the Z-Wave tilt sensor should be readable by Hubitat as such (probably a contact sensor, open/close). In other words, it seems like Hubitat should be able to handle everything already. Is there a specific way you're trying to tie them together? Or perhaps you could provide a link to the code you alluded to (that works with the ST Multi) so someone can see how easy it would be to modify to work with a slightly different device? (I'm assuming you've tried--I'm not sure what capability that app is looking for, but if it's looking for a contact sensor, which I think is still how the ST Multi works in "garage door" mode, where it just uses tilt instead of the magnet to determine open/close state, it's quite likely what you have would already work.)

The real benefits of the virtual garage door app is that is just simplifies the grouping of the dry contact sensor and tilt sensor with logic to determine if the garage door is open or closed and performing the necessary function. It also helps with the SAF (spouse acceptance factor) as there would be a single garage door tile on the dashboard showing the current state and she/he can click on the tile to change the state (either open or close). It also helps with automation as you can just use the rule to "close the garage door" and not have to add the logic each time to determine current state from the contact sensor and then decide if you need to fire the dry contact sensor or not - and then recheck the state as the garage door could have been partially open so firing the dry contact could have resulted in the door fully moving to the undesired state.

Description of the RBoy app is here: [RELEASE] Virtual Garage Door Opener/Controller with Relays and Contact/Tilt/Door Sensors - Devices & Integrations - SmartThings Community

In a lot of ways, this is very similar to the app I tried to use ([Release] Virtual Garage Door App/Driver (ST Port)) but it required the use of a Smartthings multi-sensor so that it could also look at the accelerometer to capture if the door is moving but I don't have many Zigbee devices so the hub connection to the garage is not dependably.

I know I can add more Zigbee repeaters (or buy a commercial garage controller) but was hoping to continue to use the ZWave devices that were already installed. I assume (possibly incorrectly) that others had made the same leap and had already found a way to handle this.

Isn't the problem with your sensor, not with the app?

Not the sensor per se but the reality that I have a very small Zigbee mesh to reach the garage and my experience is that Zigbee devices drop off the network fairly easilly when not in use often so while I could try and fix it by adding more repeaters, there aren't a lot of places to add them and the ones I do will just be sitting there only to repeat which means they will likely drop out breaking the chain and I can't afford something as critical as my garage door either becoming unresponsive OR opening when I am not home (or at night) when the Zigbee device finally can receive a long over due action from a rule.

So I agree that there isn't a problem with the code other than it requires a Zigbee device (which for others is the preferred type given their network) and for me, I really need something that supports Z-Wave.

If they are a repeater that means they have AC power...they should not drop off your network. I have two zigbee outlets that are only used for repeaters. One hasn't been switched on in months but is still working like a champ as a repeater.

I have 2 Smartthings outlets in between the Hub and the garage door (one in the house next to the garage wall and the other just on the other side in the garage) to try and ensure the messages get transmitted back and forth through the walls but I have found that the plug in the house falls off the network if I don't use it for a couple of days and I have to hit the button on the side repeatedly to get it to rejoin. I'll get a peanut plug to add and maybe setup a automation that just turns on the plug 1x/day to try and keep it in the network but am still concerned that if something happens I've got something as critical as the garage door that is not in the right state. I have not experienced my Z-Wave devices dropping off.

Like I said, I don't have to do that for mine. And you shouldn't have to.