Just to follow up in nauseating detail, and recognising I am taking the thread ever further away from the original topic:
webCoRE has been wonderful in many ways, but it is every inch the beta product it claims to be and getting worse, and there is a lot of bloat with it. Its future is on Hubitat. I don’t want to still be using it but I still need it, and not for anything complex either.
Smart Lighting is great at what it does, though it has a couple of infuriating quirks. One is that its toggle command assumes nothing else is changing the state of switches (unlike webCoRE which looks to see the current state and toggles that - though even that behaves suspiciously on occasions). The really big one for me is that if you specify multiple motion sensors it does not do the obvious thing of ‘motion on any of the motion sensors’, it uses them independently (curiously I was convinced it did work sensibly for several months but then stopped, but maybe I imagined it). So I have to use separate automations to maintain virtual motion sensors (I use Rules, but used to use webCoRE) . As a legacy app its days must be numbered. Quite whether it will be reimplemented or its functionality absorbed into Automations isn’t clear.
Automations are infuriating. They seem to be maintained as Rules and reverse mapped into Automations by the mobile apps (with independent implementations) which seems to be asking for trouble and getting it. Also it just isn’t clear what the functionality is that is being implemented, for example when timers start and whether they run to completion or can get automatically cancelled. The worst thing is that if you delete a device that they use they are as likely as not to completely vanish (to be more precise the condition or action with the device in is removed and if the automation is no longer complete it is deleted, so you either end up with no automation or one that may not do what you want). I use them as little as possible for simple ‘if … then …’ automations where I have no choice or the convenient ‘on/off’ option comes in handy.
I am still using Smart Lighting for the basic ‘turn on a switch when motion is detected and turn it off x minutes after motion is no longer detected’ because it knows to cancel the timer and reset itself if motion starts up again. Similar functionality in webCoRE would use the
stays condition or you could do much the same thing yourself using a
wait and exploiting the Task Cancellation Policy. I believe the equivalent in Rules will be
remains but if it has been implemented no one has said anything about it and I’ve no idea if a TCP equivalent is planned.
I am using webCoRE for the most basic of announcements like ‘the front door has been opened’ or ‘so and so has arrived’ because I really don’t want to have to write individual Automations and Rules when I can write one and use variables in the announcement. I am also using it for handling buttons for two reasons: one is that I am using
toggle and I am too lazy to replicate that manually in a Rule; the other is that buttons report their last attribute change and don’t have a standby state so checking their current value isn’t helpful (although you can get away with it when there is only one button and it is the only possible trigger), neither is
changes (which despite being in the proof of concept of webCoRE using Rules, is not documented in the Rules API) as there is no change of state, and there is no sign of an equivalent of
I use Automations for two main reasons (or three if you include simple, quick and dirty automations). One is that Security Mode handling in Rules is barely documented and if the Core SDK is used as a source of undocumented functionality you discover that the Security Mode as a condition and the Security Mode as an action seem barely related which doesn’t inspire confidence. The other is that executing Scenes from Rules is also not documented. Clearly Rules can do all this stuff as Automations are implemented as Rules, but if it is available outside of Automations, it isn’t documented.