Bruce thanks for the reply.
I can’t figure out how to quote your reply, or I would… Sorry…
With regard to the condition detail change: Understand what you are saying. The interesting thing is that when the rule itself was not updated, but the condition was, the rule started using the new condition details without updating the rule itself with the quoted name of the updated condition details. It actually started using the new condition details immediately when I clicked “done” when editing the condition, and didn’t wait for me to actually click done on the total rule itself. I think this is fine, but could confuse someone since the rule description isn’t updated to the new actual logic without manually reconfiguring it to select the altered condition name. So it seems somehow as if the rule is aware of the new condition detail immediately, but doesn’t replace the new description in the rule text display. I have not looked at the code, but I would suspect that this would happen when the rule actually operates on a key/identifier for a condition and not the description of the condition. (i.e. the code is liked to an identity of the condition which follows the condition parameters regardless of how many times it is updated, but the linked description of the condition is not updated in the rule description on its own ever). Is that possible?
On the topic of the manual over-ride, and preventing the rule from firing to fight it. You are exactly on the path I was thinking. I thought, if I could specify a condition that states: “If the dimmer is above X”. The rule would fire when I walk in the room for the first time (since the device would be off), but if I make it brighter manually, it would not re-fire dimming it back immediately (because the device condition is above the fire rule). If I were to then dim the device below the condition or turn it off, it would then return to it’s normal working status. I think this would be a very good add in the options. Of course it would be more robust to add the condition of the dimmer with lot’s of states not just >=, and that would be great.
While I think this is a great add regardless, I actually have the dimmer set a little more complicated, and this solution doesn’t quite solve my actual use case directly. To explain: I have the dimmer set to be bright if needed in the day, and then phase down at night to get the kids thinking its time to wind down. I do this with a series of similar rules: Set dimmer to 100 if: Between 7AM & 7:59PM, AND Motion Active, AND Illuminance <= 2000 (outside). I then use a duplicate rule, but set the dimmer to 60% between 8PM & 8:30PM. And continue this sequence of rules in discrete time period until I get to 20% and the time if is between 9PM & 6:59AM. This sets the final low light condition to calm everyone down, and also acts as the night light if someone enters the room at night. I should mention that I have two separate rules to turn the lights off: 1) if No Motion, delay light off for 10 Minutes, and 2) Light off immediately if illuminance >4000 (outside). This all works great except for the manual over-ride issue I mention. The “If dimmer level is above X” as described above would work great when we are only in night light mode and people are entering the room “from empty”, but actually prevents the last rule from firing at all if we are already in the room as it is phasing the lights down to the final rule since the level will be above the level from the prior rule (This is normally what happens, we are playing in the room and the lights start to phase down). I suppose I could get around this by making short intermediary rules that transition between the light levels and don’t contain the “If dimmer level is above X” condition, then the dimmer level would transition down in that intermediate rule regardless, and then the next rule containing the “If dimmer level is above X” condition would operate fine in the final stage. This is one way to do it and would probably be quite workable. So again I am an advocate of adding such a condition.
However, I think making the rules somehow aware if some other “synthetic” switch or button were activated, might be cleaner. Then the rule would just not fire if those synthetic switches were on. However, I currently have no idea how to use/create a synthetic switch that when I press it turns the dimmer to X% as the “on” condition (probably a button on the android phone first, and also later and better some type of physical toggle button on the end table). And I don’t believe the Rule Machine App has a condition type to look for this switch being “on”. I would also be an advocate of this capability.
I would be happy to help on this if I could since I know the logic I am looking to implement, but have never done any groovy programming and it would be a bit slow/painful process to get up to speed.