Announcement | Changes to our Legacy SmartThings Platform

Project CHIP Is intended to create a home automation standard for WiFi and other IP protocols similar to that of zigbee and Z wave so that any Project CHIP-certified device would advertise what it is and accept a set of basic commands. So it would say “I am an on/off light switch.” “ I am a multi level dimmer switch.“ “I am a thermostat.“

That’s really all there is to it. It’s just intended to make it easier for hubs and apps to work with IP protocol devices from different brands without having to have essentially a new set of commands for each one.

In that sense it’s similar to the new smartthings API which allows device manufacturers to add their devices to the smartthings app.

But it doesn’t do any more than that. It very specifically does not create a UI for project CHIP Or its own cloud platform. It does not compete with existing home automation systems, whether it’s apple’s HomeKit or Samsung smartthings. It just standardizes one level of communications with Wi-Fi and some other IP protocol home automation devices. (Plus adding a bunch of security features.)

So it’s definitely interesting, and probably helpful to end customers, but doesn’t really change the landscape of market offerings.

See the following thread for more discussion:

Matter - smart home connectivity standard (formerly Project CHIP)

4 Likes

SmartThings has been a “hub optional” Platform since 2018 when the new V3 app was introduced, and indeed, it is likely that over 90% of the current app users don’t have a hub. That’s because the same app is used for Samsung brand smart appliances and smart televisions.

Hub-optional configurations can already add any of the cloud to cloud integrations in the new app. Really the only thing they can’t add are hub connected zigbee and zwave devices. But there are still plenty of light switches, relays, pocket sockets, air conditioners, cameras, video doorbells, voice assistants, etc. that they can add if they choose.

The main issue with Wi-Fi devices is that they use a lot more power than zwave or Zigbee, so you tend not to see small battery operated sensors based on Wi-Fi. And it is only recently that we started to see Wi-Fi based locks.

However, there are a few brands like Neo cool cam and globe electric Which have introduced Wi-Fi based battery operated sensors in the last year or so. These tend to need a battery change every three or four months, though.

But project CHIP is not needed for someone using the smartthings app to do without a hub. The great majority of smartthings customers already are in a hub optional configuration. :sunglasses:

2 Likes

Are there any wi-fi iot/hone automation devices that truly run “local” right now. The Wi-Fi devices i am familiar with are all controlled by the vendor’s cloud even if you are physically in front of the device on the same wifi network.

The hue integration might be hub to hub over local Wi-Fi but the actual devices are not Wi-Fi they are zigbee.

That’s a great vision/ sarcasm/ no hub needed but no local control anything? While some things might need to be cloud controlled, or may be best controlled in the cloud, some things are best controlled locally.

1 Like

Sonos is WiFi and runs local. Maybe wemo too?

Is this the “topic” where we should complain about google integration? I remember that I saw comments that user can’t choose which devices to show from ST to Google. I would like to add&ask that why my life360 presence sensors from ST are not showing in Google? Everything else is there but those 4 presence sensors are missing.

2 Likes

You can “complain” here :slight_smile: Presence sensors are not part of the features Google support so in this case we cannot add it until Google provides support for it. They have recently added more sensors but not yet presence.

1 Like

Can you provide any type of timeline for the replacement of the groovy DTH for hub connected devices? Even something vague like 3-6 months, 6-12, etc. would be helpful?

If all the custom DTHs for hub connected devices are going to have to be re-written in a new language then modifying them now to make them work with the new mobile app seems like a complete waste of time…

9 Likes

so i have some custom apps in the IDE that connect to WIFI 2 IR devices in my home by IP, which i use momentary button tiles to trigger them so i can control old blind/lighting systems that use IR. will i be still able to use my custom apps and virtual buttons / momentary button tile ‘things’ ? if not this breaks basically half of my smartthings set-up.

does Hubitat let you run custom code etc, and i can integrate it with smartthings?

it just seems like this migration is going to break everything for me, so no point in even staying with smartthings anymore…

1 Like

That’s the conclusion I’ve come to, as well.

1 Like

You can still use groovy. It’s not a waste of time to update your codebase.

You won’t be able to use Groovy code once they implement Phase 3.

I personally think updating code that’s only going to be usable for 3-6 months is a complete waste of time which is why I asked for a timeline…

4 Likes

You can still use groovy, or any other language that you want, but it won’t be hosted in the smartthings cloud. You would have to host it yourself.

2 Likes

Integrations for the developer workspace can be written in groovy

1 Like

I’m referring to DTHs for Hub Connected devices and I’m pretty sure hosting them yourself isn’t going to be an option so if that’s the case, all of those Groovy DTHs will need to be re-written in whatever language they’re switching to…

I could be wrong and I’m hoping I am because having to abandon or re-write all the z-wave DTHs I’ve written over the past 4 years would really suck.

7 Likes

I’m referring to hub connected DTHs which currently have to be written in Groovy, but they also require the use of the IDE so that most likely won’t be possible once the IDE is retired…

3 Likes

There will be a solution for hub connected devices before the IDE is retired and my understanding is you will not have to throw out all your groovy code

@jody.albritton please clarify if you’re allowed to

2 Likes

Pretty bad news for me. in Samsung app about half of my devices are not working at all, while all are working flawlessly in Classic app. Mostly thermostats. Neato Botvac device handlers, Locks, all that shows as on/off switch in new app or just unable to run at all. So this move spells the end for my automation here. If I am forced to re-do everything then I am moving to Hubitat, that looks exactly like it was build by ex-Smartthings ppl.

8 Likes

Just a quick note to say I use a couple of your handlers and they are ace, thanks for all of your hard work!

5 Likes

I posted in the Other thread.
After the migration I noticed certain functions not working as they were in Classic. My Rachio has a pre-programmed time to run. However the New ST app never showed them turning OFF

Also when I leave the house in the morning…i noticed one of the doors would be unlocked.

My new automation in the New ST app for the waterfall to turn On doesn’t work as well.

I will be monitoring…

I miss the Classic app

1 Like