I'm a long time ST user and am just now trying out Hubitat. After a lot of persistence, I've finally got it set up and created my first simple automation where it is controlling a light triggered my a motion sensor in ST.
Before I start creating a bunch of automations I'm wondering if when ST pulls the plug on Groovy, will this integration stop working entirely? It seems like that would be the case but I'm not finding a lot of discussion about it.
Also is it possible to view ST modes in Hubitat? I see Hubitat has a Mode Manager app and a mode component in Settings. I've also enabled the "push mode changes to server hub" on the ST side of HubConnect but I'm not actually seeing any of my ST modes in HE.
Unless it is "ported" to ST's new architecture, it will indeed stop working when ST pulls the plug on their current Groovy IDE. I haven't seen an exact date for that, except it seems they're doing things that are in and near the phase of their multi-phase plan where that is supposed to happen. (In my opinion, they still don't have good docs on how devices are supposed to work in the new environment. They do have some examples for SmartApps, and I don't doubt that there may be something I just don't understand here, like maybe the distinction is now blurred. It seems like such a move would be premature given the current state, IMHO, but I guess I'm here because they don't have a history of making good decisions.) I wouldn't count on HubConnect being ported given that the developer no longer uses Hubitat as his primary home automation system (though isn't totally gone, I don't think), but I can't speak for him.
Anyway, you can keep using it indefinitely--until then. Just make sure you're using HubConnect 2.0, as 1.x won't work with the new ST app. I'm pretty sure modes are supposed to sync, but I'm not sure if I ever tried that on HubConnect or not. You do have to have modes with matching names created on SmartThings (or Hubitat), as it will not create them for you and name is how they match. I do have it working from Hubitat to Hubitat and used to have it working from Hubitat to ST, but I can't remember if that was pre-HubConnect. (Very early on, I used a workaround: virtual switches changed my modes and the modes were changed on both platforms based on these switches. You could still do that if nothing else works. I still do this as an "add on" to my existing mode automations since it facilitates voice control for manual changes. Just one idea!)
I'd be curious to know what system the dev is using as I'm hesitant to migrate something that's going to break so soon. Maybe I'll switch to that one haha
I am using HubConnect 2.0 with the new ST app.
If I'm understanding correctly, I would just need to create matching modes in Hubitat and then ST would activate them appropriately?
HubConnect's principal developer (@srwhite) indicated a while back that he was primarily using Home Assistant. I don't know what his plans are vis-a-vis HubConnect. But the bigger uncertainty for HubConnect is when (not if) the ST IDE will no longer be available.
So if your use of Hubitat is heavily dependent on a cloud integration with ST, I'd suggest sticking with ST because there is a lack of permanence to the ST IDE.
Most of us who have been using Hubitat for 2+ years have moved entirely away from ST (or whatever other platform we used previously). Hubitat has currently maintained integrations with platforms such as Home Assistant and Node-RED, making it easy to add support for devices/integrations not natively supported by Hubitat.
Sounds like you got it! It appears that he has mostly switched over to Home Assistant (but is also interested in a forthcoming project from some current Hubitat users and former Community members). I've played around with Home Assistant a lot and actually used it myself before Hubitat, but I much prefer Hubitat for both devices (Z-Wave and Zigbee are well integrated into the platform) and automations (I find apps easier to set up, both built-in ones and custom ones, and have familiarized myself with the development environment for the latter...which I also managed to eventually figure out with AppDaemon on Home Assistant, never got YAML working, and see that they finally have a "Blueprints" feature that looks similar to apps/SmartApps, so that should help people like me, too--but I'm still pretty happy here ).
Hmm interesting. My other problem is I have a ton of devices that are super old. I'm guessing I'm out of luck with pairing early ST-branded motion and flood sensors over to HE if I decide to move away from ST all together?
Nope! I have a first-generation SmartSense Motion Sensor (the actual first generation: AA batteries and a micro-USB port from the Kickstarter era, though I bought mine shortly after that; lots of people seem to think that whatever generation they happened to have encountered first is the "first" ). It works fine with Hubitat as of one of the earliest Hubitat hub firmware updates (it did not originally, in case you are super-into historical detail...haha).
Hubitat's founders were all ST users. So, in general, ST-branded zigbee devices work well with HE. ST-branded WiFi devices will not work with HE (unless you use HubConnect). If you have a lot of 300-series z-wave switches/dimmers, I would recommend considering replacing them over time for a better automation experience.
Fundamentally I think the motivation to migrate HubConnect's Remote Client to the new architecture, especially as a "pioneer," is exceptionally low.
Neither SRWhite nor I use ST any more, and haven't for more than a year. I have mine powered right now, but only to provide support to Community members. The moment Samsung closes the IDE, I'll be powering it off forever.
However, the API for any HubConnect Remote Client is documented and thus anyone who wants to, can tackle the migration to ST's next iteration... or a Remote Client for Vera or ??? your fav.
All of my 1st gen ST Zigbee devices work well with Hubitat, as other have already mentioned. I did initially have issues pairing some of the devices if Hubitat's Zigbee radio was set to a high numbered channel. Once I changed the Hubitat Zigbee channel to 20, it has been smooth sailing. I was able to pair the 1st Gen Motion sensor (same one @bertabcd1234 mentioned above), the 1st Gen Multi-Sensors (the ones with AAAA batteries), and even the original ThingShield (although this one still requires my custom HubDuino drivers to work with Hubitat.)
The reason I started looking for a platform other than ST is because several of my more complex automations just stopped working without any explanation. Once I started recreating them they would work again but who knows for how long. Such a relief to hear that all my old devices can be re-paired to Hubitat.
Ok one more question, why is there no "and" available here as an option instead of "or"? Am I missing something? This seems like something that it should be able to do.
Because those are events not conditions.. You are telling your RM rule to pay attention to those events when they occur then in your conditions you would define which device states etc you are testing for..
It's been a while since I used RM so I hope I am getting this right!
@erktrek's explanation is spot on. Triggers in Rule Machine are events, which by their nature are momentary and for a given device exclusive, i.e. the same switch cannot simultaneously turn off and on.
However, RM also lets you set CONDITIONS (something closer to a state). Conditions are evaluated as part of the action of a rule.
).
). It works fine with Hubitat as of one of the earliest Hubitat hub firmware updates (it did not originally, in case you are super-into historical detail...haha).
