Proposal: Moving Towards a Unified, Community-Driven SmartThings Edge Driver Repository

Devices & Integrations
, , , ,
1

Hi everyone,

I’ve been thinking deeply about the current state of our SmartThings Edge community. We have an incredibly talented group of independent developers who have spent countless hours creating amazing drivers, adding advanced features that go way beyond the stock implementation, and helping thousands of users.

However, as the platform matures, we are facing a structural challenge: fragmentation.

Right now, our ecosystem operates in isolated “islands.” If a user buys a specific smart device—whether it’s a popular Sonoff switch, an Aqara sensor, a Shelly relay, or one of the millions of different Tuya devices with their massive “explosion” of distinct fingerprints—they have to manually hunt through various forum threads, find specific channel links, and test different drivers through trial and error. Even when dealing with officially WWST-certified (Works With SmartThings) devices, the stock driver often exposes only basic features like simple On/Off, leaving advanced hardware configurations completely locked away.

Furthermore, if a brilliant developer decides to step away from the platform, their driver becomes orphaned, leaving users stuck with code that might break in a future hub update.

The Home Assistant Parallel (And Why the Stock Drivers Fails Us)

If we look at how platforms like Home Assistant handle this, they don’t rely on individual developers hosting their own separate packages. Instead, they use a centralized, open-source model (like zigbee-herdsman-converters for Zigbee2MQTT). When a developer uncovers a cool new hardware feature or fixes a bug, they submit a Pull Request to a central repository. Once approved, that fix or feature rolls out globally to everyone.

Technically, things could work exactly like this today through the Edge Drivers repository that Samsung already hosts on GitHub. However, the reality is that the official repository functions more like a closed, rigid system designed to check off the bare minimum baseline for WWST compatibility. Samsung and certified manufacturers seem content with drivers that only support basic, generic functions (like simple On/Off or default dimming), leaving advanced hardware features completely ignored in the stock code. Since the official channel isn’t set up for true, fast-paced, community-driven innovation, we need to build our own.

Why This Works Professionally and Logistically

  1. Drastically Reducing Developer Burnout: Currently, our top developers are solely responsible for answering every single thread, updating code, and manually adding every single new fingerprint users request. In a unified repository, adding a new fingerprint or a basic sub-driver becomes a true community effort. Anyone with basic git knowledge could submit a PR for a new fingerprint, freeing up our master developers to focus on core engine improvements.
  2. Ending the “Reinventing the Wheel” Cycle (No More Duplicated Effort): Right now, we have multiple talented developers spending valuable time writing separate drivers for the exact same hardware endpoints. Instead of having three or four different versions of a driver for the same Tuya or Sonoff device scattered across different channels, a unified repository ensures that all brainpower goes into making one definitive driver the absolute best it can be. Exceptional custom features created by different authors would live together under the same roof, rather than forcing users to choose between Driver A’s or Driver B’s.
  3. A Single Access Point for Users: Instead of managing dozens of channel invites, the community would have one single, unified “SmartThings Community Drivers” channel. One click, and the user has access to a curated, continuously updated library of logic-separated drivers (Sensors, Switches, Lights, etc.) or even specific drivers dedicated to a unique device or manufacturer when that specialized logic makes sense.
  4. Eliminating the “Update Detective” Burden for Users: In the current isolated channel ecosystem, when a user picks a specific developer’s driver, they become completely locked into that single developer’s bandwidth for updates and bug fixes. Meanwhile, another developer in a completely different channel might be actively solving that exact same bug or testing a brilliant new feature (for example, unlocking a “detached mode” setting for a smart switch while the other driver doesn’t support it). Today, users have to spend hours actively monitoring multiple forum threads, hopping between different drivers, and doing manual comparisons just to find out if a fix or a new feature is available elsewhere. A unified repository puts an end to this guessing game; all improvements, regardless of who coded them, roll out to the user automatically under the same driver.

How We Could Start

This isn’t about taking away anyone’s creative control. It’s about building a structured, open-source governance on GitHub where our current leading developers act as Core Maintainers.

We could start by forking the official SmartThings Edge drivers as a baseline and establishing an organization. The existing developers who choose to join this initiative would migrate their current, proven drivers into this central repository, resolving any overlapping logic and unifying their work into single, definitive packages. From there, conflict resolution, design patterns, and code approvals would be handled directly through GitHub’s Pull Request review system.

