I’ve been moving stuff into the Rules API. My remaining Automations largely involve either setting Security Modes or sending notifications.
Although lacking some important fine detail (like failing to mention that Security Modes appear in ‘PascalCase’, rather than ‘camelCase’ as they are in the capability and as is the usual ST convention), the Rules API Reference does at least suggest how to use the Security Mode in a condition. It makes no mention of the setting the Security Modes in an action. By contrast the Core SDK seems to be interested in ‘armState’ which doesn’t appear in the Reference, but omits much of the other location stuff that is there.
There are no mentions of sending notifications at all.
However if the Automations have been migrated to the Rules API, surely that means both are actually supported?
The Rules API is moving into the prime time now, so it would help greatly if there was consistency over how it is documented.
The same really applies across the board. I can pull notifications and device history out of the API should I want to and yet there isn’t a sniff of them in the Reference. I am not expecting direct access to the API (Postman, curl etc), the SDK and CLI to be in perfect harmony as the CLI depends on the SDK which depends on the API. There is a natural order there though. The API Reference needs to document anything that is live, proposed, deprecated or dead in the API, as is done for capabilities. Those should equate to ‘works unless something has broken’, ‘your mileage may vary’, ‘lingering like a bad smell’, and ‘too late’. Once you have that sorted the rest should be able to follow naturally.
I also noted the old SDC.webcore.co proof of concept claimed to handle ‘changes’ type conditions. I didn’t test that live but rather assumed that isn’t really the case as anything that major and that old would have to be mentioned somewhere.