Announcement | Changes to our Legacy SmartThings Platform

Smartthings offers me now exactly what it did before the Samsung acquisition, home automation

Smartthings has been as reliable as can be reasonably expected since i joined.

The app… the phone app, has been and remains, poorly designed, lacking in information and Inconsistent. It has failed to reflect what users require and is as agile as a brick

I will be extremely happy when this phase of the apps design gains a one way ticket to the dumpster

1 Like

I have Hive and the integration with Hive isn’t official and therefore not the best.

I also have an old intel NUC that would probably run HA. I’d just need the Zwave and ZigBee sticks.

It’s tempting but I think im right in thinking HA is community ran too? In which case it’s subject to bring dropped either in full or part.

ST is a closed commercial project, nothing to stop Samsung pulling the plug in full with no continuation.

There’s more chance of HA surviving.andvit would run regardless as you run the server


Are you running this as a virtual machine?

Are you using this version; “install Home Assistant Core on Windows, you will need to use the Windows Subsystem for Linux (WSL)” ?

I found those options here — Windows - Home Assistant


It appears from @SimonCraddock’s post that he is running HAOS natively on an x86 PC.

This would be basically the same as running HAOS on a Raspberry Pi, except for a different hardware architecture.

All of the various options are available here

No, its installed directly on to the SSD using the HA OS.


thank you.

Thanks for the reply @SimonCraddock

1 Like

Amozon said most Echo devices will support Matter and will be Matter controllers or hubs. Hopefully this will be true.

Pretty much every home automation standard/platform uses Terminology a little bit differently, and it’s important to understand matter’s definition of two different words.

  1. “controller”. I don’t know for sure, but I suspect this comes from the Zigbee light link profile definition of “controller“ as they seem to be written up in very similar ways.

In this context, a Matter controller isn’t a hub. It’s just a device that can send an instruction to another device on the same network.

The archetypal example from ZLL was a hue dimmer switch which could work with up to 10 hue bulbs without needing the hue bridge or any hub.

Here’s the ZLL spec document if anyone is interested and you’ll see what I mean:

So an echo device being a “matter controller“ is good in the sense that it will then be able to send instructions to other matter compliant devices like wall switches.

  1. “bridge.” Matter uses this in a very specific way. A matter bridge will be able to bring its devices into a matter-compliant app from a different company. Here again the classic example comes from Phillips, only this time it’s the hue bridge. Currently Many devices connected to a hue bridge, like a motion sensor or a wall switch, will show up in the HomeKit app, even if the individual device itself is not HomeKit compatible When used standalone. So whether you are using Apple’s Home app, Samsung’s SmartThings app, or any of several other platforms that Philips hue works with, the devices will show up there and can be used in routines there. It doesn’t work with all devices, but it does work with quite a few.

Philips has said the same thing will be true with matter. At least some devices connected to a hue bridge will show up in the smartthings app once both companies are matter compliant. That’s a matter “bridge.“

On the other hand, Samsung has said specifically in their announcements that smartthings hubs will NOT function as a Matter bridge. So SmartThings will only have a one-way integration with matter. Many Matter-compliant devices will be able to show up in the smartthings app. But smartthings will not expose devices connected to its hub to matter-compliant apps from other companies.

So that brings us to echo. Amazon so far has not given the specifics, so we don’t know whether its Echo devices going to take the Philip strategy and have its devices act as matter bridges, or whether it’s going to be like smartthings, and just act as a matter controller.

We do know that a matter Bridge from another company will be able to connect to an Alexa account and communicate using matter, but that’s not the same thing as the echo itself being a matter bridge.

One way integration is good, but two way would be even better. :sunglasses:


Will the Events and Utiities pages currently available on the legacy “graph” sites be migrating to at some point?

I only use the legacy “graph” site to access the utilities and events pages.

Just to have a reference, which menus do you use in each one of them?

For the Utiities, the zigbee utilities and Hub Commands.
Hub commands are the ones I reference the most if I’m seeing odd issues with the hub after looking at the events page.


I mostly use the reboot command on the utilities page

Almost every one of them, from the hub utilities, (zwave repairs, zwave exclusion), the hub logs/events (most importantly), the My Devices page (details, changing the DTH’s, status, ID’s etc), ability to create new devices manually, Location pages to see what’s installed where (apps and devices). It’s very very functional overall.


These options are currently available in the ST app. For others’ reference, in the Hub’s detail view, there’s a menu option called “Z-Wave Utilities”

I’m guessing you mean changing Driver, correct? This is also possible from the app. In the case of Z-Wave and Zigbee, the other driver must have the device’s fingerprints to appear in the list.
About the device’s details, and status, you can use the CLI and it will show you the data in a table unless you define -j or -y as the output format:

//See its details
smartthings devices device-id

//See the capabilities status:
smartthings devices:status device-id

//See the device's health status (online/offline):
smartthings devices:health device-id

Do you mean without having the physical device (Zigbee and Z-Wave)? With LAN drivers, you can create virtual devices of any kind, there are Community members that have developed drivers that help you to do so:

In the app, you can also see this information, but the devices are separated by rooms and the apps are in the “Automations” or “Life” tabs depending on their type. In the last one, there are ST Energy, ST Home Monitor, and others.
I’m guessing you mean an overall view of everything in one place, right?

As a note on the differing behavior of the various hubs, the Connect Home does not present an independent tile for the Smartthings hub. The top level presented as a tile is the WIFI router portion. The “hub” is an option off the first page you get when selecting the WIFI hub tile. Selecting the smartthings hub gets you a partially populated hub status page that says “Connected”. From the three dot menu there the only menu options are edit, driver, and information. There is no access to any utilities.

It’s missing the device network id (DNI) for Z-Wave and ZigBee devices (is there in the IDE).

Also it would be nice to have a web page display all this info like the IDE rather than just a CLI.


I also don’t see any way to get the hub IP address from the CLI

On the topic of improvements it would also be nice to see the CLI logging timestamps shown in local time rather than GMT, it’s practically impossible to debug something in a different timezone.


There should be a way to force assign a driver like a DTH. Drivers are don’t contain nearly all the fingerprints for devices. There’s no way to the community for add drivers the repo, the current certification process forces OEM’s to go through an expensive testing process and there’s no self certification mechanism (CST) as there was with DTH’s. This basically means that more devices will not be compatible with SmartThings than ever before because even through the basic drivers can work with many devices our there, because of the lack of fingerprints, users are going to lose out if they can’t force assign a driver to a device like in the case of a DTH.


Also, multiple options available for some devices simply will not be available if an official Smartthings edge driver gets grabed by the device at the onboarding process

Basic users will be totally confused why devices are not working or not showing info that they expect

A list of un official (CST) drivers should be available in the ST app to help everyone

At the moment, users are still expected to find this website, find a driver that might have a fingerprint of there device and jump through the process of getting it to work… edge may have given us local useage (mostly) but the user experience is still … complex