Searching through the forums led me to try to reset my session, no luck. Then I logged out of my session and logged back in, still the same. Then I tried appending my PAT to the command and it returned my rules.
I am the other way around. If I use the default authentication in the CLI I get the rules. If I use a PAT for a location member nothing is returned (it is actually a 403).
This is new and disastrous. It means that Wild Thing, my cross checking app, is broken. I’ve been using it in various forms for years now. It would actually be impossible for ST do anything worse than that.
Let’s ask @nayelyz if she can make some enquiries.
I remember seeing something like this in the past with a tool to create basic Rules which used the OAuth authentication to be able to create them for you.
But, if you tried to get them from the API directly, they didn’t appear. What I noticed is that the difference was in the Access Token type. In this case, I think it’s happening again because the CLI’s login flow also uses OAuth and if you created the Rule with your PAT, it won’t appear and vice-versa.
I’ll check with the team for more details about this behavior and let you know their feedback.
Would the PAT vs OAUTH issue also explain why I can see my rules in the CLI and still manage them there but not see them via the /rules api? I just get an empty object from the API now when listing rules but I can see them all via the CLI just fine (I use YAML to create my rules using the CLI but can’t see them via the API at all and this seems new within the last week or so).
I believe so. That is what is currently happening to me. I think those who have experienced it the other way around may have been creating Rules using Todd’s API Browser or similar.
I’m not terribly happy about it. It’s not that I couldn’t switch my Rules to a PAT in a couple of minutes if necessary, it is just that I am a bit fed up of the whole concept of ownership and security in ST being so opaque. How do I know if something is broken if I don’t know how it is supposed to work in the first place?
Following on to the above comment there is a certain added irony in that I couldn’t quite get my head around why it ever worked. We see webhook apps and Glitch apps maintain their own set of Rules and I was never clear why the CLI behaved differently.
Following up on this, I created a report about this behavior. I was able to reproduce that we cannot see Rules created by the CLI and in the API directly in the same list as it depends on the token used to create it.
Once I get more info, I’ll let you know.
I know you’ll let us know when you do hear anything, but I just wanted to keep this thread active as it is important to know the path forwards. As things stand I can either manage Rules using the default CLI authentication OR I can use a PAT belonging to any of the Location members. Though it is odd that it has suddenly become one or the other, if it is how it is going to be going ahead then that’s fine, though the CLI team might be advised to twiddle their help texts if that is the case. I am just about to move mine over as I can’t function without being able to see my Rules with a PAT.
Yes that is right. I gave up waiting and deleted all my Rules (tedious) and recreated them (trivial) with a PAT.
Ownership in SmartThings is very confusing. Some things are owned by account IDs, which are in turn linked to user IDs, and they share the ID with organisations. However other things are owned by those user IDs directly. Edge is particularly weird as using the CLI I can only do anything with the hubs using the location owner account (or maybe the account that installed them - I made them the same). However if I use the web interface it seems I can enroll in channels and install drivers using any account in the Location.