The timeout is set at 25 seconds. If I hit open or close from the device details screen, the contact status changes immediately, so I know it's not using the physical contact I defined in the setup. Am I wrong to expect it to use the physical contact or tilt sensor?
It is just a v-switch.
Is that what you are looking for?
So if you automate you will call that v-switch to turn on.
Ah! Right. Sorry, I looked at the message too quickly and thought you had made an update in the app code for this. That said, it’s a very good workaround!
No worries. Happy to help! 
Thanks @jsarcone
Ah I should have stated that yes I intend to use a Zooz zen16. I guess this driver is open where you can use other devices as well, so that is definitely one difference.
Possible I will need to try both with the zen16 and see if there are any differences in behaviour myself. I was just attempting to be lazy.
If I understand it correctly the default (configurable) timeout of 25s is the amount of time the app waits to compare what was requested (open/close) vs what the contact/tilt sensor is reporting - not a delay in action. Then the virtual GDO is showing "status" based solely on the reporting of the contact/tilt sensor - which changes on mine about 2s after it starts opening and changes to closed about 2 seconds before it finishes closing - directly matching the status of my tilt sensor reporting.
Okay, added local control couple weeks ago - still not where I want it to be. Had issues with Zooz GDO app and decided to try this one. So far, this looks promising - have to test departure/arrival routines and see how it goes.
A couple of things - I also would love a "built-in" capability to play a sound/siren and/or flash a light. I too have manually opened my door on arrival because the local routines had not kicked off yet only to have the GDO start closing (thinking it was opening) as I started into my garage - not good.
Second issue I've yet to solve is the fact the app strictly relies on open/closed status of my tilt sensor and doesn't know if the door is "stopped" ala not fully opened. I often open my door 6-8" to facilitate heat dissipation and regardless of whether the tilt says "open/closed" a button push will ALWAYS close the door. So if the app/vGDO thinks the door is closed and an open request is called the GDO just knows a button was pushed and the door comes down. That DOES cause the app to recognize the door "failed to open" - but that is not until after the timeout (which I have at 15s). In testing I have found there are times where I have to cycle the door a couple times before it gets back in sync with reality.
1 Like
I'm using this app for a gate opener. On my dashboard, I'm using the Garage (Control) template. Is there a way to eliminate the 'Are you Sure? Yes/No' prompt each time the button is pressed?
That's not part of the app that is a dashboard feature forbthay device type. Add a virtual switch and rule that sets the garage door to open or add the garage switch (not door )! to the dashboard
Howdy All, I've been using this app for a really long time ... however every now and then (eg 1 out of every 5 times) it doesn't actually open my garage door. The garage controller doesn't appear to be the issue and has a good z-wave connection directly to the hub.
My relay "auto-off" is definitely a long enough duration too.
The only thing I can't prove 100% is the app. It feels like sometimes it just doesn't trigger the relay but it does change the virtual door state to open - I know this as I get the notification.
I'm wondering if the app is turning the contact on/off rather than letting the controller manage this?
Any ideas?
i would sett the auto off to 1 or 2 seconds. there is no need to have it turn off that quick
500 = 1/2 a second iirc so I'd have thought that was ample?
EDIT: Math isn't my strong suit, but I think 500 actually equals 8.3 seconds in this case and some manual testing seems to support that. So I've changed the auto-off value to 60 (60/60=1) and I see how that goes.
So it looks like 60 is producing a better better so far. The door seems to respond faster too which is interesting. Maybe the door motor didn’t like the really long press?
Ya my off times for things like my gate is 1 sec.
1 Like
Feature Request -
I've used this little ditty for some time now and and thankful and grateful.
I get debug messages whenever the unit operates. I don't see a debug log enable anywhere.
I wonder if the app driver could implement a log switch? I did take a look under the hood, and it seemed that some messages were more 'info' oriented but all messages are characterized as Debug. Ideally, it would be great to have a debug, and a warn message type, with associated enable/disable switches.
I'd be happy to submit a PR if that would help!
3 Likes
Ok will.add that in the near future
3 Likes
new vesion on git hub.
here and available in package manger..
changes:
debug option and desclog options.. auto turn off of debug after 1/2 hour
for messages via the actual virtual garage door device you have to edit that depending on what device you are using..
https://raw.githubusercontent.com/lgkahn/hubitat/master/lgkgaragedoor.groovy
2 Likes
Simple and elegant! thank you!
Hi @kahn-hubitat -
I believe one debug command was possibly overlooked. On line 155 -
log.debug "Contact is in ${evt.value} state"
I hand adjusted my copy of your app by adding this at 155:
if (descLog) log.info "Contact is in ${evt.value} state"
... then commented out the original line
// log.debug "Contact is in ${evt.value} state".