Eventually, if the community adopts this unified repository approach, we could also discuss open collective structures or voluntary crowdfunding (like GitHub Sponsors) to ensure the core maintainers are recognized for managing the repository infrastructure. But first, we need to talk about the willingness to cooperate.

What are your thoughts on shifting from fragmented individual channels to a unified community repository? I’d love to hear from our core developers and community members on how we can make this sustainable for the long run.

Due to forum mention limits, I can only tag 10 people here. To kickstart this conversation I am tagging the core developers behind the drivers I personally use, alongside the main contributors I see most actively shaping our community’s code right now: @Mariano_Colmenarejo, @orangebucket , @TapioX, @erickv, @wonjj6768, @blueyetisoftware , @TAustin, @Andreas_Roedl, @veonua, and @mocelet.

My sincere apologies if I missed anyone who has been instrumental to our Edge ecosystem—please feel free to tag and invite any other developers or users who might be interested in this discussion!

Your hard work has been the true backbone of SmartThings Edge. Your perspective on whether this unified repository approach is technically and logistically viable—and how it could protect us from orphaned code and developer burnout—is incredibly valuable.

2

IMO that would feel like working for SmartThings without working for them, leading to actual burnout and adding more tasks on top.

They actually have lots of individuals hosting their own code: the Blueprints which are the event handlers with a mix of user preferences and logic. Users are constantly hunting for the best blueprint for a specific device and publishing new ones, I lost count of how many there are for IKEA buttons.

In a certain way a driver is a package that includes the aforementioned converters and the blueprint with added features to make it easier to use. Being able to install a certain driver for a device or even test multiple ones from different developers is what makes SmartThings more flexible in this case since sometimes no one size fits all.

3

For me, this project is more of an art project than a traditional software project. I enjoy experimenting, trying ideas, and moving quickly. A common set of standards and review processes would probably slow that down more than help.

I’m absolutely in favor of openness, though. All of my drivers are open source, anyone is free to read the code, use it, fork it, or open PRs. If someone contributes something useful, I’m happy to merge it.

I’m not even a Lua developer. Most of the implementation is actually done by my AI agent, while I focus on agent improvements, testing, and making sure everything works together.

What I’m not looking for is the extra bureaucracy that comes with a shared repository discussions, approvals, release coordination, coding standards, and so on. I simply don’t have the time or motivation for that, and I’d rather spend that time building new things.

4

Hello everyone,

@marcos.scheffler Thanks for the approach you’re taking, rather than just unplugging channel invites.

At this very moment, I’m unable to respond and share my ideas, but since this is important, I wanted to take a few minutes to at least make some presence.

I’ll have some time at the end of the day to follow up.

Thanks for your patience and disposition.

5

I think this proposal touches a very real problem, and I agree with the basic diagnosis: something has to change.

Community Edge drivers are difficult to discover, sometimes fragmented across different channels, sometimes abandoned, sometimes duplicated, and often hard to evaluate for normal users. A more visible, better organized place for community work could absolutely help with that. It could make good drivers easier to find, make abandoned work easier to continue, and give new developers better examples to learn from.

So I do not disagree with the idea in principle, but I think we should be very careful about what problem we are actually trying to solve.

A unified community repository might improve discoverability and collaboration. What it must not become is a more efficient way of outsourcing SmartThings platform gaps to unpaid volunteers. That distinction is important.

Community developers are often misunderstood as people who simply add a few fingerprints or write a little bit of Lua in their spare time. In reality, a lot of community work is much closer to reverse engineering, integration design, device testing, support, documentation, and sometimes platform work by proxy.

A community driver is often created because one of these things has happened:

  • a device is not supported at all;
  • a device pairs with a generic profile and exposes only a fraction of its features;
  • a WWST integration exists, but covers only the most basic functions;
  • a manufacturer-specific Zigbee cluster needs to be decoded;
  • a Matter feature exists on the device, but is not exposed properly in SmartThings;
  • a suitable production capability does not exist;
  • a custom capability would work technically, but is treated as undesirable or second-class;
  • users are told by support to ask in the SmartThings Community;
  • or the official path is simply too slow for the problem users have today.

