Expose as a lock about smartthings_myq HOT 35 CLOSED

Have not forgotten about this. May still be another couple weeks, but I'll get it in there eventually.

from smartthings_myq.

Yeah, I've already added door control back on my local version. I see the same thing where switching to Z-Wave lock fixes the Smart Locks app. I find it pretty silly they've apparently hard-coded that somehow instead of just looking at capability. Anyway, it's nice to know how to fix it. I may even be able to automate temporarily setting it to Z-Wave lock and flipping it back.

from smartthings_myq.

I've tried reaching out to the ST Dev Slack and even chatted with RBoy directly, but no one seems to know exactly how the "lock" capability really works as far as integrating with other apps (especially Google/Alexa). I haven't been able to find any other working examples of a "virtual" lock.

We are definitely trailblazing here.

You can ignore that dhname setting. That was a relic I copied over from one of the z-wave lock handlers I was trying to reverse-engineer.

At some point in the next week or so, I'll try and do a bit of cleanup on the committed version to at least re-add the door controls and try to get the unknown state fixed in the Smart Locks app.

from smartthings_myq.

Interesting idea. I'll play around with that and see if I can figure it out.

from smartthings_myq.

So after playing with this a bit, I think I can get it to work. One thing, though, is that if I add a lock capability, I'm pretty sure Alexa will still see the door and switch capabilities, so unless you comment those out yourself, I imagine someone could still bypass the pin by saying "turn on the garage door." I suppose I could add a setting at the SmartApp level to just disable those interfaces and ignore "open/close" or "on/ff" commands that are sent. I'll think on that.

from smartthings_myq.

@brbeaird awesome, thank you for taking a look!

I wouldn't mind having commented code / forking this, just wasn't sure how to accomplish it. However, having a setting to choose either just as a lock or "regular" door would definitely be great.

Is there any difficulty in getting the sensor to report locked/unlocked instead of opened/closed, or can you just call to those states when reporting locked/unlocked?

from smartthings_myq.

Yeah so I think it actually makes the most sense to just spin up a slightly different device handler for this that looks more like a lock in just about every way. Shouldn't be too hard. I'll see if I can find some time in the next week.

from smartthings_myq.

Getting close here. Been testing the lock functionality with Alexa and ActionTiles, and it works well. Just need to write the optional setting to disable the switch functionality to force all events to go through the lock.

from smartthings_myq.

Done.

from smartthings_myq.

@jrseliga - give that a shot and see how it works for you.

from smartthings_myq.

I tested through Google Home and the device is still coming through as a switch vs a lock. I really like this whole idea and would prefer to only be able to close the garage door via voice or through Google Home/Assistant. Similar to how the Nest x Yale lock works.

from smartthings_myq.

from smartthings_myq.

@brbeaird seems to be working great. Thanks a ton, Merry Christmas!

from smartthings_myq.

So apparently this update has a rather unfortunate side-effect for anyone who uses the native Smart Locks app in the SmartThings classic mobile app. The garage door "locks" show up in that app as "unknown." Manually refreshing the door temporarily fixes this, but eventually they flip back to unknown again. Looking into the best way to handle that...

from smartthings_myq.

Would it be possible to add an option to completely treat the garage door as a lock? As in make it look like a smart lock (a Schlage/Yale smart lock)? The sensor could tell us if the door is open/closed (just like a regular door) and if it’s opening/closing. The lock could be used to lock/unlock the garage door (like if a person were using a key on the outside of the garage door)... with the added bonus/feature of actually opening/closing the door for you (like a true gentlemen). Both Alexa and Google know how to differentiate which device a user is referencing when they are named the same by how the request is phrased. When I ask Alexa or Google if my front door is open, they refer to the status of a sensor. When I ask if the front door is locked, they refer to the status of the a smart lock. Google doesn’t allow unlocking by voice, but it does allow locking whereas Alexa asks for a PIN. The only thing Alexa and Google hasn’t worked out is that it doesn’t make sense to lock an open door :/

from smartthings_myq.

Ok, just pushed an update to try and clean this up. The lock functionality is now split out into a separate device handler that behaves more like a lock in some ways but still retains the contact sensor and garage door capabilities (at least for now). I also added a refresh that should resolve the "unknown" issues with the SHM lock app.

@kc6108 - it should already do this. If you have Alexa "unlock" the door, it will open the door (and prompt for pin if desired). I'm not sure if it's compatible with Google, though.

from smartthings_myq.

Google Home now shows garage doors as sensors when the lock option is selected. At the moment I believe this is the best we are going to get without help from ST/Google. Schlage, Nest, and Yale locks come through as locks with unlock only functionality, but getting our hands on the necessary code may simply not be an option.

From a usability stand point, being exposed as a sensor is nice. I named my multi-sensor “Garage” and the virtual sensor created by the SmartApp “Garage Door”. This allows me to ask if the “Garage Door” or “Garage” is open and/or closed, as well as, ask what the temperature is in the “Garage” vs what’s the temperature in the “Garage Door”.

More on usability... Google doesn’t allow locking or unlocking of the lock (garage door). So I setup IFTTT to listen for simple phrases. If a close (lock) command is heard then I have IFTTT lock (close) the door. If an open (unlock) command is heard then I have IFTTT speak back “Sorry, I can’t open the garage door by voice.” This is similar verbiage to what Google responds back with when I ask to unlock a Schlage, Yale, or Nest smart lock.

All in all, the only differences I’m seeing between your Garage Door locks and Schlage, Yale, and Nest smart locks are:

1. Google Home (or on the Google Home Hub display) shows a sensor icon instead of a lock icon.

