There are a lot of threads which are just too reliant on the old groovy architecture to be helpful now, and which will probably be confusing to people in the future.
Should we archive them in the archive section of the forum?
Delete them all together?
Mark them with a [deprecated] or [pre 2023] or something similar?
I’d hate to see future readers slog through 150 posts that are no longer relevant.
On the other hand, some of the stuff about devices and DTHs could be useful to people creating new edge drivers with that same device.
I contacted @nayelyz several weeks ago about this topic. Her response:
Thanks for the suggestion. I’ll share it with the internal team to see if we can do this. I think once the complete sunset comes, we’ll have less workload.
I liked the OBSOLETE tag @krlaframboise has been using and I also think it’s one that will translate into multiple languages well, so that’s what I’ve started using.
Note that at present, I am not myself marking any topics where I know the developer is actively working on edge driver versions. That way the developer can decide for themselves how they want to preserve earlier conversations and maybe update the first post of a thread with the link to the edge Driver instead. Whatever they want to do.
This is going to take a while, so don’t expect everything to be marked right away.
I’m starting to mark some of the smartapp topics. If you are the original author and want it marked a different way, just go ahead. I’m just marking them as a convenience so fewer community members get confused.
Here’s what I’m doing so far:
If it’s a fairly simple groovy smartapp and it’s also using Groovy DTHs and it’s either quite old or has been dormant for a while. I’m just marking it OBSOLETE.
If the main thing that’s being shared is a script that runs on another device, like python or something, and the integration through smartthings is just done with a virtual device, then I’m marking it NEEDS UPDATING because the main issue is that the instructions tell people to create a virtual device through the IDE now they’ll need to use one of the new architecture methods.
If you are one of these authors, here’s the link to the new 2023 FAQ on creating virtual devices:
if the author is someone like @rboy who has already told the community that they are working on versions for the new architecture, I’m not changing anything on the title for now. I assume that that developer will eventually update the first post in that thread, or close it themselves and replace it with a new thread.
if the author is someone like @heythisisnate (for Konnected.io ) who has already published the new integration method hopefully they will update the first post in the thread, but I will try to add a linking post at the end if they haven’t done that yet. I may Mark these NEWER VERSION AVAILABLE when that’s appropriate.
Again, this will be a slow process, so if there are any smartapp authors who want to go ahead and mark their own threads, please do so.
Given the amount of forum traffic on ‘lock’ support with the recent change to rBoy SmartApps. It might be time to update the API capability lockCodes to the 2015 forum update which defines the specification. Maybe the ink was slow to dry?
