Issue:
When dimmer switches are configured as physical turn ons/offs for a motion lighting rule and they are the only switches being acted on in that rule, their brightness level is skipped over since they are seen to already be on.
Example:
Preset the brightness of a dimmer to 100 while dimmer is off, when according to the mode and the motion lighting rule it should be 1.
When the dimmer is physically, or digitally triggered, i.e. not by the motion, the motion lighting rule responds with "Not turning on, already on" since that dimmer is the only device in that rule and it is seen to be on since it was just physically or digitally pressed.
This then does not change the brightness level of the dimmer to the intended level of 1 even though it is at the "incorrect" level of 100.
Workaround:
Add a second endpoint device to that motion lighting rule, real or virtual. If there is a second device in the rule to act on, it seems to send a request to all devices being acted on, thus resetting the brightness to the correct level regardless of what level it was when physically or digitally turned on. This, in my opinion, is the intended effect of the rule.
Has anyone else experienced this issue or is my assessment of how the app should be functioning incorrect?
Motion Lighting Configs
Note: Working as intended when that dummy virtual dimmer was added
I just use a Simple Automation rule(s) for these types of cases. SA is much faster than motion lighting for changing to the correct level anyway. You would need to use multiple rules (one for each time of day), but rules are free. I don't currently have any ML rules that don't activate before I can get to the switch. Even my downstairs bathroom, with the dimmer just inside the door, turns on before I can get my hand on the switch.
Thanks for the idea, but it has been working for me for a while now without issue and if I would want to really optimize for latency I would probably just convert over it to Node-RED.
I also want to try and support the built in apps as much as possible because the better the out of the box experience is, the more novice friendly the platform becomes, and the more successful the platform becomes, imo.
There is a new option in the Options for turning on section, "Do turn on if already on". This will solve the problem you described. It overrides "Not turning on, already on".
Sweet, I will try it out and get back to you. One question though, what is the use case for these new options, I saw the "Do turn on if already on", "Don't turn on if turned off manually", and "Don't turn off if already on". I did not see anything in the documentation about them and am curious how they differ from the disable switches/buttons/contacts etc.
From my perspective those options are very confusing from their wording alone, so any clarity you could provide would be helpful.
Update: Upon initial testing that seems to have fixed my problem. Thank you so much. Still hoping you can clarify the things listed above however.
I understand that this refers to ML not turning on a device that was manually turning off (after being turned on by ML, and Iām pretty sure the activate switch has to be specified in ML).
The second one is for not turning off a device that was on before ML was activated.
In regards to that option it appears to be unselectable when using the 'Don't turn on if turned off manually' option since that generates a new option in the location of the 'Do turn on if already on' option. Are these options meant to be mutually exclusive or is this a bug?