2. You don’t have the ability to lock (close) the device if it’s currently unlocked (opened).

3. In the settings of the device the manufacturer comes through as “Unknown” and the device type is a sensor vs a lock.

I wonder what would happen if you added code to set the manufacturer as “Schlage” or “Yale”? ;)

from smartthings_myq.

Yeah, I agree, it's probably as close as we can get unless someone gets us more documentation on how to set up one of these locks in a "virtual" way. I have a Schlage lock, and I've looked over the Z-Wave lock code several times, but the way it handles polling and sets the manufacturer involves some pretty complex z-wave commands that are way beyond my understanding. I really have no idea at this point how to reverse-engineer that stuff in a way that works on a virtual device that isn't actually z-wave operated. If you do find a virtual lock out there at some point, feel free to send me a link. I'll keep an eye out myself.

from smartthings_myq.

I forgot to mention that “unknown” is still being displayed as depicted above. The garage door is the only smart lock in the list as I don’t have any other smart locks configured in ST. Maybe that’s the culprit?

from smartthings_myq.

I assume pulling to refresh that screen makes no difference? If you open the device in the IDE and drill down into it, does it show a value in data for "locked"? I have noticed that in the previous SHM screen, it can take a 1+ hour delay for it to pick up the door lock status for some reason.

from smartthings_myq.

Nevermind, I'm seeing the same thing myself now testing with my hub and just one door. Not sure why as it was working fine before. This is incredibly hard to nail down.

from smartthings_myq.

Well oddly enough, the lock state is working for me today. I was doing other testing and removed and re-added the door device a few times. Eventually I re-added it as a lock, and it just worked. I'm going to slowly prune down the random code bits I added last night to verify it still works without those. I think the key may have just been removing everything, refreshing Smart Locks to see no locks, then re-adding the lock device, but we'll see.

from smartthings_myq.

I got the unknown issue to go away by adding this to the Lock DH:

fingerprint mfr:"003B", prod:"6341", model:"0544", deviceJoinName: "Schlage Camelot Touchscreen Deadbolt Door Lock"

I’m sure you’ll come up with something way better lol

from smartthings_myq.

Wow, by adding that line of code, it kinda truly makes it a lock in ST. The buttons to open and close the doors no longer send open or closed commands. The only way to open or close the garage door is to use the Smart Lock lock/unlock toggle on the dashboard. Only the status of the door works in the SmartApp. I guess we asked for true lock functionality lol.

from smartthings_myq.

One last note before I hit the hay. When I added that line of code, I removed the unschedule and refresh every 30 minutes reschedule as I found they weren’t needed.

from smartthings_myq.

Ok now that's interesting. I'll give that a try.

from smartthings_myq.

FYI I have moved the lock option to a hidden "advanced" section in the 2nd page of the setup. I don't want this option confusing people who aren't really interested in it.

from smartthings_myq.

I have been testing the Lock functionality over the weekend.

I found that going into “Devices” and changing the “Type” from “MyQ Lock Door” to “Z-Wave Lock” immediately and permanently syncs that device inside Smart Locks in the ST Classic app. Afterwards you can change it back to MyQ Lock Door (this is a pain and shouldn’t be necessary IMO though).

I also found it weird that none of the door controls work. I recommend adding Door Control back.

I also like what changing the vid from generic-contact-4 to generic-lock-2 does for the new ST app. The device status is actually displayed correctly as locked/unlocked vs unknown and it doesn’t take away from the functionality in either app that I could find.

from smartthings_myq.

While I’m at it, I found that changing the Lock capability to LockOnly ensures that the unlock functionality doesn’t work. While this isn’t a good thing for Alexa, it is a good thing for Google (until they add a security layer like Alexa has for asking for a PIN). It’s really a moot point cause what I was truly aiming for was getting Google to import the Lock into Google Home instead of just the Sensor. I don’t really want LockOnly functionality inside the ST apps. It’s just so f’ing annoying that Schlage and Yale locks show up inside Google Home with lock icons and allow the user to lock an unlocked lock. I speculate something like hard-coding for these locks is at play too. Do you have any contacts that could guide us on how to get Google to import your MyQ locks as locks as well inside Google Home?

One last thing, what’s the purpose of setting dhname inside the parse function at the bottom of the DH?

from smartthings_myq.

Changing the vid to generic-lock-2 fixes the unknown status being displayed on the Garage Door Locks in the new ST app. Unfortunately in fixing that we lose Door Control and Sensor info inside the Devices. Although the Lock replaces the Door Control, we lose Sensor and gain a worthless and broken Battery.

I think I found the best of both worlds.

definition (name: "MyQ Lock Door", namespace: "brbeaird", author: "Brian Beaird", ocfResourceType: "oic.r.lock.status", vid: "generic-contact-4") {

This fixes the unknown status, retains the Door Control and Sensor, as well as, keeping the sliding door icons inside the device. That keeps both apps in sync. The smart locks app inside the new ST app works as well with this change.

The only thing I can’t automate is the original issue of the unknown status re the smart locks app in the Classic ST app. At least it seems we have a workaround for that for now.

from smartthings_myq.

Also, please don’t hide the lock/unlock messages so they can be displayed in the history inside the smart locks app inside the Classic ST app.

from smartthings_myq.

Yep, great point - will do. I didn't want the messages spamming logs for people who wanted the normal door device, but now that it's separate, it should display.

from smartthings_myq.

is this still in beta?

from smartthings_myq.

Yes. Pretty much on hold here until I have a better idea of what I can do with the custom device handlers.

from smartthings_myq.

I will work this into the new Edge version.

from smartthings_myq.