correct me if I’m wrong, but i’m pretty sure that flipping a switch will turn a ML rule on and off, not cause it to be evaluated. you would still need a condition change to trigger an evaluation.
If you want it to it does that. Like I said not sure if I understood your wanting so we may have crossed wires. But let's say you wanted ML to do the motion part depending on time mode with different delays but you just want it to give a true false value to then be processed though a RM rule which also incorporated the switch. That sounds possible by creating a virtual switch to then trigger the rule. I currently just turn the light on off up down and different colours/ temp using ML. I then have rules on each light that is triggered via the switch and that keeps them running together.
Is this the round about way of saying that you can use motion lighting to turn on a virtual switch when there is motion so you can use the motion in another rule? Why would you want to do that? Why not just use the motion in the rule instead of the virtual switch? I think you're making things a lot more complicated then they have to.
It was but it all depends on what the OP wants to do, then finding the easiest way to do it. Like I said I use ML to control the light then I also have a rule to control the light via a switch but it's done in a way that they are kept in sync.
@bravenel hey Bruce. Think I’ve found a bug in ML 
I converted my RM rules over to ML rules. I’m using per mode setting. Today I’ve gone into the lights to turn these to use delay per mode and all delays have a 1 minute default. If you then try to change this figure to anything else, as soon as you click out of the text box it reverts back to 1 and won’t save any value greater than 1. The rule is I’m trying to convert is:
I’ve tried to change the value from mobile safari, OSX safari and Chrome but get the same on each
It doesn't look like you enabled Delay per mode.
The inputs for delay do default to 1, but you should be able to put in a different value. I'm able to with Chrome on Mac, and below, after changing them with Safari.
I cancelled the change as I didn’t want 1 minute delays for each mode
@bravenel this is on iOS 12.3. Same behaviour on Chrome on Win 10
I tried flipping the switch for delay per mode, save, come out and go back in and took this recording
Any update on the RM truth change bug?
@bravenel I also noted this a while back but it does work you just have to "pick the one its wants" by that i mean one becomes the "master" box which changes the delay of the others in that mode and if you change the "slave" it doesnt like it. You did mention you were going to look at moving the delay per mode to the OFF settings page to simplify this and for another issue/ short coming i reported. Did you ever get a chance to look at this? I assumed not as you were obviously working on RM 3.0 at the time so had bigger fish to fry 
so haven't brought it up again until now.
I cant remember what box became the "master" it was either the 1st delay per mode used on that mode or the last.
@BorrisTheCat that seems to have done it. @bravenel I have one hue strip set to colour temp per mode and another hue strip set to colour per mode. I went to the last mode in set colour and changes in that set (starting from last mode) mirrored back to set temp. The bug seems to be when using set colour and set temp in the same ML rule
1 Like
I'll look into it.
This is definitely a bug. It's actually a structural flaw in the app. It should not be offering a different delay time for each mode for each lighting type. There is actually only a single set of delays available.
Another use has suggested many times, unfortunately to my neglect, that delay per mode should be a part of Options for Off, not where it is now in the UI. That user is right, and that is the fix for this problem.
It will be moved to Options for Off, so that there is only a single set of delays, to make clear that they operate on all light types. A CT bulb and a Color bulb and a dimmer should all turn off at the same time in a single ML rule. Needing different times for different light types is beyond the scope of a single ML rule.
Hopefully this will make it into our upcoming 2.1.0 release, or at worst a hot fix update to it... Stay tuned. Thanks for doing the heavy lifting of exposing the root cause of the problem you were having.
2 Likes
Checked again this morning, still no release. When can we expect 2.1.0? We really need the rule truth issue fixed asap.
Thanks Bruce
Thanks Bruce just updated mine now will see how it goes, need to create a few more test rules.
Thank you Bruce! Seems to be working now.
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
