There has been a lot of excitement about Rule Machine since it was released one week ago. The original topic now has over 400 posts, and is getting hard to find things in. This new topic is intended to be place where ideas and requests for new features in Rule Machine can be posted.
Bruce- in reply to your post in the original thread re: linking rules. Did you find that linking rules within Rule Machine wasnāt really feasible, or was too much work to add? The virtual switch method should work fine, though some of us hate having so many virtual switches in our list of devices. We can be OCD a bit sometimes! Just curious, thatās all
I worked quite a bit on it, and had nothing but trouble due to parent-child app issues (maybe Rule is a teenager). One thorny issue was the equivalent of āsubscriptionsā to Rule state changes. Then it dawned on me that I was chasing a chimera. Gosh, Iām sorry you need a virtual switch, but really? It would be a mistake for me to implement something in Rule Machine that it can already do as is, donāt you think?
Using a virtual switch is acceptable, for sure. It might not be as ācleanā as a baked-in solution, but that doesnāt mean that itās the wrong way to do it. Wasnāt trying to imply otherwise, I was just curious as to how you arrived to the resolution, and thought my thought reasoning might be of interest
Iād still like in-app āphysical switch overrideā functionality. Iāve tried doing this with mode switches and conditions, and itās just not that clean for me.
Iāve got a somewhat hacked (but working) version based off of your latest codebase. Iāve not done a pull request, because I know youāve been swamped with all of the attention/feedback. Let me know if you want me to shoot it your way.
In my case, I use it so that my family can manually turn on the light at the switch and then not have any rule processing happen at all - which means that the normal āturn off lights pending delayā is overridden.
Thanks again for your great work on this - itās finally made Smart Things really useable for me!
I have a version of Rule which implements Water Sensors and Valves. But I donāt have any devices of either type. If someone who has these type of devices is willing to test this new version with them, please let me know!
Iām willing to test leak/water sensors. I donāt have a valve though. May I suggest you create a github development branch, and invite anyone to test it. Labeled āBetaā and openly available seems to work for Googleā¦ I will help in any way I can.
PS: I anxiously await thermostat actions, because I either have to make 10-20 routines, or create a smartapp. Rule machine rulesā¦
PPS: From a sheer usability standpoint as a suggestion, if you were able to simplify/remove the left subrule right subrule inputs, that would make this more usable for the masses. I have no suggestion how to do it (ugh), and I am able to use it just fine. However I am aware the ST UI is very restrictive in this regard.
Had a thought, not sure if possible. Is there a way that you could show in the app, in the list of Rules which ones are currently True? I know the interface is a bit limited, so not sure if there is a way to do it, but thought I would ask.
Allow remove/reduce list of conditions from a rule. App on could allow you to select āNoneā for properties to remove a conditions. Work arounds are to select the same condition multiple times or delete rule and start over
Prioritize stability over new features. Need an app that can cover 90% of common rules/logic. Users who want super complex rules can create there own app, add virtual switches, call routines, use IFTTT, etc.
Work with ST for approval and local execution of this powerful app. Simple, local automatons of locks would be huge for ST.
This one is ironic. In a previous version, a few days ago, you had to input the number of conditions you wanted to set up. If you changed that to a lower number, it wiped out the higher numbered conditions, and you could re-enter them. Now, we got rid of telling the app how many conditions. Iāll think about this request, because we did lose something useful while gaining something else thatās good.
This is already the guiding principle. Most new features donāt have anything to do with stability, such as a new sensor supported or a new action supported (unless I break the specific new feature, which Iāve done once or twice). HaHa, you can already, and could from day one, create super complex rules.
This one is impossible, and completely beyond my control. I will submit Rule Machine for approval, but there are no guarantees that ST will even look at it, let alone approve it, and even less likely, allow it to execute locally. Itās interesting to me that people are using Rule Machine to replace Smart Lighting. I donāt know why ST never listened to the Community about the need for a rules engine, but then, they arenāt very good at listening in general. They have their idea about what they want ST to be, and we are along for the ride. Donāt hold your breath on this one!
interestingly enough, you can remove any of them, it just doesnāt re-number after. So if you have condition 1, 2 and 3 and delete 2, you are left with 1 and 3. Not sure if it would affect working or not.
Yup, which is why I specified descending order, in your noted case, condition 2 will be sitting there mid ship looking ignorant. This āprobablyā wouldnāt effect rule execution, but would push all of my OCD buttons. In fact I may look at preventing removal of a condition thatās not the last oneā¦