Exactly. Matter will be great, like 2 year from now. But all your old investments will be hit or miss, depending on the manufacturer. And the likelihood if you have old devices is that they will not be supported. So you get to buy everything again and Samsung gets revenue from new licensing they were not currently getting with how easy it was to load up custom device handlers in Groovy.
There is one way to tell…
If you open the device in the ST app, click on the 3 dots and select Information. If you see the hub name under the light name at the top then it is using the local connection. Those would be the LAN HUE for device type in IDE. If you do not see the hub name then it is the cloud-to-cloud integration which means you clicked in the Link Account button. Those should be the Placeholder device type in IDE.
If those match up, you can remove the cloud-to-cloud integration and keep the local connection, if both show the hub name then I would assume they have changed something on the backend and to keep the new connection and remove the old one.
Or keep both. It is not going to have any effect except for the duplicate listings.
Some devices are going to be updated. The Philips hue bridge will be updated and it will bring in some of its attached devices. Ditto some of the Aqara hubs, which could be a more reliable way to use them in smartthings. but we will have to see exactly what happens.
There’s an active discussion thread on matter in this forum if you’re interested:
Don’t think it’s possible. The hub can act as a virtual matter device/adapter for existing devices maybe. THREAD/MATTER seems to be over wifi from the latest diagram I saw in the other thread. Wifi is terrible for battery devices at the moment. They’ll need a new wifi protocol possibly or just rely on hub+zigbee/ble for those devices to bring them into MATTER.
I don’t think it will solve the platform interoperability issue either. Where you might like some aspects of a rules engine in one platform and try to mix and match automation.
I think it’s more for device OEMs to be able to streamline production against one standard. Like USB-C cables where everyone conforms so it makes it easier for them to make things or get others making things.
In my case I’ve been expressing frustration because they have NOT met their promise of feature parity before sending Groovy to File 13.
Sorry for the delay, I already asked the team to get more info about it but I haven’t gotten any feedback yet. I pinged the again today. I’ll keep you posted
It’s possible, Thread is not Matter but just one of several possible protocols, another of which is WiFi.
A Matter bridge is not a “virtual matter” proxy: it is a matter device. The hue bridge will be one. Some of the Aqara hubs will be one. It’s possible that the new IKEA Dirigera hub will be one, but we are still waiting to hear on that.
A matter “bridge“ offers two way integration with matter. Samsung has decided that smartthings will have a one-way integration. You will be able to bring matter compliant devices into the smartthings app, but the smartthings hub will not be able to join other matter compliant apps.
and separately there is new WiFi technology which has much better battery life such as that used by the currently available Shelly motion sensor.
But most battery-powered Matter devices will probably use Thread which is comparable to zigbee in power usage, and Samsung has already said that Thread will be added to the SmartThings protocols. The SmartThings/Aeotec hub is already “thread-capable”—they just haven’t turned it on before.
we have been discussing all of this in considerable technical detail in the link that I already gave you, so I suggest that we take that discussion over there. You might want to glance through the thread to bring yourself up-to-date.
On a different note, does anyone know if the channel concept for public/production edge drivers will go away? Or if the hub will just look up/find things from a global registry? I guess samsung can do that for official things pretty easily in the app. The channel opt in process can be confusing.
Since the driver has to published to be installed, have a registry that the app can automatically lookup the driver by fingerprint. And in the app, give the user the option to select the driver rather than guess if the driver may work, install it and hope and pray.
Seems this has already started. Was right in the middle of the process of migrating some devices and the the header in the IDE Devices table just lost the ability to sort devices by different table headings.
I was sorting by ‘Type’ to workout which ones are running edge drivers but that ability is gone. I tried a couple of web browsers and it’s the same in all of them.
I’m a multiple browser tab kinda person and have some old IDE Device tabs still open where the up/down sorting arrows are there. Hit refresh and they are gone.
The ability to sort is still there on the tables for Device Handlers and SmartApps.
Doubt they’d put in the effort to do that. Works on my phone. I double tapped the header and I can sort.
More of a cockup than anything in the table. Tried IDE in several browsers and no longer can sort Devices but others ok.
My experience has consistently been that the page loads and you can see all the device entries, but it takes a bit longer for the sort buttons to appear. I’ve been using it extensively the same way you describe over the last few days as I work to clean out custom DTHs and replace virtual devices with edge-compatible versions.
The screenshot below is from a fresh browser tab I just loaded on a laptop I wasn’t previously logged in on.
I will log out and log back in again and see if that fixes it.
Also the number of ‘entries’ at the bottom of the page is missing. Strange this is happening only on the Devices tab.
I just refreshed the page and that too is missing when the page first loads but appears with the header buttons; at the same time the rows in the table expand from single height to double height.
I’ve written a few DHTs and smartapps. I’m pretty sure most of my DHTs will not migrate. I have custom stuff for Insteon, Flair, Nest, Inovelli, etc. I’m not too attached to any one way of doing what I did, but I can’t seem to find a good reference on how to migrate from Groovy. Can someone point me to a how-to for migrating my custom DHTs and Smartapps to whatever is the right thing? Edge, Rules, Scenes, CLI, Lua, …? I can’t judge the need for the transition, but I am pretty confused as to what I should do to keep my current work. I did a search on migration, but there are so many results it is hard to understand what I need to do to migrate. Please help.
Actually if I leave the page open for a while they both turn back up. If I hit refresh they disappear then reappear after a number of minutes.
Wonder why there is such a delay?
Any tips for how you got it to use the edge driver? I’m trying to do the same thing and it just keeps re-adding using a groovy DTH. I’ve enrolled in the beta channel and installed the ZigBee Button. Not sure what I’m doing wrong. TIA.
Try deleting the dth. Had an issue where a bulb dth was blocking a edge driver from installing.
That is how it has always been for me.
You are incorrect on number 1 and for number 2 there is a bit more nuance to the answer.
For number 1, it is not just custom capabilities. There are devices which have been created by Smart Apps and there are devices which SmartThings has dropped, or are no longer supporting, all features of; Samsung has begun a list of those devices in their FAQ.
For number 2, the Alexa integration being switched away from Groovy is not relevant; if you change the underlying device type, whether the device is recreated or not on Alexa is pretty random at this point. Go to your setup and change a device on the SmartThings side and then check a few hours later on Alexa, you will find that devices are rediscovered as being new. Do you really think that changing the driver is going to have zero influence?
The FAQ on the device changes is pretty lackluster. What should Samsung/SmartThings have done?
Instead of supplying a FAQ with a set list of the devices, Samsung could take the incoming feed for devices, generate a list of all known devices, and then match all incoming device commands against supported drivers.
For Z-wave and Zigbee? That would be trivial.
For other devices? Samsung had to write a driver for those integrations; I would expect someone had to write test cases to check their work.
Samsung has done a poor job communicating any of these changes to SmartThings users. If I look in “Notices” in the SmartThings app? There is still zero communication about this change. You have users which have been reliably using SmartThings for years who are still in the dark about the changes being made.
Is the effort that has gone into this change the best Samsung can do as a company?