I'm hoping to run some automations on door unlock, but I don't have any interest in having the lock itself controlled via the Hubitat C7.
I can pair the lock via S2, and I can read the locks state then, but that gives me everything.
I tried pairing via S0, but while it connected, and showed in z-wave details, it never showed up in devices or gave me any info.
Does anyone have any suggestions for a good way to do this? Is there a way I can limit the capabilities the hub has over the lock? A different method of pairing you'd advise if I only need to read from the lock?
S2 or S0 won't affect this (locks do require security to pair, and they should "fall back" to S0 if S2 is not available or declined, though a few oddball devices do have problems with this--not sure if finding a problem that might accidentally make it work the way you want was a goal, but it's unlikely).
The only way to really do this is to (pair it normally and) restrict who and what has access to your hub. You can set a password on the web interface, and that will take care of the "who." You can only add specific Hubitat apps that you want on the hub side, and that should take care of the "what" (apps on the hub can only access devices you've authorized within that app; for the most part, this would be automations you create -- or don't -- on the hub, but be aware of things like Alexa, HomeKit, Google, or Maker API that could expose the lock to external services).
An alternative is to find or write a driver that only exposes the attributes and not the commands, which would eliminate the second concern above. Before I'd do that, I might take a step back and share the bigger picture: what particular concern are you trying to address? There may be another way to look at this issue if the above doesn't help.
I was originally hoping to make it pair in S0 mode to accomplish this, but that seems to not be working.
I do have my hub restricted, but that's still a much larger attack surface than I'd prefer.
An alternative is to find or write a driver that only exposes the attributes and not the commands, which would eliminate the second concern above.
Ah, I think that might be viable, though a lot of work. It seems that a driver can't be changed without repairing the device, so that would accomplish what I want?
Before I'd do that, I might take a step back and share the bigger picture: what particular concern are you trying to address? There may be another way to look at this issue if the above doesn't help.
I only need to read the lock, not write to it, so pairing any hubs/services greatly increases the attack surface for no real benefit to me. Using a electronic cloud lock already exposes you, and I'd really like to limit that exposure to a single, audited provider (August) rather than multiple.
For example, perhaps I could take "Hubitat/examples/drivers/virtualLock.groovy", and remove line 91 to disable the lock command, and then force the Hubitat to use this driver for the August lock instead of the normal one?
I saw that, but I'm again unsure why; with rare exception, S2 vs. S0 does not affect device functionality (neither does S2/S0 vs. no security in most cases, though locks are an exception).
This is not the case; you can change a driver at any time. Choose the new one from the "Type" dropdown on the device detail page.
Not easily. Virtual devices are effectively fake (simulated, useful for testing apps or odd uses on your hub, etc.). Among other differences, you would need to parse incoming Z-Wave messages, which a virtual device never has to worry about. You'd be better off starting with a Z-Wave lock driver, should you be able to find one.
But if someone has access to your hub, which they'd need to run the "Lock" or "Unlock" command from it in the first place, even if you change the driver, nothing is stopping them from changing it back (or just sending a "raw" Z-Wave command from the device detail page) and doing it anyway. Without a firmware feature on the device to disable remote control -- and I'm not sure any Z-Wave (or Zigbee) lock has such a feature -- anything else is just a workaround that makes it some degree harder.
I saw that, but I'm again unsure why; with rare exception, S2 vs. S0 does not affect device functionality (neither does S2/S0 vs. no security in most cases, though locks are an exception).
In that case, I think that was a misunderstanding by me, thinking that the lock would downgrade it's access with dropping to S0. I had found some forum posts mentioning that (maybe older firmware?), but it seems to not be happening to me, and at the least probably isn't something I can rely on.
This is not the case; you can change a driver at any time. Choose the new one from the "Type" dropdown on the device detail page.
Yup. Based on this and your followup message, I think I simple can't get what I want out of this August/Hubitat integration.
If the attack vector is compromising the hubitat hub itself, one can still send raw zwave commands to any device. So while those commands not being in the driver is directionally good, it is not a full protection from a competent assailant.
Just pointing that out. Doesn't mean that it wouldn't be worth doing anyway though.
Yeah, using a different driver won't do what I want.
The concern I have is that kicking a door in is a clear sign of forced entry, where as a hacked lock is not, and that's very important for insurance if the worst does happen.
If it helps at all, a former career police officer friend of mine with decades of service said that in his experience vast majority of home "break-ins" are accomplished via unlocked doors, open windows, open open garage doors, keys left outside in obvious locations (under the mat - DOH!!), etc. People problems, not technical problems. The next most common category he experienced was smash and grab. Break a window, grab stuff easy to sell stuff quickly, and high-tail it away.
There just aren't a bunch of bands of hi-tech thieves running around breaking into homes via sophisticated network attacks.
Unless there is some reason why believe you'll be targeted by a sophisticated gang of Mission Impossible thieves, an "IT break-in" just isn't going to happen. Much more important to ensure you and family members remember to close/lock stuff up.
Lol... Was just using that as a jump off point. People are so concerned about security of their home automation system. Lets face it, a brick will bypass a lock. Lets assume that someone is close enough to sniff your z-wave or zigbee network, they're close enough to see exactly what light you're turning on or off etc. At that point they're gonna wait till you leave and break in the easiest way possible... just saying.
The point is more that a brick or similar method leaves obvious traces of a break in, where as a hacked lock would be very hard to tell apart from leaving the door unlocked, which would mean no insurance coverage.
Also wouldn't just be z-wave range, but if the remote services of Hubitat or any other third party integration got compromised.
I get it. Windows and cylinder bumping much faster. The poster in the original thread (in a deleted thread) kept making claims about high-end homes in Silicon Valley being broken into via a Z-Wave hack. IIRC @aaiyar kept challenging him and there were no receipts.
Yeah @aaiyar is good about calling out bs and doing a mic drop lol. Multimillion dollar homes will have a proper alarm system and not rely on a lock to protect them. There is going to be a whole lot more at work including a monitoring company.
Without a firmware feature on the device to disable remote control -- and I'm not sure any Z-Wave (or Zigbee) lock has such a feature -- anything else is just a workaround that makes it some degree harder.
