Continuing the discussion from [Rule machine - as per the app developer, this app is no longer available for new installs, distribution, or support]
As for designing your own rules engine smartapp, sounds great, here is a new thread for that to keep people from getting confused.
This thread is for discussion about desired features and development of the core smartapp. If youāre just looking for the rules engine code for CoRE, itās in the following thread:
If you need assistance setting up a piston after you have installed core, as in the following thread:
You can continue to report bugs, request features, or discuss design ideas in this thread.
Anyone who tries to create a new rule engine should create a web-based graphical one. That way it can be much friendlier than trying to dig through tiny menus in your SmartThings appā¦
Very good idea. Letās try and compile a list of ārulesā that this app should be able to accomodate. From simple if that do that to most complex ones involving historical events (i.e. trigger an action if and only when an attributeās value exceeds a certain threshold, after itās been below the threshold. Subsequent reads over the threshold should not trigger the action again, unless the value drops below the threshold and then goes over that threshold again)
I think any rules engine needs support for both rules and conditional triggers
Seriously thoughā¦
I need to be able to write this:
When Door Contact Opens AND my Light Switch is ON do somethingā¦ However, DO NOT do anything if my Light Switch Turns On while my Door Contact is Open.
As for the difference between one time events and subscription events, this is the same reason that IFTTT introduced a ādo button .ā
SmartThings allows you to subscribe to events like a switch turning on or a motion sensor being triggered.
The original rule machine, as I understand it, was based on responding to events.
Then people wanted the ability to trigger a one time execution of a rule just like turning on a switch. Or like the Do button. No subscription, just a manual initiation.
That led to a second app which was called, I think, ātriggers.ā
And that in turn led to requests for one time events that would have conditionals around them.
The purpose of the one time event is that they could then be used from other parts of SmartThings. It was no longer all automatically driven by subscription events.
And then the conditionals let you say ābut only ifā other conditions were true.
In my experience, many UIs do distinguish between subscription events and āat willā events, whatever you want to call them. But other UIs will just count an at will request as a different type of subscription. I donāt think it really matters one way or the other, itās just a question of what fits your particular design.
IFTTT added the do button not so much because of the ādoā part as because of the button. Itās essentially the same as a recipe without an if other than the at will request. And they knew they wanted that at will request to have a button UI. So they went ahead and set it up separately.
I like that you are trying to work on this. Even if Bruce decides to come back, the more ideas we get with this app, the better each app could become! Iām trying to be positive here towards RM, but at the same time, hoping this new engine could become an evolution of that as well. CHOICES!
I see three variations that are the same as RM far as I can tell, but this sounds simpler to me:
This than that.
This than if a,b,c, then that.
If a,b,c, then that.
1 and 2 are triggered, 3 is like RM rules which subscribe and follow events.
A birdy told me that @Mike_Maxwell might know a little bit about web based integration. I am thinking out loud here, but what if we can all create the first community rule engine where we can all contribute to building it a little?
They are all viable because no-one has combined the strong points of all 3 yet. SmartRules is great but limited to a phone/tablet, Simple Rules Engine is very basic, and Rule Machine is extremely powerful but difficult to use effectivelyā¦ (these are gross over exaggerations, but you get my point.)
If someone is going to pour time and effort into reinventing the wheel, they better take the lessons from the existing rules platforms and improve on them.
Perfectly said. Which is exactly what I am trying to do. Rather than complaining that RM is gone (and by all means, I want it back too), letās put our shoulders together to push this through.
There is a fourth, which is the ability to initiate a āthatā without any āifā other than the initiation request itself. This is what the IFTTT ādoā button is.
And there is a fifth, which puts conditionals on the at will request. So do that when I ask you to but only whileā¦
I think @JDRoberts is saying RM is missing the ability to trigger an action from the app itself, much like the Routines allow you to click them. I concur with him, I could have used that a couple of timesā¦
A lot of power of RM lied in it being a completely mobile driven app, that power also exposed the limitations, bugs and mobile os platform parity issues.
The UI and UX flow of RM would likely be different had Bruce elected to re-write the code from scratch, forcing users to re-enter all their rules from scratch upon every releaseā¦
He didnāt do that, with very few exceptions, your old rules worked perfectly in new feature releases.
Maintaining backward compatibility on the smartApp side is very difficult.
The fourth, the at will request, just says ādo this because I told you to do it.ā It isnāt automatically initiated by anything. I have a headache, Iām going to take a nap in the afternoon, I want everything set exactly the way it gets set when my good night rule triggers. But I want it to happen NOW just because I said so. A āthatā without an āif.ā
And yes, I think the fifth ones are conditional triggers in rule machine terminology but @Mike_Maxwell would know better.
I did a tiny bit of brainstorming with Bruce when he was first writing rule machine, but I never actually used it and as you know, I canāt follow code these days since Iām now dependent on voice readers. So I donāt know anything about the internal details.
this is a limitation in the current UI, you get one button for a smart app ( > ), anything else needs to be triggered from submitOnChange events within dynamic pages.
There is a smartApp button input, however it isnāt completely implemented, Iāve been pushing for them to fix it, but there seems to be no interest from ST in doing so.
For any of you guys that think writing an SA of the complexity of RM is easy, have a go at writing a decent UI in STā¦
Iām not being an ass here, Iām serious.
Never said it was going to be easy, but someoneās got to do it. Web can be used with endpoints and JSON comms to an angularjs+bootstrap responsive app wrapped by a dummy container app within ios and android.