I’m so confused by the Motion Lighting App (and HE frankly) because there’s so many options that are worded similarly. I’ve read the Help and other people’s questions, which even made me more confused. So bear with me, 4 years later, I just discovered “Motion Lighting” lol after using other methods to trigger motion sensors and lights.
My current setup:
2 different sensors that trigger a hall and stair light.
Motion is detected, lights turn on to 35% brightness.
Timer is set to 2 minutes of inactivity before these turn off again.
Question and problem:
4. I BELIEVE the “override and suspend animation” means that if someone uses one of the light/dimmer switches manually to either dim, raise, or turn on fully, then it should prevent the lights from turning off automatically after 2 minutes of inactivity? Sorry, but the documentation can be very confusing. If so, then this is what I want but…
Okay let’s say all the above are correct in my understanding, essentially all the rules above are completely disabled UNTIL someone turns off the switches manually at this point which then resets the rules above to default state again?
Is there a way after X amount of minutes AFTER someone manually pressed a light switch to reset this rule again? I’m just concerned someone else in the house might use a switch then forget to turn everything off afterwards now. It would be great for instance if I could pad the time instead of completely disabling the switches that after X amount of minutes (if a switch was triggered, add an additional 30 minutes to disable all before reverting back to default), everything once again turns off. In the past, I used Basic Rules (and sometimes RM) but they never quite worked right all of the time.
What you said in 4 and 5 above is correct. And you are right that this pretty much leaves the automation hanging waiting for someone to manually turn off the light before it will start working again.
So, how to do 6? The first thing I'd suggest is to move this automation to Room Lighting. It can be imported there to create a functionally identical automation as Room Lights. Motion Lighting is the older predecessor app, and Room Lights is newer, based on the years of experience gained with Motion Lighting. Motion Lighting had become overly 'featured' as you described in your post, and just couldn't go forward.
In Room Lights you will see a very similar feature for disabling the automation after the physical dimmer has been adjusted, like this:
If you want to change that so that it expires after some time, you're going to need a slightly different mechanism and another rule and Hub Variable to accomplish it. Instead of using this feature, you'd use something like this:
This rule is doing the exact same logic as the feature we've replaced, except for the addition of the timeout on waiting for the Kitchen dimmer to be turned off. With the addition of the timeout, now the Hold Kitchen variable will go back to false after the first to occur of 10 minutes or Kitchen being turned off. So after 10 minutes, the Room Lights automation won't be prevented from turning off the lights. Note that the trigger for the rule is for 'Dimmer level physical'. This will only trigger from the dimmer itself being changed, just like in Room Lights (and Motion Lighting).
Thank you for taking the time to write this. I appreciate it. However as someone who is overwhelmed with things unrelated to HE, I find a best practice far from intuitive.
Please consider adding “DEPRECATED” or “OBSOLETE” and perhaps something like, “please migrate to (insert build-in app name)” to some of their installation name. This is the second time this year that this has happened to me as the first was discovering Simple Automation Rules was also deprecated. It will help a lot of people and save everyone time.
I had a lot of strange issues with both RM and Basic Rules with motion sensors triggering lights, which is why I thought “Motion Lighting” was something new after reading some posts. The main issue was that some of my motion sensors weren’t triggering the lights sometimes and other time intermittently. I’ve tried it all from replacing batteries, rewriting rules (switching between RM, Room Lighting, SAR, and Basic Rules), resetting my Zigbee network, adding repeaters, and using different motion sensors, eliminating certain zigbee sensors altogether, etc. So I was shocked when ML has been working perfectly fine for over a day.
Could you just add something simple to Room Lighting which accomplishes what you’re trying to show with RM here? It would make more sense to tie that together.
I’ll be honest in saying that RM often trips me up. I’ve also posted quite a few RM rules that others said should work but haven’t and I never got to the bottom of solving why things will work one day and fail the next.
Another feature suggestion: add a ? Box next to each term which pops up a small description/example of what each thing does with an option to be disabled by more experienced users. It could save a lot of time jumping between tabs.
We did this initially, but there was a hue and cry to leave the apps in place. There is no need to migrate a functioning app.
This is most likely a device or mesh network issue. An app can't respond to a device that isn't communicating reliably. There are several posts about how to address this sort of issue.
We won't be adding more features to Room Lights at this time, wanting to avoid feature creep.
I think you are missing a means to turn off the lights. Your RL + RM resumes the RL instance. But if someone leaves after the motion ends but before the timer goes off the light will not go off. Perhaps a virtual switch (instead of the variable as variables are not available as means to turn off in RL) in the rule and add that virtual switch as a means to turn off. Include 'don't turn off if stays pending' so the switch won't turn off the lights if the motion is pending when the virtual switch resumes the rule.
No offense but this whole thing is so unnecessarily over-complicated and confusing. The syntax is awful. Perhaps not to some of you, but try this on most average people who are not robots and their heads would explode. Simple suggestions such as indicating/writing that a new method is preferred is met with opposition. Instead things get even more messy/convoluted because you all keep piling on code and methods instead of cleaning up old ones. And it will unfortunately get messier over time.
The beauty of an older system like Wink was that it was simple, but then if you wanted to expose more advanced things one could, but for the most part it was written as clean as possible for most people to understand.
Right now I have a situation for whatever reason the sensors are working but the system decided it wouldn’t turn on my lights with motion. It’s been fine for almost two weeks so I don’t know why. I came to read what was suggested above and it’s really confusing.
PS. I said a similar thing about RM a few years ago and it was met with the same level of pushback.
I'm sorry you find the apps confusing. We try not to deprecate older apps, as many users want to keep using them. There is not a method in the UI right now to separate older apps from newer ones. There's a bit of a dilemma between the different forces at play here, keeping things simple, preserving backwards compatibility, and moving forward all at the same time. We are doing our best, but realize that for some that's not good enough.
I'm not sure what this issue has to do with this topic, and perhaps would get more traction in the community for help in its own topic. There are basic troubleshooting steps you can take, including logs, testing individual devices from their device pages, etc. It's not really possible to know from what you've written just what the problem is. We'd like to help.
While I can work with this and have some programming skills, it’s frustrating as I’m a UI person/product designer and illustrator thats designed name brands that are in everyone’s home and in the movies. I work with celebrity interior designers and billionaires. Some of my suggestions are even the basis for what we’re seeing in AI. I’m just trying to brag, but politely say that I have a pretty good sense where things could be improved short of providing an updated resume/CV.
There will always be power users and people that understand things better than others. It depends on what audience you prefer. It’s the difference between Apple (Steve Jobs/Ives IPhone 1 era) and Android when it comes to UI design. Jobs understood that the art and UI would lead the programmers. He put form in front of function and good things happened. Now we’re stuck with Tim Cook and it’s becoming a hot mess but I digress.
But you don’t have to abandon older code, just mark that something is not preferred (deprecated in favor of) and some of the more advanced bells and whistles are either reworded so it’s more clear, perhaps a little question button next to switches (again, hideable) which launches a pop up with small explanations and examples, and bury some advance stuff under “advanced” dropdown menu. It would make a huge difference and I don’t think it’s going to break anything. I mean heck, hire me to mock up some new streamlined interfaces.
Our team is working constantly to improve the hub and its UI. There is no shortage of ideas about what should be the highest priority, and which UI elements deserve the most attention. Posts like yours make it sound as if we live in a vacuum of ignorance about the hub, its strengths and weaknesses. Trust me, we don't.
