.. also in defence of Hubitat There is an aspect of my suggestion to use ST as a peripheral that doesnât sit well ...
Suggesting itâs useful for the cloud integrations that ST can provide (if HE doesnât) in a way negates the local model that HE performs so well. Itâs likely that control of ST devices requires cloud access, at least for ST to complete and so you start to introduce those dependencies on the ST cloud again. True HE can have similar issues with say IFTTT but becoming decoupled from this for your home automation implementation is a great objective.
Absolutely it can only be done through the ST cloud. And, as long as one is integrated with ST that brings their cloud into the picture. There are also many good integrations that use the cloud, and we aren't averse to supporting them as time goes on. But, people should have their eyes wide open about the implications of it. Alexa and Google Home are two good examples.
We all use the cloud for many things, for hub registration, for updates, for Dashboards, etc. etc. The main thing about local is to get your primary core automations to run locally, and to keep on running irrespective of the cloud. You may not know what's happening at your house if the internet goes down when you're away, but the hub should just keep on doing its thing. And it does.
Agree 101% on this .. itâs essential that you are in control of your home for functionality and security purposes without the Internet being required.... and that is a fundamental design failing of many other systems.
I even try and go one stage further and ensure all key features can operate even if my controller or network fail. Lighting, heating, security, audio visual etc. Islands of functionality enhanced by smart integration.
When your away and your family canât turn a light on by the switch or the TV remote doesnât work then the whole smart home experience is instantly alienated with the family .. weâve all been there Iâm sure...
Well...maybe you could expand the app to tackle the reverse, turning switches on or off based on mode (i.e., allow bidirectional "snycing" of the switch states, useful if you're, say, using another platform and syncing mode via virtual swithces...and also because I'm not sure what would happen if one mode switch is turned on, then at some point a different mode is selected via the regular/non-switch method, and the previous mode switch is turned on again).
If this is already handled by the new Mode Manager and/or yours, then nevermind. (And if it really isn't but is a good idea, I'll probably be able to say "nevermind" in a firmware update or two anyway. )
I could, but if there's a way to do it without creating a rule for each mode/switch, I haven't figured it out. I'm a former webCoRE junkie trying to learn RM and...I'm not there yet.
EDIT: I just realized the lighting apps can also do this (turn on/off switches with mode changes). I used Hubitat Simple Lighting and still had to create one child app for each mode, but it was probably less clicking than anything I know how to do in RM.
For the very real request of 'product road maps', and as a guy who has to manage several of them, I hate them. They are not agile, they are waterfall and do not allow business to pivot based on actual needs and often anger more than they placate.
I think the HE guys do a pretty good job of telling us what's upcoming.
)