That is not just a repository problem. That is a platform problem.

And I think this is where the discussion becomes more important than just “where should community drivers live?”

SmartThings is a very specific ecosystem. Edge drivers, profiles, presentations, capabilities, fingerprints, lifecycle behavior, hub firmware behavior, Matter mappings, the CLI, Rules API, Advanced Web App, WWST requirements — all of this is highly specialized knowledge. Much of it is proprietary SmartThings knowledge. If you do not work with it constantly, it is not necessarily useful outside this ecosystem.

That also makes the situation difficult for manufacturers. We often assume that a manufacturer should simply “support SmartThings properly,” but in practice this means they need people who understand not only Zigbee, Matter, LAN APIs, or their own firmware, but also the SmartThings-specific integration model. We can see in pull requests and integration attempts that even developers working on official or partner integrations sometimes struggle with profiles, capabilities, fingerprints, or the expected SmartThings behavior.

So when a community developer builds a driver that supports more features than the official integration, that does not necessarily mean the community developer is “better.” It often means the community developer has spent a ridiculous amount of time learning very specific SmartThings behavior that most companies do not have in-house.

And this is why I think the current half-open model is so difficult.

SmartThings is not fully closed, because the community can write Edge drivers, create custom capabilities, publish channels, and support devices. But it is also not fully open, because many of the important parts are controlled centrally, documentation is sometimes incomplete, production capabilities take a long time, platform behavior can change, and some things cannot be solved properly from the outside. That creates a difficult balance.

There is also an uncomfortable business angle here. WWST certification is not just a technical process; it is part of the commercial SmartThings ecosystem. Manufacturers get an official badge, catalog visibility, partner status, and a clearer route into the Samsung/SmartThings user base. Community developers sit in a strange position in that model. On one hand, we can be inconvenient, because we sometimes make devices work without the manufacturer going through the full official integration path, and we expose functionality that the official integration may not expose. In that sense, we can interfere with part of the value proposition around certification and official support. On the other hand, we also make the SmartThings platform more attractive, because many users stay with SmartThings precisely because the community fills gaps, supports unusual devices, fixes incomplete integrations, and keeps older or niche hardware useful. So the community is both a complication for the official ecosystem and one of the reasons the ecosystem remains valuable.

If the ecosystem were completely closed, then Samsung and WWST partners would have to take full responsibility for device support, feature completeness, support channels, capability coverage, and Matter behavior.

If the ecosystem were truly open, then the community would need better tools, clearer documentation, faster feedback loops, a transparent path for capabilities, better access to platform internals, and a clear status for community-maintained work.

At the moment, it often feels open enough for the community to be expected to fill the gaps, but closed enough that the community cannot always fill those gaps cleanly.

Custom capabilities are a good example.

For many real devices, the standard production capabilities are not enough. That is not a theoretical issue. It happens all the time: irrigation controllers, air quality sensors, advanced thermostats, blinds, locks, presence sensors, energy devices, vendor-specific functions, and many Matter features do not always map nicely to the existing standard capability set.

Community developers can often solve this with custom capabilities. But custom capabilities are also often treated as something that should be avoided, especially for official or partner integrations. The result is predictable: official support often exposes only the lowest common denominator, while community drivers expose the real device functionality — but then those drivers live in a less official, less discoverable, less supported space.

That is not ideal for users.

It also creates a strange incentive. If custom capabilities are discouraged, then production capabilities need to appear quickly. But if production capabilities take months, developers and users are stuck. Either the feature is not exposed at all, or the community has to work around it.

The same applies to Matter. Matter is supposed to reduce integration complexity, but what happens when a Matter device exposes a feature that SmartThings does not surface yet? Is the expected path a GitHub issue? A WWST escalation? A production capability request? A custom capability? A community Edge driver? A support ticket? Waiting for a future platform update?

Right now, the answer often seems to be: all of the above, depending on who asks and how much persistence they have.

That is not sustainable.

There is also another point that should not be underestimated: support.

The community is often the always-on support layer. Users post in the evening, on weekends, across time zones, with devices that do not pair, features that are missing, broken automations, unclear app behavior, confusing Matter issues, or integrations that only partly work. Community developers and experienced users often respond immediately, because that is how forums work.

