Rules are not visible when using different ST token

Developer Programs Rules API
1

I created a Rule using Smartthings CLI.

My Smartthings CLI is configured with config.yaml with a token which is created at https://account.smartthings.com/tokens

The Rule works well in my Location.

The problem is…
When I use SmartThings Rules Manager at https://smartthings-rules-manager.glitch.me/
The rule, which works well, is not visible at all by clicking “List Rules”.

Also, when I create a rule in SmartThings Rules Manager at https://smartthings-rules-manager.glitch.me/
The rule is not visible in Smartthings CLI.

…

FYI,

  1. ST CLI is downloaded from here. v0.0.0-pre.18
    I installed to the Ubuntu 20.04 Server x64 version. It has been working well.

  2. SmartThings Rules Manager is a glitch app provided by SmartThings Github.
    Rules-API-Hub/Sample Rules Apps/smartthings-rules-manager.glitch.me at master · SmartThingsCommunity/Rules-API-Hub (github.com)

  3. ST CLI Token which is manually created from https://account.smartthings.com/tokens is granted with ALL permissions that are checkable from the token generation site. It is connected with Smartthings CLI executable using config.yaml file.

  4. Rules Manager Token is automatically created when I logged in to that glitch app webpage with my Samsung account.

  5. Both tokens are created with the same Samsung Account (which is my Samsung Account)

…

Here is what I tried for the workaround.

In the SmartThings Rules Manager at https://smartthings-rules-manager.glitch.me/
I could see the Bearer Token, which is automatically generated after logging in with the Samsung Account.

So, I copied that Bearer Token, and pasted in the config.yaml of the SmartThings CLI.
Then the Rules are visible in both CLI and Smartthings Rules Manager glitch.

…

Here is the problem.
Why are Rules, of the same location, not visible to each other when using different Bearer Token?
It needs to be fixed.

Thank you.

2

The confusion is understandable. The tokens have different scopes and I believe the CLI and Rules Manager were intended to be utilized independent of each other. May I inquire about your use case? Did you start with Rules Manager and switched to the CLI or you intend to use both simultaneously?

1 Like
3

I originally started using Rules with ST CLI.

Recently, I heard about local execution of rules in the beta firmware. So I was planning to move from WebCoRE into Rules, and I was digging around SmartThingsCommunity Github, and I just found out that there was such thing as Rules Manager.

Pros of the CLI is that, I can locally save rules into json text file, so that I can easily edit the file using powerful text editors, especially when I make a big change.

At first, I installed CLI at my home PC, but I moved CLI in to my Ubuntu Server, so that I could access CLI with SSH and modify the json file even if I am not home.

Windows version of the CLI showes login webpage and generates token automatically. But in the Ubuntu Server version, since there’s no GUI desktop, I needed to use the manually generated token from https://account.smartthings.com/tokens

Pros of the Rules Manager glitch app is that, it seems more user friendly. For simple use, this kind of interface would be more useful.

Therefore, I was planning to use the both.
Complex use with CLI + text editor… Simple use with Rules Manager.

But if I could use only one tool, then I should be stick with the CLI.
I’m planning to use Makefile for automatically uploading only modified json file. i.e. change the json file and just type make at the linux shell.

It is not reasonable to stick with only one token for using Rules API.
Let’s say I created a rule with a PAT, and by some reason, the token was accidentally deleted or lost, then the rule could never be modified or deleted.

It would be great if Rules created from the same Samsung Account should be visible regardless of the tools/tokens that I am using.

Thank you.

1 Like
4

@Brad_ST The tokens have different scopes and I believe the CLI and Rules Manager were intended to be utilized independent of each other.

If it is the policy, then I can understand that tokens from different smartapp are not transparent to each other.

However, It is weird that PAT which is generated from Samsung account with

  • Rules
    • See all rules
    • Manage all rules
    • Control this rule

all checked, is NOT able to “See”, “Manage”, and “Control” “all rules” that are generated from other tools.

It is like PAT created with

  • Locations
    • See all locations
    • Manage all locations
    • Control all locations

all checked, should be able to see, manage and control locations generated from other smartapp.

At least, I think, this policy needs to be changed.

1 Like
5

I sort of get what the thinking is here. There will be some rules that you only want to be able to manage via particular applications. The obvious current examples would be Automations or Scenes. It would be nice to be able to see the rules are there and read them, but you don’t want to be able to mess them up. Having their own private scope is good.

Rules Manager is different because intuitively you expect to be able to see the same rules you do with the CLI, or indeed with any method using a Personal Access Token. They should all have the same scope.

I am using CLI with a Personal Access Token I created and added manually, and I know the rules I have created can be accessed using other PATs. However had I been able to let the CLI login and create it automatically would I be using a SmartApp token and be working with rules that were private to the CLI? That would be rather unfortunate.

I’d imagine at some stage we will be able to see all the rules created by any SmartApp or PAT but we haven’t reached that point on the development timeline.

1 Like
6

I had very annoying situation because of this problem.

To use the new ST Edge device handlers, PAT for Smartthings CLI required ‘channel’ permission.

However, there’s no way to add just channel permission to existing PAT, I had to re-create the PAT with the channel permission.

The problem is,

Rules are bound to PAT, so that I had to delete all the rules that I’ve created with the previous PAT, and re-create the same Rules with the newly created PAT with the channel permission.

…

There must be several situations that requires replacement of PAT, other than this situation, such as PAT was accidentally leaked or something.

The problem that Rules are bound to only one PAT, can be annoying in these situations.

7

I changed the default PAT for my CLI for the same reason and it made no difference to my Rules. I’ve changed it lots of times. I often access my Rules from different places with different PATS.

I’ve not examined why things like Rules Manager can’t see other Rules but I’ve always assumed it is because they work with Rules owned by the app rather than the Location.

8

Oh, it seems that I did unnecessary works. :confounded:
Thank you for correcting my misunderstanding.