Going from Pico remote -> Lutron Hub -> Hubitat -> Hue hub -> Hue bulb -> response = ~750ms (3/4ths of a second). That may actually be on the high side for on/off, since this is this time between effective brighten/dim ("SetLevel") events.
This is most certainly faster than anything you could get using ST. Even with the best internet connection, in the same vicinity as the data center, you'll have 250ms just there and back.
Yes to the first; no to the second. As per ogiewon, Room Manager app (by bangali) can do this.
No, thank god! That's one problem with ST, where you've got "Scenes" and "Routines" and "SmartApps"... Just... why?! To do what you want, I'd think you'd be better off using the dashboard.
I really think you might be better building some of your own apps. "Routines" are klunky. "Modes" have their place, but more as a super-global variable, to change what happens rather than as a trigger. For instance, rather than having a "routine", just have the motion sensor trigger the light and music if it's after 10pm. "Keep It Simple!"
YES. Latency is more of an issue with ST than internet speed IMO. With ST, you are effectively going from tiggered device (sensor, etc) -> hub -> router -> modem -> some path to the remote cloud server(s) -> modem -> router -> hub -> triggered device (switch, etc), In HE, you go triggered device -> hub -> target device. Not much of an opportunity to experience latency there
As an example....I have a couple of lights that are triggered by doors opening. In most cases, the lights are on before I can even swing the door open far enough to see anything in the room. It's AMAZING. With ST there was usually a short but noticeable delay, and occasionally I would be in and out of the room before the lights would come on.
I was using routines in ST, and created the equivalent in RM. Instead of a "Goodbye" routine, for example, I have a "Mode - Away" rule that sets the mode to Away and turns everything off when my wife and I both leave. Same with "Mode - Home" rule in RM (which takes the place of my old "Good Morning" and "I'm Back" routines), and "Mode - Night" rule (which replaces the "Good Night" routine).
You mentioned that you have a lot of webCoRE automations...I had 70-something pistons on ST and was able to replicate all but two of them using RM. I counted the other day and I think I ended up with something like 130 RM rules. It takes a little different way of thinking for some using multiple rules with different triggers, restrictions, conditions, etc, but RM is very capable. It's not as "pretty" as webCoRE but after using it for a month or so now I actually find myself liking it better. I got to a point where I hated making changes in wc because everything took so long to load. Could have been my PC I suppose, but I have had no issues with RM.
As a side note, the only two webCoRE pistons I wasn't able to move to HE were just there to essentially forward web requests from outside my network to non-ST devices inside my network. So I was using them as a port forwarding service of sorts, which there are other ways to do. I found other workarounds for these and ended up just deleting them instead of trying to move them over to HE.
Tha is for the replies to everyone. I’m getting pretty excited now. HE has been dispatched. Hopefully it doesn’t take too long to get here.
@Eric.C.Miller - I thought it was just me that gets up to devices doing stuff they shouldn’t be! Recently I’ve got up to the kitchen Sonos playing at half max and lights are on. When I go to bed I do a quick check in ST app to make sure Lights are off, modes are correct etc. When I get up and see certain devices on I check in the history of that device and see they have been running since around 2am by WebCoRE pistons or ST apps that don’t even turn these devices on.
@Roguetech and @destructure00 - hopefully Hue sensors will be able to keep up with those sort of speeds.
Looking forward to making life simple and using native integrations and rules.
My WebCoRE pistons add up to around 60 but around 10 of them are for tiles to show devices on - not actually pistons to perform tasks - I look forward to seeing if I can rebuild them.
I assume I need the hub first before I can start building out rules in RM?
There are some specific RM ones too and you can get a feel for the hardest element of the change... the UI is nothing like WebCoRE. In most ways, RM and WebCoRE are building automations from opposite directions. RM is called "Lego like" for it's building block approach. This results in 2-3 Rules doing what one Piston will do.
Also, be sure to look at Simple Lighting and Motion Lighting tutorials. There's a lot of benefit to the focused/targeted approach on those apps. Unfortunately, I don't use them and some of my simplest rules in RM are "cluttering" the long list of Rules.
As I migrate a device, I adjust the ST settings and automations, including ActionTiles, to work with the device in HE until I can move the automation to HE. It is not a perfect or painless transition, but it is well worth the effort. HE respone is much faster than ST and 100% reliable.
I converted 2 months ago. Not fully complete - still have my Yale lock running under ST (using RBoys app/device) and my Nest stuff but that's it. Also my ring doorbell is triggered through Alexa instead of IFTTT thanks to @stephack's integration suggestion. One less cloud tie-in.
I'm waiting for the lock manager which is in the works. The locks do function with HE though if you need it.
The nest stuff is out of HE's hands, they HAVE a solution that a few (lucky) early adopters are using but are now awaiting Google's blessing for more allowed users.
I am really happy so far. I feel like I've regained some control and direction over my devices. I may even get a 2nd unit as a backup just in case.
As an aside another very cool use case for a 2nd device is if you have a large area to cover you can use the HE bridge app to manage devices past the "hop" limits of zigbee/z-wave provided your hubs are wired to the same subnet. I haven't done this but read about it in the forums.
Finally speaking of these forums - the community has been awesome (and patient!). Support has been great and responsive as well. Can't say enough good things about HE so far..
@arnb - thanks for the info. Lol they will probably be my first apps I get setup then.
By having the device in HE have you found them slower to react to calls to switch on/action being as your adding another layer to the device to need to perform more hops?
@erktrek thankfully I don’t have any lock devices. They are just way too expensive for my liking.
I look forward to Nest thermostat coming over but in ST I don’t control the Nest setup with Nst Manager. The main one I look forward to is Nest Protect.
Lol regarding a need for a second hub, I recently bought a new build house in the UK. They only get smaller so distance to cover isn’t an issue. Unless there is a set limit to the number of devices a hub can have attached to it, I don’t think I would need a second hub.
Nice price aside () a smart lock can be very useful in improving home "situational awareness" - getting alerted when the door is unlocked and by which code also triggering rules to set things like lights or modes. It's also nice to not having to hand out keys to everyone. Changing a code is easier than rekeying...
Assuming the lock manager will have similar functionality to RBoys excellent ST app you should be able to manage multiple codes and be able to schedule when they are active etc.
In the interests of spending all your money - also really recommend a video doorbell like the Ring..
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
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.
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.
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
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.
) a smart lock can be very useful in improving home "situational awareness" - getting alerted when the door is unlocked and by which code also triggering rules to set things like lights or modes. It's also nice to not having to hand out keys to everyone. Changing a code is easier than rekeying...
)
)
