Field "commandID" is not recognized by rule engine

Developer Programs Rules API
1

Per the Rules API documentation, there is a field called commandId in commandAction->commands which returns a BodyMalformed error as it seems to not be recognized.

See example JSON:

{
    "name": "Control Dining Room Switches",
    "actions": [
        {
            "if": {
                "equals": {
                    "left": {
                        "device": {
                            "devices": [
                                "a6fed7df-4497-41de-b197-bfe6b2c78e28"
                            ],
                            "component": "main",
                            "capability": "switch",
                            "attribute": "switch",
                            "trigger": "Always"
                        }
                    },
                    "right": {
                        "string": "off"
                    }
                },
                "then": [
                    {
                        "command": {
                            "devices": [
                                "6c092e48-d616-423b-a621-ee951f8acab1"
                            ],
                            "commands": [
                                {
                                    "component": "main",
                                    "capability": "switch",
                                    "command": "off",
                                    "commandId": "run by rule"
                                }
                            ]
                        }
                    }
                ]
            }
        }
    ]
}

@nayelyz
Thanks

Henry

2

Tagging @nayelyz

3

It isn’t something that is known to Routines either. It could be a relic of earlier versions of the Rules as I’ve seen as much removed as I have seen added over the last three years.

4

Hi, @harobinson
I’ll ask the team about this and create a report about it if necessary.

5

Thanks for the comment. That said, you would surely want accuracy/quality in code including documentation. Some of us have not had such a long legacy with SmartThings and there is some frustration when you need to decide if my code is wrong or the documentation is wrong or there is a bug.

Frustrating that you can’t take JSON from SmartLighting routines, copy it as is, and then use it as the basis for your new rules. Syntax is different.

It would be good to have one complete, accurate source of truth.

Venting done.

1 Like
6

Yes, I was speculating on how it might have come to be there. I’ve been expressing my frustration over the rather vague wording of the API Reference for two or three years now. It seems to be written using a lexicon of terms that have never been communicated to the end users and the assumption that there is other documentation out there which properly explains things, which there really isn’t. OK a few bits have appeared in the main developer documentation but it started off with significantly different terminology and it has been like pulling teeth to get it to where it is, which is miles away from where it needs to be.

I’ve also been expressing my frustration and bafflement on the Routines v Rules situation for a very long time too. For a long time before I twigged where the Rules powering Routines and Smart Lighting were hiding in plain sight, I was perfectly aware that the functionality of the Rules available to the the Routines was significantly ahead of that in the Rules API, which in turn was a superset of the bits that were documented. I’ve never really understood why.

I also get hacked off about Scenes. It irritates me that there is an action to execute a Scene, but not one to execute a Rule. I don’t want to use Scenes any more than I want to use Routines. I’m not much of a coder but it is my code and I don’t like it being messed with.

2 Likes