Official SmartThings staff, understandably, do not operate like a 24/7 support desk in the forum. But that means that by Monday morning, the community may already have analyzed the issue, proposed workarounds, explained limitations, or even built a driver. Sometimes that can look as if the community has “taken over” the conversation. But in many cases, it is simply the natural result of the community being present when users need help.

This is not a complaint. It is just important to acknowledge the reality.

A unified repository could make that community work more structured. But structure also creates expectations. If we create something that looks official, users will expect official reliability. If we add review processes, developers will expect reviewers. If we define standards, someone has to maintain them. If we centralize abandoned drivers, someone has to decide what is abandoned, what is safe, what is recommended, and what should be deprecated.

That can become a lot of unpaid coordination work very quickly.

So if SmartThings wants to encourage a more unified community driver ecosystem, I think the platform side needs to change as well. Otherwise we are only making the volunteer layer more efficient while leaving the underlying causes untouched.

Some things that would help much more than a repository alone:

  • A clear public statement about how API changes affect community developers, Edge driver development, CLI usage, Rules API usage, Advanced Web App usage, and non-commercial experimentation.

  • A faster, more transparent process for new production capabilities.

  • A clearer policy around custom capabilities: either embrace them as a legitimate extension mechanism, or provide a realistic alternative that does not take months.

  • Better documentation for Edge driver behavior, device presentations, capability design, Matter mappings, lifecycle behavior, and common pitfalls.

  • Better official tooling and validation for profiles, fingerprints, presentations, preferences, and capability usage.

  • A clear path for reporting missing Matter features or incomplete Matter mappings.

  • More complete official profiles for WWST devices, not just fingerprints that map devices to generic profiles exposing only basic functionality.

  • A public or semi-public backlog for platform limitations that community developers repeatedly hit.

  • Some form of official recognition that community developers are not just hobbyists adding convenience features, but are often filling real integration gaps that affect SmartThings users directly.

I also think SmartThings could learn from looking at the wider smart home ecosystem. If the question is “which integrations are users missing?”, then one useful signal is obvious: look at what people are actually using in ecosystems like Home Assistant. That does not mean SmartThings should copy Home Assistant, and it does not mean SmartThings should become Home Assistant. But it is a valuable market signal. If a brand or device class is widely used there and repeatedly requested here, that tells us something.

In the end, I think the repository idea is useful if it remains community-driven, lightweight, voluntary, and honest about its limits.

  • It should help people find good work.
  • It should help developers share code and patterns.
  • It should make abandoned work easier to continue.
  • It should make it easier for users to understand what is official, what is community-maintained, and what is experimental.

But it should not become a replacement for official SmartThings support.
It should not become unpaid WWST integration work.
It should not create a new layer of bureaucracy for community developers.
And it should not hide the fact that many of these drivers exist because the official platform does not yet expose what the devices can actually do.

So yes, I agree that something should change.

But the most important change cannot only be that the community organizes itself better.

The most important change has to be that SmartThings defines more clearly what kind of ecosystem it wants to be: closed and fully responsible, or open enough that the community can participate properly.

The current middle ground is where most of the friction comes from.

6

The old Community Wiki was pretty close to what you’re proposing. Nice easy way to consolidate information about custom Groovy drivers and quirks about every device ST could support. Easy for any of us providing drivers or custom device support to update. Quick searching by fingerprint. Sadly no one wanted to take it over.

Other tools have also sprung up but they aren’t quite as rich as a wiki, more like a “driver store”, similar to how custom Control4 drivers are marketed.

The same issues apply when it comes to these things, no one wants to maintain or devote time to these things (for free) for very long, people age out of the environment, life gets in the way, etc. This is even moreso on a shrinking user base like ST has. The amount of posts/questions on this forum is a clear indication of that. The tinkerers keep that type of stuff growing vs just the people with a few smart bulbs they want to control. The WWST device support is “good enough” for 98% of people who end up with ST, even fewer who even have a hub. Back in 2013 when Smart Home was a boom and everyone wanted in on it things were growing but at this point custom drivers on a non hobbiest platform is pretty niche.

Just my opinion.

7

@Andreas_Roedl Your feedback felt like playing chess; there’s so much to consider.

