Question,
Is there a way to enable debug for Hubitat simple lightning?
I was home today and noticed that again one of my automationd had a strange behaviour. I noticed that one of my automations was still running even though it should have stopped after 5m with no motion. Looking into the Logs all seem to fire and stop correctly between sunset and sunrise. Except for the last one where the trigger for On occurred at 7:43 am and than it never stopped.
Is it possible that as the rule is set between sunset and sunrise that if the turnoff after 5 minutes with no motion occurs after the sunrise that it will not trigger?
This is most likely not related just noticed this today. All individual devices are reporting events when triggered.
The rule is triggered every minute (60 Sec is the blind time of the sensor) if motion is present but the Anti turn on only occurs after 5 minutes of no motion. As per logs the last anti turn on was 7:15 and there is motion within the 5 minutes at least until 7:43. After 7:43.10 (remember that sunrise was 7:44.00) there is nothing else recorded. As such it seems that the rule is completely shutdown at 7:44 without taking in account if there are still conditions to be met within the rule.
The expected behaviour would be for the rule to stop acting on trigger events but would still complete.
I think I read somewhere that a restriction will basically stop the rule from doing any more actions. Freeze it in its tracks. So if there is any overlap in the timing then what you described will happen.
That's bad.
It should in theory stop the triggers but not the rule from executing.
So in essence how you ensure that if a rule that starts when all conditions are met completes it's execution?
Should not the restrictions be checked ONLY at rule start?
It seems from what you saying that the rules restarts every time that motion is triggered. When the expected behaviour would be something like:
If (Restrictions are met) & motion than triggers X
Than if Motion not detected in (defined user) minutes than triggers y.
With a restriction this is not true. A restriction prevents anything from happening while in effect.
There are two ways around this issue concerning on-off automations that start just before a restriction takes effect: (1) Use a condition in RM instead of a restriction, or (2) separate the on and off portions of the automation into two separate rules, with the restriction only for the on part.
Motion Lighting has this functionality built-in, the separation of on and off logic, for just this reason.
Thanks a million.
I was trying to avoid using RM as I find it quite unfriendly.
For Example for a single button with multiple clicks where I would expect to have a single rule I need to define n multiple rules. One for each click, another for release and another for held.... It's so unfriendly.
It should be:
If pushed 1 than x
Else
If pushed 2 than y
Else
...
Thanks
I just find this really cumbersome an not logical in my humble opinion.
I would recommend a note in HSL that states:
Restrictions will disable any actions/Events from taking place even after the rule start.
These are just tools. With Simple Lighting, the idea of adding more options, for example to restrict on but not off, quickly changes it from "Simple" to "Complex". It's not possible to design a tool that fits everyone's use case perfectly. That's why there are multiple tools to handle this sort of automation.
Your automation would work with Motion Lighting. You could restrict the period during which it turns on to be some time frame, and it would still turn off after that time frame.
Completely Agree with that.
Hence my reference to only add a note, this would allow for users to better understand the tool and help them choose the right tool for their needs
I usually have one rule for ON and one for OFF to get around this issue in simple lighting. you can have the time restriction in OFF with offset to cover the sunrise problem.
That's an interesting workaround.
But from an user experience point of view you should not wish to be putting workaround as solutions. The exception should not be the rule.
In fact it could work, however it's confusing based on the simple fact that you will need to select all modes. As the design of Motion lightning is all around modes.
It takes more in consideration the technical aspect of the rule than rather the user experience, even though in essence they are the same.
For Example the user will expect to see
Turn this lights on (independent of mode).
Only if modes are required than A or B.
What you have is:
Turn this lights on Modes A to Y.
In essence same thing but from a user perspective is different.
Its just a matter of customer education.
After you get the hang of it you will eventually understand it. But it's not intuitive.
I hear you and there are a couple of posts about this. @bravenel wanted to keep simple lighting as simple as possible. You can use RM to create this rule as well.
Regarding keeping SL simple I agree with him.it should be simple.
The challenge is always to balance what is simple from a technical standpoint vs what is simple for the user. Sometimes what is simple for the user is a very complex thing from.a technical perspective.
The user should not need to carry complex interactions to obtain the desired result.
A good example of this is the evolution of websites. The initial websites demanded multiple interactions to provide the user with the desired information they required.
Than robots where invented to take that heavy lifting from the user into the Server side. This was a necessary move as was discovered that the attention span of the user rapidly decay with the number of clicks. Another example is the amount of Text in a website, initially you had dense pages of information it was than discovery that too complex data display would made users leave the site. Was than necessary more creative ways to provide the required information in a more lean and simple format.
The same principles apply here.
The challenge is for HE and any plataform how to provide a way/ways that are simple for the user to understand and use but at the same time provide the complexity that what is for them simple. A very daunting task to any developer.
On that aspect I do like the stringify approach.
P.s @bravenel thanks for the clarifications I will test motion lightning
I'm looking at it now. Modes are deeply ingrained in Motion Lighting. However, creating a derivative app would be pretty easy to do. The benefit of this is that it would preserve all of the learning embodied in Motion Lighting about the nuances of motion lighting automations, and preserve most of the UI.
