Hehe I bought Ring Pro 2 Pro a couple of months ago and it’s all wired in and working. I have it exposed to ST but not much else than that. Also got Arlo Pro 2 camera up and monitoring al the time - again exposed to ST but not being controlled in ST.
Lol regarding the locks - my wife wouldn’t go for that at all - it’s been a struggle for lighting and using Sonos speakers for alarms with SHM. Her worry would be about getting locked out
For now, the simplest Ring to HE integration users have found is via Amazon Alexa. Since Alexa has Ring integration already (with instant updates), you can easily create an Alexa Routine to have it turn on a
HE virtual motion sensor whenever motion is detected at your door. The HE virtual device then automatically turns itself back off after a few seconds. This provides a nice 'motion event' that you can use in other automations. Credit for this idea goes to @stephack.
Check out the discussion and the virtual driver I created below
Sadly not available to us in the UK as yet, we need the updated Alexa skill to expose the ring and motion. 
1 Like
I've moved some devices, automations, and TTS messaging from ST to HE, these run very fast and are reliable. Obviously, setting the status of a target virtual device on a differant hub may take some extra time, but in my opinion it's a lot easier than attempting to brute force everything over to HE in a single session. I'm still using ST SHM and my ST SHM Delay smartapp with my two Keypads, and so far it works well with the virtual motions and contacts in HE, Since SHM Delay uses a cloud based Virtual Contact Sensor, most everything including ST SHM runs in the cloud in my ST setup, except perhaps for ST Smart Lighting.
One big issue I encountered was getting some of the devices into pairing mode after removal from ST. Then after pairing the device, going back into both ST and HE and setting up the device status transfers to the other hub, then fixing any existing ST automations not being moved to HE. Be sure to print out all of the current automations for a device in ST before it is removed from the system, since they are lost when the device is removed. Another concern is losing your device mesh when transferring a repeater.
I hear you! My wife would not go for a front door lock like that either.. was able to put one on our side door however and that has worked out great - allowing our daughter access after school, cleaning crew etc. I also have Aeotec recessed door sensors in all the exterior doors as well with door open alerts being sent to a door chime (and alerts if a door is left open for more than X minutes).
The real problem with all this Home Automation stuff is once you start down the path it's hard to stop... I currently blame HE for making this so much more appealing, accessible AND private.
E.
3 Likes
Guilty as charged. 
5 Likes
I admittedly have weird requirements, in that I'm designing my "smart home" from the beginning with the intention of leaving it with the house, and therefore all the automations need to at least be plausibly manageable by some random person in the future. I also expect my SO and kid to set up their own personal stuff like bedroom lamps, but mostly just a "beta test" for my design. (I figure it'll raise the value of the house, and by the time I'm done, I'll know wtf I'm doing, and will be able to rebuild it better 
)
But I still want to mention that, although RM is a solid app and can certainly get you up and running, building your own apps isn't hard. It took some doing to build up a library for the core functions (turning on/off a single light, a group of lights, dimming and brightening, testing inputs, etc.), but now that I've got most of those... I just built a new app to handle contact sensors (see destructure00 post 13) to independently set devices and actions for Open and Close, including delays (eg wait X seconds before turning off), checking Mode (and allowing setting of Mode), and schedule times (eg only at night)... It also will check another app for scheduled light levels, and I plan to build into the system the option to manually override (if turned on by a Pico remote, don't turn off from a contact sensor).
It took maybe two hours to build and test. (Well... plus another hour to change from using "pause" to "schedule", so multiple opening/closings wouldn't stack on top of each other - but it worked with "pause".)
I didn't see where RM could delay actions. Maybe it can I didn't look hard enough. But, assuming RM can replicate what I'm doing in general, there's three big advantages to doing your own stuff.
First, obviously, simplicity. You can design the UI to match your needs, without extra features complicating the interface.
Second, it can greatly reduce the spaghetti nature of doing different things with the same devices. For instance, my lights auto-dim at night, while controlled by Pico remotes (and/or contact sensors, MagicCubes, and - at some point in the future - motion sensors). Keeping track of Modes, time windows, being triggered by schedule, presence, etc., etc., without creating conflicts is greatly simplified, when working with one set of functions. One set of functions can go through the check-list, as it were, regardless of where it's called from - no matter how a light gets turned on (aside from a physical switch), it checks if there's a scheduled light level (and temp color), and auto-sets it (and auto-reschedules automated events). That would be very very tricky in RM.
Third, it can make it easier to manage and track the routines, and know which to tweak when something goes wrong. Using the App -> Child app structure, all of my routine names begin with what it is - "Contact - ", "Pico - ", "Schedule - ", "Presence - ", etc. - and that's enforced in the code (it knows which child app it is, so it just checks the first letters, and if not already properly named, it prepends it). So, they're all grouped together by function, then sorted by [the rest of the] name (so, like, "Schedule - living room 7:30", "Pico - living room", etc.).
Obviously, if you need any tips, or even a copy of my code base, let me know.
(edit: @erktrek, this might be of interest to you too)
I have yet to automate my locks, but don't give up. If you give a crap about security, you can NOT just "automate them". You have to be careful and plan it out, but it can be done. Just as with internet security, I'm going to require of myself a dual-authentication system. If you have a garage, that's pretty easy (unless you want to automate the garage door ). [Unlock if BOTH] 1) Inside geofence, and 2) Garage door opens. In other words, someone would need to steal both your garage door opener and your cell phone (and know where you live)... Or car-jack you, but then you're pretty much screwed anyways. Alternatives to either of the authentications include having a key-ring fob (either BT or swipeable), hidden motion sensor (eg like inside a fake rock that you nudge with your toe on the way in), or even a hidden button. Even if someone "cases" you and miraculously notices the trick, it still wouldn't work without your cellphone, or whatever the second thing may be.
There's no need to give up basic security, but it does require a bit of imagination, and of course test test test before putting it into production.
edits: Clarity
3 Likes
Interesting. I haven’t built any SmartApps in ST and thought it would be pretty hard to do my own so have always gone with community stuff. Did you have a post or anything you read to start with that made you think “I can do this” and explained HOW to do it from the basics?
Haven't done any how-to tutorials. Maybe I'll try to get around to doing that, especially now that there's a documentation section on Hubitat. I suppose I'm confident enough in at least the basics to not worry overly much about embarrassing myself by telling people to do half-assed things 
My process is a never ending improvements and tweaks. I wouldn't consider myself a "pro" by any stretch. Lot of fancy stuff can be done that I haven't figured out yet, like building dynamic UI pages. (Hell, I just figured out I could use HTML in the UI, and Patrick (staff) was like yea no shit, nothing new there.)
I started with the UI. Best practices would be to flow chart out all the app, but screw that.... I get the UI working with what options I want, and let that drive the logic. I used little snippets from basic ST apps, and piecemeal them together, and just kinda figured out what worked and what didn't, and sorta reverse engineered the basic syntax. (Honestly, the ST documentation makes a whole lot more sense if you already know how it works 
)
The next thing was to figure out the "subscribe" function, for catching event triggers like a button push, including the "Initialize", "Update" and "Install" functions. Then I built on the logic for basic actions, like "If button pushed, turn on." Then next thing was to put those actions into discrete functions.
Once I had a couple similar apps, I merged then under one "parent", sharing those functions. If re-learning it over again, I'd do it the same way, but using child apps under a parent app is really important for how my stuff is now set up. But debugging parent-child relationship with a half-built app would be a serious pain in the butt, so I don't regret building two separate independent apps and then merging them, even thought it was a lot of "wasted" effort.
Schedules were the hardest part. First, schedules require a weird passing off between a couple or three functions, and still have trouble wrapping my head around it.
Second, there's at least a half dozen commands used to schedules events (RunIn, Schedule, RunEvery, etc.), and it seems there's a large variance between ST and HE for what works.
Third, passing variables using schedules is an art form, and you can't pass device "objects". So, it can be a tricky dance to handle function calls that are uniform between schedules, "subscribe" and other functions. Figuring out basic rules for what variables (and variable types) to pass to and between functions early on will save much headaches - changing up expected variables can require substantial rewrites. For instance, because of schedules, I've had to switch my primary functions from expecting a device object to passing a DeviceId, but once it goes through the top-level functions, it can then change over to passing device objects (so not to retrieve the device from the DeviceId over and over and over again).
edit: Speaking of variables, that's been the hardest part for me, and I still have a long way to go. Groovy arrays and variable types just don't seem to work like what I'm used to from other languages. But, I've managed with just a rudimentary tricks. I could probably streamline some code if I knew better, but whatever. It works. /edit
The ST documentation is super useful, but even ST's documentation isn't real complete, can be very cryptic, and what works in ST doesn't always work in HE. Ofcourse, I owe many many thanks to many people on the forums, but those who really are pros sometimes give just enough answer to make me crawl off and spend hours figuring out what they meant . (But, when I get stuck, I don't hesitate to ask, and without fail, I've been pointed in the right direction.)
Having "samples" in suite of different apps would give you a massive jump over just using their documentation and picking through ST apps. I'm more than happy to provide my code base.
edit2: As you've no doubt noticed, I do have experience in coding, but not professionally. Having familiarity with basic concepts of variables, functions, commands, if and loop structures, etc., etc., has obviously helped me immensely. But, if you don't have coding experience... You should get some, and no better way than to do it! /edit2
1 Like
Wow. Sounds like you doing a great job! And learning a lot. Well done.
Thankfully I do have a bit of coding experience from a few years ago (lol from a few years ago though - Pascal, C, BASIC, VBScript and a little bit of Swift).
Seeing your code base would be much appreciated. My hub is almost here so looking forward to that and getting started 
I've created a GitHub account. As a new user, let me know if I didn't do something right.
A couple notes... The apps are all built with Hue lights in mind. Dimming and brightening could be improved if using direct-connected bulbs. And "Alerts" is not complete. Doesn't work, at all. I include it only because it's referenced from the master app. I also plan on adding a "Presence" app. I just need to take the time to debug it, since it's a pain to test the GPS-based outcomes.I'm motivated to get that done, so will probably add it within a week or two.
And just to be on safe side... They're copyrighted, and licensed on the GNU General Public License version 3.
Wish you the best, and don't hesitate to ask me... whatever.