In my opinion, the major problem is the unmaintenance and abandonment of community driver releases, because even if users find it difficult to locate a community driver to integrate their device with X and Y extra features missed by the original provider, the self-driven nature of the community always channels the users to the right path… that’s the beauty of this community.

So, in simpler words, and because I (and most likely we) don’t have enough information about the direction that is being taken around the SmartThings Community as a project, I don’t agree with the proposal.

Why?!

Because it takes away the purpose of the dev community, and because, even if we didn’t give you the number of users a well-positioned partner may have, we willingly collaborated with SmartThings at no expense to themand at no expense collaborated with ST to retain some percentage of users that really wanted to go for SmartThings with low-cost solutions, keeping an open door for new customers that otherwise could just have jumped to buy any competitors’ solution for edge computing technologies.

What do I propose?!

Instead, I propose to formalize how the Community Drivers are being “sold” to this segment of users, for example, by defining a consistent structure to the documentation of the repository, a minimal testing suite, and even automated workflows (GH Actions) to level up the quality of these drivers.

8

All of this sounds nice but takes a ton of time for what would be a labor of love (for free). I wish anyone taking this on luck.

9

That’s true, it would be heavy.

But on one hand, it is well known that SmartThings’ Team is very indulgent when it comes to deadlines regarding integrations or migrations.

On the other hand, that would be the whole point: to minimize the exposure of users of abandoned work by consolidating a form of “non-official but quality-approved release”, just like they do with the pop-up/disclaimer that appears on every community driver, but with a different goal rather than discouraging users from using open-source software.

10

I think we actually agree more than it may have sounded from my previous post.

Just to clarify: my intention was not to attack SmartThings staff, the developer community, or the idea of better organization. If some of my wording sounded too sharp, that was not the intent. It was also influenced by the recent API announcement, because we still do not really know what it means for community developers, Edge driver work, CLI usage, Rules API usage, and non-commercial projects in general.

To be honest, that announcement felt discouraging. At least from a community developer perspective, it raised the question whether this kind of work is still truly wanted, or only tolerated as long as it does not get in the way. That is probably why my previous comment came across a bit sharper than intended.

I fully agree that abandonment and lack of maintenance are probably the most immediate practical problems. A community driver can be excellent when it is released, but devices, firmware, SmartThings behavior, or the developer’s availability can change over time. For normal users, that is very hard to understand.

So yes, I do see value in a more consistent way of presenting community drivers: clearer documentation, supported devices, known limitations, last confirmed test date, and maybe a simple status like experimental / tested / maintained / no longer maintained.

I would only be careful that this does not turn into bureaucracy or something that looks too official. The self-driven nature of this developer community is exactly why it works.

That was my main point: community organization can improve, but it should not become unpaid bureaucracy, unofficial WWST, or a substitute for SmartThings improving the developer experience itself.

Community developers are not the problem. Quite the opposite. They make SmartThings more useful, more flexible, and more attractive for many users. Any solution should preserve that.

But before we build too much structure around assumptions, I think we should first wait for clearer answers from SmartThings about the API changes and what they mean for community developers. Once that direction is clear, it will be much easier to decide what kind of community organization actually makes sense.

11

Thank you all for the thoughtful and detailed feedback.
After reading every message carefully, I realized my initial proposal sounded more structured than what I actually intended. So I’d like to clarify the idea, address the concerns raised, and reshape the proposal into something lightweight, voluntary, and aligned with the reality of our community.

What problem am I trying to solve?

Today, community drivers are:

  • scattered across dozens of threads and channels

  • difficult for users to discover

  • duplicated across developers

  • vulnerable to abandonment

  • hard to maintain when Samsung introduces breaking changes

The goal is simply to explore whether the community can reduce these pain points without creating bureaucracy or obligations.

@mocelet

You highlighted the risk of centralization turning into obligation and burnout.
I agree — and that is not the intention.

The reformulated proposal does not impose standards, does not require anyone to maintain anything, and does not eliminate diversity.
Multiple drivers for the same device can coexist.
Autonomy remains intact.

@veonua

Your workflow prioritizes speed, experimentation, and freedom.
This proposal does not interfere with that.

Experimental drivers continue to live in each developer’s personal channel, exactly as today.
No reviews, no coordination, no slowdown.
The repository would simply reference your channel link and contain the code for discoverability — nothing more.

