First thanks to all for your help in my creating my first set of rules. They seem to work great. Especially to @TAustin for the API Browser. Here is my wish list for rules beyond a Real Rules Builder.
Smartthings CLI should list ALL rules that have been installed. Why it only lists the rules installed via the CLI and not include other rules that are currently being executed is beyond me. The hub recognizes them, why doesn’t the CLI?
Need a “rules:logcat” that tracks the execution of the rules. Would surely speed debugging approach.
More actions supported including the ability to post an event that the rule evaluated to true and fired. It seems that we simply fire blindly.
Also, good to have some kind of timer function that would allow you to control how often a rule evaluates. Many have commented about how “change” can cause blinking lights loop. We know how to fix it in Z-wave drivers (to handle multiple events per button press), we need similar constructs for rules.
Not sure how to get this to SmartThings team but figured community would help me and chime in as to what else is required. Hopefully, the Smartthings team will return to development as the transition from Groovy wraps up.
Thank you for that. But using that would introduce a delay in executing a command. We need a construct that is “no more than once per …”. In other words, if the rule fired at time 0, and you state no more than once per two seconds, then the rule would not be issued within two seconds after the rule executed.
What do you mean by ‘ALL rules’? Currently the CLI can list all of the Rules that it created while using its default authentication flow, and all of those created in the Location by members using a PAT if it is using a PAT for authentication. Just not both at once. It seemed a bit odd when it changed to doing that but I prefer it. It means I can use the default authentication for ‘playing’ with Rules and the PAT for the production stuff. There are, of course, the Rules that might have been created by other Installed Apps. Would you expect to be able to see those?
It certainly needs something.
I’m not entirely sure what you are getting at there. I’d certainly like the equivalent of webCoRE’s $currentEvent family of variables if there was anything I could do with the things. Maybe that is the sort of thing you were getting at?
I haven’t quite grasped this one either, apart from a desire to throttle Rule activity. Would you envisage effectively disabling triggering for a period?
Don’t know if we’re talking about the same thing but I am starting using rules, and find the EveryAction precisely useful to run a check virtual switch at [5] minute intervals to find values of temperature, humidity etc that would otherwise, in a routine trigger only on change.
Agree that @TAustin 's API Browser is a fantastic tool.
I mean that if I create a rule using the CLI, then I can see them/control them using the smartthings rules command. If, however, I create the rule with the API Browser, then the CLI doesn’t list these out. I understand that it is related to authentication method but since the hub executes either/both of them, then they should be listed. I need to see if it would work if I used the -t option correctly.
I may not be describing it correctly, but I would like to be able to evaluate a rule and store the result. This could be used as inputs to subsequent actions. Let’s take the simply case that a switch state changed. You would like to record the new state (on or off), and then use that as an input to the next rule. Of course, today you can do it by having a rule that says, did the state change and was it on, then change to on. And then repeat, did the state change and was it off, then change to off. Easier to be able to collapse it to one run with the new state as a variable that you use as input. Hope this makes sense.
Yes. The able to disable for a period would be great to address race conditions.
We found your post, @harobinson and when you make this kind of request, you can tag me or @AlejandroPadilla, we can create a feature request so the team can have it on their backlog to analyze it.
About your point 1, I already reported that and the team mentioned they would add something to the API so we could make a request to bring all the Rules we have created.
I’m taking note of the other ones you mentioned, if you have more ideas or things that you have seen that would enhance the Rules API, please let us know and we will share this list to the engineering team.