Yes, I think that describes the current situation very well.
The interesting part is not that SmartThings has none of this. The interesting part is that some of the building blocks already seem to exist, but they are in places where they are mostly useful for the mobile app, not as a proper public platform model.
That is also why I increasingly think less in terms of individual devices and more in terms of Locations and Rooms.
Devices come and go. They get replaced, moved, reset, renamed, excluded, re-added, or substituted by another brand. But the Location remains. The Rooms remain. The living room is still the living room, even if the thermostat, motion sensor, temperature sensor, blinds, or radiator valve behind it change over time.
That is where the current model starts to feel a little strange from a user perspective.
For example, I now have several devices in the living room that expose temperature. Some are dedicated sensors, some are thermostats, some are presence sensors, and nowadays it feels like almost every device has a temperature sensor hidden somewhere. So which one is the “real” living room temperature?
Why doesn’t the SmartThings API simply offer something like an average or representative room temperature, similar to what Home Insight already seems to do visually?
The same applies to occupancy, windows, lights, humidity, air quality, and other states. As users, we often do not actually want to automate against one specific device. We want to automate against the state of the room or the home.
Sometimes I imagine what it would be like if my wife had to rebuild our entire smart home in SmartThings from scratch. She would not think in device IDs, capabilities, components, or which sensor happens to be best placed. She would simply expect to say:
Set the living room to 21 °C at 6 PM.
She would not know, and should not need to know, that an Aqara FP300 is responsible for presence detection, or that the Frient Smoke Detector happens to be the best temperature source in the bedroom, or that three different thermostats in one room need to be coordinated.
She thinks in states and desired outcomes, not in individual devices.
And honestly, that is probably how normal users think.
Of course, I understand that @Nathan_Sterner @SmartThings API survey is likely aimed strongly at B2B and partner integrations. That is also why I framed my proposal in that direction. But the user-facing benefit would be just as important.
A good example is a small manufacturer that recently launched a Matter-over-Thread radiator thermostat valve. No manufacturer cloud, no dedicated app, no ecosystem logic like Tado. Once it is connected to SmartThings, you can manually control each thermostat in the app. That is basically it.
If you have several of them in one room, you are back to controlling individual devices. There is no room-level heating logic, no representative room temperature, no awareness of open windows, no understanding of whether the room is occupied, and no real abstraction above the physical devices.
The manufacturer is essentially saying:
Here is the device. Now you figure out how to make it smart.
But this is exactly where SmartThings could provide enormous value.
What if the kind of intelligence that Tado provides through its own cloud could exist natively in SmartThings?
For that, the API would need an abstraction layer above individual devices. Something like:
If the average temperature in the living room is below X, set all radiator thermostats in that room to Y.
Or:
If any window in this room is open, pause heating in this room.
Or:
If the room is occupied and the room temperature is below the target, heat the room.
That sounds simple from a user perspective, but implementing this kind of cross-device logic in SmartThings is surprisingly difficult.
And that is where many current workarounds start to feel like Rube Goldberg machines.
Virtual switches. Helper devices. Mirrored attributes. Multiple routines just to express one logical condition. Rules copied into the Advanced Web App with IDs manually adjusted. Virtual aggregation devices just to represent something that should arguably already exist at Location or Room level.
Personally, I really dislike virtual devices for this kind of thing. I understand why they exist, and I understand why they are useful, but it feels fundamentally wrong to create a virtual switch and several routines just because I want to use a condition like:
Not all windows in this Location are closed.
That should not require a workaround.
So yes, I completely agree: the fact that /weatherdata, /summary, and /summary/presentation already exist is actually very interesting. It suggests that SmartThings already has pieces of a Location and Room context layer. But those pieces are not where they should be. They seem to be shaped around the mobile app experience instead of being exposed as a clean, documented, public API model.
What I would love to see is this idea taken seriously as a proper platform layer:
Location context
Room context
...
Hub context
Network context
Not as app tile data. Not as hidden Client API behavior. Not as something only advanced users can reverse-engineer.
But as a supported SmartThings API concept.
Because the missing piece is not just more device control. SmartThings already controls devices very well.
The missing piece is a clean way to describe and control the state of the home above the individual devices. An aggregation layer of capabilities, if you will.