@Andreas_Roedl

Your analysis was extremely valuable.
You’re right: many challenges are structural platform issues — documentation gaps, capability delays, unclear Matter mappings, and unpredictable changes.

This proposal is not an attempt to replace Samsung’s responsibilities or create unpaid integration work.
If anything, a minimal, unified base of community work could give us more leverage, not less, because it makes contributions visible, organized, and harder to ignore.

I agree that limits must be clear so this never becomes bureaucracy or unofficial WWST.

@erickv

You pointed out that abandonment is the most immediate problem — and I agree.
Your suggestion of documentation structure, testing, and workflows is valuable, but heavy.
The reformulated proposal below aims to keep things lightweight while still addressing abandonment and discoverability.

@csstup

Your reminder about the old Community Wiki was important.
It shows exactly what happens when information is scattered and dependent on individuals.
The goal here is not to recreate a wiki or a “driver store” that only points to links — but to create a place where drivers actually live, so they don’t disappear when someone leaves.

Reformulated Proposal (lightweight version)

Below is the simplified version of the idea — aligned with the concerns raised.

1. A single repository where community drivers actually live

A unified repository bringing together the code of all drivers that each community developer chooses to share.

Alongside the code, the repository generates a catalog:

  • list of all drivers

  • list of supported devices per driver

  • links to experimental channels

  • documentation for stable drivers

This gives users a single place to understand what exists and what each driver supports.

2. Two sections: experimental and stable

Experimental drivers

  • Published directly in the developer’s personal channel (as today).

  • The repository only contains:

    • the code

    • documentation

    • the link to the developer’s channel

  • No review, no coordination, no slowdown.

  • Full freedom preserved.

Stable drivers

  • Drivers that developers choose to move from experimental → stable.

  • Require minimal documentation (supported devices, capabilities, known limitations).

  • Require at least one active maintainer.

  • Published in the unified community channel.

3. Optional shared library folder

Reusable utilities for fingerprints, lifecycle, logging, etc.
No obligation to use it.

4. Clear maintainer roles

Driver maintainers

  • Each developer is the maintainer of their own driver.

  • They approve PRs, decide design choices, define capabilities, respond to issues, and push updates.

  • They have full autonomy over their driver.

Co-maintainers

  • Any developer can become a co-maintainer if the original maintainer approves a PR adding them.

  • Co-maintainers share responsibility and help avoid abandonment.

Global maintainers

  • A small group (2–3 people).

  • They do not control driver design.

  • They only:

    • perform the final merge into the stable section

    • ensure nothing breaks the stable channel

    • publish stable drivers to the unified channel

    • assign new maintainers if a driver is abandoned

They protect the stable channel — they do not “command” the drivers.

5. Simple rules

  1. Whoever creates the driver is the initial maintainer.

  2. Other devs can join as co-maintainers via PR approved by the maintainer.

  3. If a maintainer leaves, another dev can assume the driver.

  4. Stable drivers must have at least one active maintainer.

  5. Experimental drivers remain fully independent and live in personal channels.

Why this matters

  • Prevents years of work from disappearing.

  • Reduces duplicated effort.

  • Gives users a single place to find drivers.

  • Creates a clear catalog of supported devices.

  • Keeps experimental development fast.

  • Preserves autonomy and diversity.

  • Avoids bureaucracy.

  • Does not replace Samsung’s responsibilities.

  • Does not create unpaid WWST work.

  • Does not impose standards or obligations.

Samsung would benefit — but Samsung already benefits from everything the community has built.
The goal is simply to organize what already exists so the community doesn’t lose its own work.

12

Thanks for the follow-up @marcos.scheffler

While I digest this new information/summary, I’d like to ask:

  • What is/would be the strategy to promote the catalog of “Official Community Drivers” if not opening a new post/thread, which would be most likely pinned by ST moderators?
13

First of all, it’s better not to call “official” :sweat_smile:

We can keep the repository/channel visible without relying solely on a single post:

• Create an official post introducing the catalog and the repository (which moderators can pin).
• Create a permanent announcements thread, or open a new thread for each announcement — for example, when releasing new stable drivers or new versions.
• Encourage each developer to publish their experimental drivers in their own threads, always pointing back to the community catalog.
• Whenever recurring questions appear in the forum, reply with the link to the catalog to promote organic discovery.

