Sounds interesting, but the only things is that webcore will only works on the HE side, so if everything is mirrored in ST hub, I wont be able to use webcore with ST devices unless its virtual devices… If I understand…
I would like to be able to get devices from ST to HE to be able to use it with webcore without transfering everything…
That’s exactly what the multiple projects that have just been mentioned will do. They all do it with proxy devices which are virtual devices, but may be handled a bit differently on the two sides. But you don’t have to transfer your devices to the other hub for network communication.
So far there are two community – created projects specifically for communication with hubitat, and you could also use MQTT since there is now an edge driver project for that and Hubitat already supports MQTT.
So there are at least three existing methods for replacing the old groovy hubconnect in a way similar to what you described. Each has different features and requirements, so you’ll need to do a little research to see what will be best for you.
Hubithings is probably your best bet for that. It will clone existing ST devices across the cloud to an HE instance as virtual devices on that side. Then you can use Webcore to control those virtuals.
Mira is designed to go the other way. Take real/virtual HE devices and clone them to ST virtuals. You could create routines between the Mira managed ST virtuals and your real ST devices (for instance, for switches you could use a routine to mirror the behavior between the real switch and the Mira virtual, and that behaviour would then be replicated across to HE), but its more moving parts than Hubithings would require. OTOH, Mira is 100% local hub to hub direct.
HubiThings Replica will do exactly that. If you have questions on how it all works, please feel free to post them in the following thread and we’ll be happy to answer them. It is currently in beta, but release and inclusion in HPM is imminent.
There has to be some serious reason why they are doing it OR they are using $40 developers and winging it. The entire migration strategy is simply: a joke. Critical smart applications like smart lighting, better lock management, etc. should have been the first step rather than devices. A substantially better routine module too.I am okay as I knew about 12/31 and got everything moved out but now not having the power of Webcore is really hitting me. I have like +50 routines with no way to group them, tag or categorize them and over 40 virtual devices. Simply put - very badly done.
Have you used it? Wondering about the cycle on and off. It’s not quite clear how it works based on the description. Does this turn on all the lights I select for the chosen time, all off, then all off again? Or does it switch between them?
Also unfortunate you can’t use sunset or sunrise. Big difference in the winter when it’s dark at 4:00 versus in the summer and it’s dark at 8:30.
I do have an Alexa or two around the house, but I’m mostly a Google Home user, so haven’t done much with Alexa automation. Can you automate Alexa to turn on/off guard when smart things registers away (virtual device or otherwise)? Or does it require verbally telling it to activate/deactivate? If the latter, I just don’t think I can get my family to do that.
yes, you can automate it, but it requires some work arounds. I have a virtual contact switch created in smartthings that turns on/off based on our Goodbye and I’m Back routines. Then in Alexa Routines you can create a routine to arm alexa guard based on that switch. But they don’t let you disarm it via that option in Alexa routines. Instead you create a custom action in another routine that mimics saying “Alexa, i’m back” based on the switch