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.
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.
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.
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.
You can “complain” here 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.
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…
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…
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.
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…
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
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.
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.