The Fragility of the ST Architecture

Reading all the posts last week from people whose smart home setups stopped working recently, either because zigbee communication isn’t working or because Z wave devices suddenly start acting like they’re some other device class or because virtual cloud devices just stopped working… I am forced to face the fragility of the smartthings architecture.

Let’s take the zwave motion sensor which is suddenly being reported by smartthings as a leak sensor.

The zwave sensor hasn’t changed. It’s sending the same reports It always has, in the format required by the independent third-party specifications. It would work fine with any other certified Z wave hub.

But smartthings layers its own architecture over the top of that independent third-party specification. Originally that was device type handlers. Now it’s edge drivers.

And because this architecture is proprietary to smartthings, and not part of an independent third-party process, This layer is not fully documented and certainly we do not get detailed change logs for every time the platform changes.

Every certified Z wave platform has its own unique rules engine, and you can get weird stuff that happens at that level. But there are only a few where once you have added a ZWave Device to your network the essential messaging between the device and the hub might be reported so differently that it looks like a different device class.

I don’t think I ever fully acknowledged this before, although it’s been true from the very beginning. And there have been several platform breakdowns in the past because of it, particularly around the issue of the management of multiendpoint Devices.

But until last week I didn’t fully acknowledge even to myself the ultimate fragility of this design approach. It would be one thing if, like Philips hue, there was a culture of detailed changelogs. But there isn’t.

I’m not saying that there aren’t a lot of great things about the smartthings platform: obviously there are. But I also think it’s important to acknowledge the wild wild west aspects of operating without an independent review and logging process for changes.

It’s possible that matter will improve some of the stability issues, but maybe not. Certainly smartthings has not as yet done much about documenting exactly how they are supporting matter, and where there might be gaps. :thinking:

I’m not sure what else to say at this point. This is an amazingly creative and supportive community and they have been able to do fantastic things on the basis of this architecture. I’m just not sure it’s a safe environment for anything essential to a household.

Maybe everybody else already realized this and has taken it into account. I know personal priorities differ, and that’s fine. Choice is good.

Lots to think about, anyway. :thinking:


I think part of the problem with Z-Wave sensors is that the stock driver covers all types of sensors. If a device get paired using generic fingerprints the driver doesn’t know what the device capabilities are so strange things show up. I think the forced migrations fall in this category.

Z-Wave Sensors need to pair with a specific fingerprint with the capabilities specified and then there are no problems.

I saw this several times during my manual transition from DTH to Edge during the Beta months.


Thats why I have always considered ST as a hobby and something to tinker with and would not rely on it to prevent my house from flooding or burning down or rental proprerty lock management etc.


Yeah. My carefully curated ecosystem of various locks, lights, switches and sensors have not survived the platform changeover. But, what really annoys me is that my ability to drill down and adjust settings is being removed in stages. I can see the problems on the hubs but can no longer asjust them like when it was groovy. If it continues down this path I am going to abandon for an open source solution

What specifically can’t you adjust?

1 Like

I would add – you can extend the definition of ‘safe’ to include ‘secure’ in your conversation. There remains the open question that a bad actor could potentially modify their Edge driver with possible nefarious intentions. There should be a way to thoroughly inspect any community solution before accepting the change. Off my soap box (again), but people should be aware.

1 Like

It is as easy to unenroll from a driver chanel as it is to enroll, unenroll does cut the ability for automatic updates to happen without the users approval

There is a lot of work that can be done by Smartthings to make things safer for users …do they feel it is necessary, who knows


@JDRoberts I fear you’ve missed the real fragility of the ST architecture, and it equally applies to both the old and the new. SmartThings can make a change on their end, completely without your control, and can result in your local devices or automations to fail to operate correctly. And this can happen at any time of their choosing.

Go away on vacation, and you might find an update pushed to your system has caused things to fail.

You have no real control on this platform.

When I was away for 3 weeks earlier in the year, my Hubitat and Home Assistant instances kept running exactly as they had when I left the house, even though both platforms had major updates released while I was away. In both of those platforms, I’m in control of what they do, how they do it, and when I update them.


Earlier today I got a notification that someone liked my post from 2016 (I have no idea why). I’d totally forgotten about this particular outage, but it was only one of hundreds that happened when I was a heavy user of the platform (I still have a v2 hub running, but it does almost nothing these days).

SmartThings can and do update things at any time without your control, and they break the system for end-users all too often.


This is all 100% true. I’ve been lucky in that we’ve never been bitten. We also don’t use ST for motion lighting or access control. ST overall has a very high WAF for us.


So many little things. For example I run multiple hubs in different locations. Sometimes a new device would be added at location(a) but appear inder the device list at location(b). I used to be able to copy the device details and manually create the device in the correct location and delete the old entry. Or Id purchase a device only to discover it was was geo-restricted meaning its not an option in the ST device list menu. I could jump into the hub and add it there. And about a hundred other things