At one point, smartthings was following ADT guidelines, limiting automated/network access to notifications and the states that could trigger notifications, to prevent customers from accidentally turning off their security system or important alerts. Different security companies have different philosophies on this, but the ADT position isn’t uncommon.
Whether that’s still an internal guideline or just a legacy artifact from the old ADT partnership, I have no idea.
The odd thing about this situation is that you can login to Postman and read the API calls to read and set the Security Mode state. Except those calls don’t seem to work in practice, they give a 403 error.
I note that there is such a thing as a r:security:locations:*:armstate scope for subscribing to the Security Mode state in apps. This isn’t actually available for whitelisting in the Developer Workspace. It is not available for scoping PATs either, and I have never seen a suggestion of an equivalent for setting the modes.
I am actually indifferent to whether the Security Mode can be read or set directly via the API as it can be done indirectly and that seems to be the better way of doing it. It is just the way I think about things.
STHM is a Webhook SmartApp. Presumably the ability to Dismiss an alert is an internal function of that app but, regardless of how it works, it really needs to be easier to do, like issuing a command to a device. This is the important one for me.
It would seem I have been misunderstanding the relationship between the Security Mode and STHM. I have always assumed Security Mode had an independent existence and STHM was just an example of a security system that was using it, so I never understood why Routines wouldn’t let you access Security Mode if STHM wasn’t setup. However from what I can see from the API it would seem that if STHM isn’t set up the Security Mode simply isn’t there.