I am a little confused as to the implication for me an an end user of the “groovy is going” message.
Like many others who have been using for some years I have a number of non natively supported devices, like the Fibaro SmartImplant and the Sonoff Button. These are using device handlers kindly provided by developers on here, and some have interface issues in the new OneCore app, but I’ve found that using the simulator in the IDE I can get round bits, and everything just works.
So when Groovy is dropped does that mean all these custom Device Handlers will stop working? If so do what can be done to migrate these so my world and many others I’m sure, doesn’t just stop working ( exaggeration! ) Is it just a wrapper around the code, or totally rewrite and how complex is that for even the smallest one at say 200 current lines?
Thank you.
So is there a “Request to convert” thread or a “Old Handler - New Handler” thread?
Guess the number of people so far with access to the new dev environment and experienced is much more limited than those currently developing and maintaining the groovy based stuff.
Any idea if Samsung are going to provide an “exposure” utility either in the IDE or App to tell us users where they are using unsupported elements well in advance so the work to migrate etc can be planned, or do we expect that the notification type messages like we got about moving from the classic app will be all that will be provided?
To my knowledge, currently there is no new development environment for Hub-Connected devices, like Zigbee and Z-Wave. Until that is announced and opened up to developers, no one knows what to expect.
Yes, but so will the stock handlers so something will replace them. I don’t have any insight into what it is.
I’d be surprised if it wasn’t something we could relate to though. When you look at the lifecycle of a Webhook app you see a lot that is recognisable from a Groovy SmartApp. Device integrations will still have components, capabilities, attributes and commands and there is still a need to be able to command the hub to speak Zigbee and Z-Wave and hopefully there will be slightly more versatile TCP implementation.
What I would be thinking about is what custom DTHs I am currently using, and why. Have they been updated in the last year and if not, why not? Who is going to rewrite them? That sort of thing.
Maybe they’ll just discontinue Zigbee and Zwave support entirely now that they’re out of the hardware business and smartthings will be only for Roh Tae-moon approved c2c integrations with your bespoke refrigerator
(This post is sarcasm, or at least I hope it still is in 12 months)
Actually, they will need to be rewritten to use the new API. The new REST APIs aren’t part of a particular language. E.g., updates ones could still be Groovy if you have the ability to host it somewhere.
For cloud devices. No one knows about hub connected devices which are the majority of custom dths.
We simply don’t have an answer as to what is going to happen. And the lack of transparency is the biggest problem with ST
