The greatness of smartthings for tinkerers was that even if you aren’t an official developer, you can make custom stuff tailored to you and not have to have it get approved by smartthings. The direction this seems to be going in is requiring a developer account, which I would rather not do. This is going in the direction of wink… closed off and not tinkerer friendly. Maybe a JSON ide could solve this?
I had the same hangup until someone else pointed out to me that the language of the developer page is stronger than the actual check. Currently, anyone can register as a developer. Just make up your own organization.
Who says it’s stable??
What are the implications for ADT/Smartthings hub and connected devices?
Where does the “Connected Home over IP Project” or whatever it is called fit into the present and future situation for SmartThings?
Doesn’t it include Google, Amazon, Apple and Zwave and the entire Zigbee Alliance, working with Samsung and others?
Isn’t Google Home’s most recent app upgrade starting to look, at least cosmetically, as expansive as SmartThings’ app?
I don’t know the answer, but I have to ask the question:
Isn’t it possible that the direction in which these companies including Samsung, are now moving apace, create the possibility that they may make the SmartThings hub superfluous for new adopters?
Please don’t shoot the messenger - I’m just asking.
I don’t know the answer, but the thought must be crossing some minds. Not just mine.
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:
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.
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.
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…
That’s the conclusion I’ve come to, as well.
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…
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.
Integrations for the developer workspace can be written in groovy
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.