I'm the author of the app, and am empowered to make such decisions. It wasn't "necessary". It was a design decision. I've articulated the reasons for that decision.
5 Likes
Personally, I am pleased to see the removal of RM 4.0 Restrictions. I always felt that they were sort of a HAMMER, to prevent a rule from doing anything. This caused unexpected behaviors for many users. I always prefer a more SURGICAL approach to making the logic take care of all of the possible scenarios. That is just the programmer in me. 
6 Likes
@ogiewon - I'm an old school idiot, and haven't programmed in ~25+ years, but I did wonder why restrictions were still there when Rule 4.0 was released. Conditional statements that "frame" the body of a rule really give enormously more fine-grained control over when a rule should run relative to restrictions.
1 Like
Moving fast in getting the release out, and not having come to the realization that they should be gone.
3 Likes
I appreciate that you gave us time to change some of our rules prior to the upcoming release. I was not happy when the changes were made to the way Xiaomi devices were handled, but I appreciate this very much. Thanks.
Edit: I'm checking my rules now and making changes, but one thing I want to know is where is the private boolean switch for RM 4 rules that have not yet had it enabled? Restrictions are not visable in new rules without pre-existing restrictions, and I wonder where that switch will be. I note that private booleans are remaining, as per the first post.
@bravenel, Sorry, I've got another question. I'm attempting to remove restrictions and moving rules from 3 to 4. I have a query about delays. I have a rule in my bedroom, where the light turns on if there is movement for >2 seconds (so that it doesnt trigger on us turning over in bed). It worked well in Rule 3. If Movement for >2 seconds, then turn on light. After 1 minute of inactivity, the light turns off. Here is the rule.
In Rule 4, I'm not sure about cancel delayed actions. Which actions will the cancel actually cancel? I want the cancel actions to only cancel the 1 minute delay for lights off (ELSE), not the 2 second delay for lights on (IF). Is this possible?
Edit: would moving the "cancel delayed actions" above the previous "set color" work, so it cancelled the delay before the next delay is set?
Curious...what motion detector are you using that can report a change in status within 2 seconds? Most commercial offerings need to see no motion for at least 15-30 seconds before sending a motion inactive status update.
I have a wired alarm system that constantly reports active/inactivity. I would like to turn it down, because it's constantly writing to my logs, so I had to disable logs for those sensors.
1 Like
It cancels any and all pending delays that have "cancel" selected. Your 00:02 delay should probably not have "cancel" selected, although it seems very low probability for that to matter.
Then use a Rule Machine 3.0 rule, that option is currently availabe
Restrictions weren't "taken out", they merely aren't available via drop down menus. They are still openly available through writing the logic.
I don't understand what this means.
So you want your wife to have a way to suspend a rule (like Pause does), and have it then later automatically restart? And this happens often? This is hardly a user friendly solution to errant rules.
So you want your wife to learn how to open the web interface to the hub, find the apps page, find a particular rule, open it, find Restrictions, and then know what to do? How is that "simply using" smart home features? My wife doesn't have a clue what any of those things are, nor should she.
WAF is a serious issue. I've lived through it for several years now. What you're proposing is not a solution for WAF, it's a kludge. Give her a button she can push to disable things, if that's a problem.
1 Like
Accidentally pressed the delete button (instead of edit)... My post disappeared! I'm merely stating that this was a simpler and faster way. Adding logical conditions, from a user perspective, can just be impossible. I know it's hard to accept for people used to see this as the simplest possible task in terms of computer systems, but it remains a hard fact for most people. Thinking a user's interface from a programmer's perspective, is a very common mistake.
*Example 1 : the dashboard's tiles - to update a dashboard you have no choice but select tiles individually from the UI, instead of having it refreshed by adding new devices in the app. This may seem simpler at some level, it's been a nightmare for me when I migrated my devices. I had to delete and redefine all my dashboards several times after adding more devices (or give up on using dashboards until everything was implemented properly, which for the duration of the migration would have meant no user friendly interface at all for several days). It was faster to do so rather than adding device after device "manually" into the dashboard UI.
Example 2: not being able to see devices statuses from the list of devices on the html interface (having to click each device), nor being able to activate a switch without having to wait for the page to load and then scrolling all the way down to the device and then clicking the device's name so its page will open and then and only then being able to see its status and turn it on/off.... of course, dashboard is supposed to be the solution to this... but after a certain amount of devices / tiles, the scrolling feature is very slow on an iPhone XS max... and so on.
Example 3: No compatibility for Thermostats with Alexa Skill. That's a real bummer. Found a couple of workarounds, but, again, totally not user friendly.
True. That was a bad example and the one I wanted to edit before I accidentally deleted my post. The issue is the time it takes to add conditions vs selecting a mode.
You know as well as I do that mode restrictions are a default feature, and it works for all apps that add this option, without having to implement it as explicit conditions in the app's code (beside by adding the related section in the settings). That's why I'm having such a hard time understanding the reason for your decision : why having to add mode logical conditions while the feature already exists as a core option?
No, this is only true for single page apps, not all apps, to make it easier for beginner app writers.
Wait a minute, now you're saying that the time to craft the rule is the problem? You create a rule once, and it runs for years after that.
It takes 20 seconds to create this action:
Forgive me if my poor English gets in the way! I don't mean that the time to craft the rule is the problem, I mean the time to edit the rule. Restrictions, as drop down menus, didn't required editing the conditional statements at all.
It takes 20 seconds, from a laptop or a desktop computer, not counting errors that can and will happen such as selecting "delete action" instead of "edit action" or "add action before... the wrong action/line, thus having to delete and then do it over. It's really funny how it seems obvious to you that this is simple. It is not, from a user's perspective. And I like being a simple user when I'm busy.
However, I'm wondering now if I didn't miss something here... Where would you add the conditional statement you just quoted? At the end of the app as a separate statement? So far I was assuming I'd have to create a mode condition, add it atop of all other conditions and indent it so all other conditions / actions would be within this first statement enclosure...
If it'll be a matter of just adding the statement anywhere or at the end of the rule, it's then a much simpler solution already, although it still needs editing.
It comes first, the very first action. It's a Simple Conditional Action. It is also very easy to edit, easier than to create.
1 Like
I was not aware of that. I have one cust app that uses multiple pages but I did not get to try the mode restriction on it. I'll look into it. I had initially written this app to run on ST's platform. Do you know if this is also true there?
Yes, this is true for ST also.
1 Like
Apparently I'm not understanding how "Stop Actions" works. I assumed that, in the below rule, the rule would exit if it were not Evening mode and the IF statement would never be evaluated. But that's not what's happening. The IF is evaluated regardless of the Stop Action, and the lights get changed if any of the Harmony actions specified are current.
I can change the Stop Action to be an IF statement, but I'd like to know what I'm doing wrong, here. Thanks.
Don’t use the “Stop Actions: This Rule” action. You have to use the “Exit Rule” action
1 Like