14

Except that what I’m reading in this updated proposal does exactly the opposite from a developer POV.

Today my drivers live on my public github repo, but they don’t have to. I can keep them wherever I want. Publishing updates to my channel is done whenever appropriate. I manage my own testing, my own timelines.

Your idea seems to be that all drivers get rolled up into a single repo, but I’m not sure how easy that is to manage when its dozens of sources all in different layouts. A github repo of github repos?
And then when drivers are considered “stable”, someone with the keys to the stable subscription channel would actually deploy updates from the master repo, but not really having any idea what was in the change or likely even the ability to test the code (they’d need the config/device/etc).

When something breaks or a user has a question, who do they contact? A maintainer who then has to reach out to the developer?

I appreciate the effort to make things easier for users to find community drivers. Other systems have tools to help (HA with HACS, HE has HPM) but they are just an easier way to find/install. The individual community drivers are still managed each by their own developer without adding a stable channel maintainer level.

15

Hi @csstup, thanks for the feedback! You hit the nail on the head regarding the developer workflow friction, and I completely agree that a manual layout transition or relying on a human bottleneck to deploy code would be a massive and unnecessary overhead.

To clarify, this proposal isn’t just about the end-user experience; it is primarily about how developers can benefit from a shared infrastructure. Maintaining isolated drivers means everyone is independently solving the same platform-level headaches. A unified community organization allows devs to share reusable code blocks (like shared utility folders for common battery mappings, lifecycle states, custom Tuya cluster decoding, whatever else makes sense…), drastically reducing the time spent writing boilerplate code from scratch. It also provides an automatic backup system so years of work are preserved if a creator scales back.

I think GitHub tools and automations play a major role here and can help to address these concerns without forcing anyone to change their day-to-day workflow. This is just a conceptual idea on how we could handle it technically:

1. A Repo of Repos? In essence, yes!

For that, I think the community organization could use Forks of the devs’ own repositories instead of manual copy or upload of code. Your driver would continue to live strictly on your own public GitHub repo, exactly where and how you manage it today. GitHub Actions can help to automatically synchronize forks in the background, so you keep 100% of your autonomy and layout.

Even sharing code blocks or shared utilities works perfectly here: devs could simply fork the community’s utility repo into their personal accounts. This gives them absolute control over which version of the shared tools they want to use, without any risk of external updates breaking their existing code. Plus, if a dev ever decides to delete their personal repo, the community fork remains intact as a safety net, meaning the code is never lost.

2. Differentiating Stable vs. Experimental via Tags

GitHub Actions can also help with deployments. Tags can be used to indicate when a driver should be published when stable, or if a driver is only experimental.

For example, when you decide a version is ready for the general public on your end, you could simply create a release tag (like v1.0.0-stable) on your repo. An automated GitHub Action script could detect that specific tag, run basic checks, and automatically package and deploy your driver straight to the community’s “stable” Edge channel. No human maintainer ever touches your code, reviews your changes, or controls your timeline. You retain full control over your release criteria. If there is no stable tag, the driver remains strictly in the “experimental” section of the catalog, pointing users only to your personal channel link.

3. Who does the user contact and what do Global Maintainers do?

The catalog page generated by the central organization would clearly list you as the Core Maintainer for that specific driver, complete with a direct link to your GitHub Issues page or your specific forum thread. If a user runs into a bug, they go straight to you, just like today. You still decide design choices, define capabilities, and push updates.

The Global Maintainers wouldn’t “command” or gatekeep individual drivers. Instead, they would act as infrastructure librarians. Their core tasks would be to review and manage PRs related to the shared utility libraries to ensure code quality, and step in only if an existing driver is verified as completely abandoned and a future SmartThings update breaks it, allowing another willing dev to step up and patch it.

Since SmartThings doesn’t give us a “HACS for Edge Channels”, this lightweight, Git-automated fork approach might be a way to simulate a community package manager using the infrastructure we do have available.

Do you think utilizing GitHub Forks and automated Tag-based triggers could help mitigate that workflow friction from a developer’s point of view?

16

Overall, I’m positive about the distribution aspect of this proposal. Discovering community drivers is currently difficult, and a centralized catalog could definitely improve that, even if Samsung doesn’t actively participate.

