It’s valid YAML and indeed # comments it out. So it won’t be read when the hub looks at matching drivers for a device.
The general rule of thumb is that if you’re device is using a custom DTH currently, then you should find a custom Edge driver or expect some impact after Sep 30th ranging from minor loss of functionality for the device to it not working at all.
Quite probably. It isn’t actually clear where the Routines limit comes from. The guardrails and rate limits documentation is gloriously vague and exceeds the API Reference in its ability to pull terminology out of the air. It is also contradicted by other documentation.
I saw this coming. It is like the app migration where the users who migrated nice and early, as asked, were kicked in the teeth by seeing those who left it to the last minute, or beyond, have the migration done for them and even get extra functionality, and then given another kick as the deadline was extended by months.
I wonder if the bugs in Smart Lighting will be replicated.
Does this mean the end of Homebridge? There must be thousands of users who currently enjoy the benefits of SmartThings and Apple Homekit combined - it gives us more choice for devices and control whilst still having a smartthings system.
Often like in my case, its quicker and easier to use the Apple shortcut on my phone than it is to open ST and find the device - which is made slower by the constant “Network Connection” pop up that seems to be every time i use ST app.
Webcore is another example - will that be broken too?
I am sure you have some big plans but I think alot of people will unfortunately migrate over to Home Assistant.
On Sept 30 I will wake-up to discover what functionality is lost/broken for my 3 hubs in 3 remote locations. Some devices will need to be replaced, some features will be lost forever (myQ, rboy apps), the massive interconnected web of logic that was built through a patchwork of apps, device handlers, and newer routines will all need to be rebuilt and tested. I won’t be able to look at the old apps or drivers to compare since the IDE will be gone. I won’t be able to have any side-by-side comparisons to test if my new logic is working like the old ones did. And I have to do that for 3 houses in three parts of the USA all on one day. All that effort just to get back the same functionality I had on Sept 29th.
SharpTools will continue to work after the migration, and their Rules Engine looks to be the best/easiest option for complex automations. They now have an option to connect through the new API, and have said they’re working on a migration plan of their own to move existing customers from the old to the new API.
SmartThings is creating drivers to replace the stock DTHs, so the test would be to look at your devices that are using custom DTHs and figure out whether they’ll still function on one of the stock DTHs. If not, then you’ll need to figure out a different solution.
First, the good news: Homebridge itself exists independent of SmartThings so it’s not going anywhere.
The current SmartThings/Homebridge integration, though, is a smartapp written in groovy, so the bad news is that, yes, that particular path will stop working when the SmartThings groovy cloud goes.
(And unfortunately the way Samsung is going to implement Matter will NOT let you add the ST hub to the Apple HomeKit app, so that won’t be an option.)
So someone will have to write a new integration between ST and HomeKit.
There are several ways that could be done.
@tAustin has done a really interesting integration to MQTT. You could use that and an MQTT broker to get to Homebridge, for example. But it would be more complicated than a regular ST/Homebridge integration.
If we are going to get another ST plug in for Homebridge, somebody is going to have to volunteer to do that work, and I haven’t yet heard of anyone who is. And I would expect it to take several months anyway.
Not the answer you wanted, I’m sure, but I do think a year from now there will probably be a new ST plug in for Homebridge, but of course no promises.
Also, I see that the provided link for Edge drivers goes to the ‘Main’ gethub branch and not the ‘Production’ gethub branch. To my understanding, only the uncommented devices in the fingerprints file of the ‘Production’ branch are eligible to be re-joined as an Edge device. So if that’s still true, then I take it that only those devices uncommented in the ‘Production’ branch will be migrated from a DTH driver to an Edge driver by September 30, correct?
I just looked at the remaining DTH zigbee & zwave devices I have connected, and all of them are not commented out on the ‘Production’ branch so it looks to me like all of my devices should be fully migrated to Edge by September 30.
The only remaining legacy DTH driver I have is the SmartThings SmartWeather Station Tile driver which I’ll apparently eventually lose with all its Automations at some point. Either by 30 September, or sometime before the IDE is finally depreciated in early 2023.
Since the vast majority of people who use the SmartThings app now do not have a hub at all, how can they use Virtual switches once the Groovy cloud is gone?
You can have a nice “hub optional” ST set up with Samsung smart tvs and appliances, a Hue bridge, Lutron or Leviton (WiFi) switches, a Ring doorbell, an Ecobee or Nest thermostat, Meross smart plugs, and other cloud to cloud integrations.
And currently you can use virtual switches to extend that via Alexa routines to other devices that don’t have ST integration.
So will those of us without hubs still have virtual switches come October? And will those virtual devices be able to trigger Alexa routines?
@JDRoberts I’m currently using one of the virtual switches that can be created through the CLI. It appears to be a cloud construct - routines that include it switch to non-local. Hopefully we get a better way to create them before October though.
That really does need addressing, as does an answer I made elsewhere which overlooked the obvious pitfall. There is a ‘virtual switch’ Edge driver, so on the face of it a stock virtual switch DTH to Edge migration can occur, but that’s only any use if you have a hub.
I suspect the solution will be the virtual devices that have come to our attention via the CLI but have yet to be introduced to us and seem to be missing key elements (cloud v local, and how to map commands to them). However those using them need to know what they need to do.
BTW, if the answer for virtual switches is that you have to buy a cheap Android tablet so you can run the android version of the ST app, I’m personally ok with that as long as there’s a virtual device that can trigger an Alexa routine.
(You can usually find a tablet for under $50. Obviously it’s an additional cost, but not outrageous. Or complicated.)