I am trying to move from webCoRE, Smart Lighting and Automations to the Rules API. Although much of the functionality I require looks like it may already be in use by Automations, the exposed and/or documented functionality doesn’t seem to have changed in the last nine months or so, and nor does the undocumented functionality that can be extracted by reading the Core SDK code. My requirements are actually extremely basic and I know I’ve banged on about all this before. This is what is still stopping me …
I use a lot of IKEA On/Off Switches, which present as two different buttons with
held functionality, and I also use multiple buttons for the same functionality.
Buttons do not have a standby value so they always show the last value used. You can use an
if Button button is pushed condition for a single button and it will work fine, but only as long as nothing else will trigger the piston, be that a device or timer event, or some other form of ‘manual’ piston execution such as the Test button. As soon as that happens the button will be returning the last thing that happened with it. At a push, though, for a single button it is an effective but compromised solution.
if Button button changes to pushed trigger would only work if the button pushes alternated between different values so that is no use. However webCoRE does have
if Button button gets pushed which does the job perfectly.
Unfortunately, when it comes to the Rules API, the only documented option is currently
equals, which is the equivalent of
is pushed. So I could port my pistons over, but I would have to use the compromised solution, split the piston in two, and then have multiple copies of each, and that is really a compromise too far.
So I am stymied by there not being a useful way of handling a button press.
Most other things I can do as I have simple needs, though something as simple as the
$currentEventDevice would be a game changer by itself.
I have actually managed to remove Smart Lighting, but only by using Automations for the ‘power allowance’ functionality and the similar delay after a contact changes, and because I have changed my motion sensors and no longer need the delay there. It is the absence of remains on for x minutes that is the particular limitation there.
I have always formed the impression that Smart Lighting was almost exclusively driven by subscriptions, and with each automation being a SmartApp it could constantly be updating its restrictions as they changed, not as the automation was triggered. Trying to replicate those automations would be a lot easier if there were a
changes type of condition (ironically this was actually in the SDC.webcore.co proof of concept over a year and half ago but I don’t think it worked when I tried it).
Automations and Quick Controls
Automations and, at a very large push, Quick Controls are useful toys for a limited number of automations, though if I had a switch to disable the latter they would be gone in an instant. I don’t mind using Automations for temporary things, and for simple Automations that might need to be easily enabled and disabled, and perhaps even for audio notifications (though I’ve no idea why Automations don’t support the Speech Synthesis capability). However I can not accept that they get edited or even deleted when they are perceived as no longer being viable. That might mean deleting a device with the expectation of replacing it a few seconds later, or it might mean something that should be irrelevant has occurred, such as STHM being deleted (it seems to be assumed that the Security Mode has no purpose outside of STHM, which is utter rot). The same functionality implemented directly in Rules is left well alone.
I am pleased to say that I can both read and set the Security Mode in the Rules API, even though the two functions lack consistency. Unfortunately what I can’t do is either execute Scenes, even though that is even mentioned as being possible in the documentation, or send push notifications, and those are game changers.
So close, and yet so far, and with just no visible signs of progress.