My concern is about the long-term maintenance model rather than the repository itself.

Today, most drivers evolve in the developer’s own repository. As soon as a developer starts adding new features, fixing bugs, or experimenting with new capabilities, the community repository will inevitably begin to diverge.

Keeping those repositories synchronized is relatively easy at first, but over time it becomes increasingly difficult. Every merge requires review, testing, and validation across different hubs, firmware versions, and physical devices. Since developers and testers are spread across different regions and own different hardware, this quickly becomes a significant amount of work.

I can easily imagine a situation where the community repository falls behind the original one, or developers stop contributing because maintaining two repositories isn’t worth the extra effort.

So my main question isn’t whether a community repository is a good idea—it is. It’s who owns the responsibility for keeping it up to date, deciding what is considered “stable,” retesting drivers after platform or firmware changes, and preventing the community version from gradually becoming outdated.

17

Hi @veonua, please take a look at my reply to @csstup right above.

There is absolutely no need for developers to maintain two separate repositories. You would continue to manage strictly your own personal repo, exactly as you do today. GitHub automation handles 100% of the synchronization and mirroring in the background with zero extra effort or double-work from your side.

18

My couple of virtual device drivers can be found via this Wiki.

If something like this happens, I can store my own drivers there.

19

Hi everyone, apologies for the delay.

I’d like to follow up on your response, and then I’ll keep up the pace of the conversation below.

(I’ll try to be as descriptive as possible) So, starting with this… hmmm… I know that even today, the driver I maintain is not an official driver, regardless of the thousands of acceptances tracked in the last 3 years… And I’d like to be transparent in this matter because I’d like that others devs to acknowledge the value they’ve brought to the whole project and company without even knowing… maybe they know, but let’s review a few facts:

  1. Let’s consider the fact that every SmartThings Edge-based user spent at least 114.99 - 149,99 USD to buy their Aeotec V2-V3 (I know that there are a few alternatives… but let’s build the idea)
  2. At least my driver has 6299 acceptances, or installations
  3. If we just multiply these it becomes quite a number: $724,322 - $944,787 USD… but it is very obvious that the users who installed or accepted the invite didn’t really buy a hub to get the driver, and they probably had the driver for years… so let’s take at least 10% of the lowest: $72, 439
  4. So, just my collaboration in the SmartThings Community and the SmartThings Edge project was around that money generated… now imagine the impact of drivers built by @Mariano_Colmenarejo or @zambobmaz which are developers that are constantly hunting for innovation for users and actively debugging and adapting their solution to as many as possible to fit all of their users…
  5. Finally, let’s consider that it was work built with love, without payment, and that not only helped end-users but also companies to integrate their certified solutions without even realizing it.

So, I’m probably exaggerating the fact and numbers but the fact that the driver will be centralized by another individual or company without becoming in some sense official seems quite disrespectful IMHO… unless the repository you mention is intended to live under this account: SmartThings Community · GitHub (fingers crossed it is)… but I doubt it

Just in case anyone is curious about the acceptances on their driver, run the following command once you’ve set up your ST CLI

smartthings edge:channels:invites <CHANNEL_ID> --json

Now, as I said, I’ll keep reading and will read the follow-up of this response as soon as possible.

Thanks for the patience =]

20

Hi @erickv! Please don’t misunderstand my point—when I said “it’s better not to call it official”, I was actually referencing the exact line of thought that you and @Andreas_Roedl brought up earlier in this thread.

As Andreas noted, if we create something that looks too official, users will expect official corporate reliability. And as you put it a few posts ago, the goal is to consolidate a form of “non-official but quality-approved release”, exactly to minimize the exposure of users to abandoned work without turning the community into a rigid, bureaucratic entity.

I completely agree with your sentiment and your math—the value you and the other devs have given to this platform is astronomical.

To address all the valid architectural questions regarding multiple drivers, repository layouts, and automation overhead, I am currently starting a PoC (Proof of Concept) on GitHub.

I am designing a completely transparent, declarative automation layer that requires zero double-work or manual version tracking from the developers, keeping 100% of your repository sovereignty intact. Once the PoC is solid, I will bring the results back here to this thread so we can discuss concrete ideas.