I have a rule I have been using for months that has worked well. The rule is triggered if the ceiling pot lights in the room are turned on and in turn then turns on a floor lamp. Conversely when the pot lights are turned off the floor lamp goes off.
I noticed today when I set the pot lights via dimmer slider in a dashboard the floor lamp didn't go on!?! I went to the device tab and set the dimmer to go to 49 (it was at 48) and then the floor lamp turned on. O turned off the pot lights then tried 47 on the dimmer and the floor lamp worked. Then I went back to trying 48, it repeatedly didn't cause the rule to turn on the floor lamp. Something weird about the precise value of 48 in the rule that doesn't cause a proper evaluation of the If statement.
Not a major problem for me as I won't likely hit 48 setting too often but I wonder if it is indicative a more serious logic flaw in RM?
Were it me triggering on if the cans were on or off, I would, for the purposes of the floor lamp define the dimmers as a switch on or off. The trigger and the condition. Dimmers will show up in the list of switches.
Yes I could change the rule easily enough hydro311 and croweflight. In fact I probably won't even fix it as its rather unlikely the dimmer gets set at 48 very often.
I was just bringing this forward because it is an obvious and repeatable logic failure in RM that probably has implications beyond my use case. I definitely didn't write a rule that said if the value is greater than 0 (but not 48) then do this.... I would think some rules might be very dependent on an accurate condition test. Mine is a trivial floor lamp turn on but what if it was a heater or a motor on some mechanical system? Then having "most of the time" conditions won't cut it.
This was more fyi for development team at Hubitat in case they want to investigate further.
update: FWIW the problem is the trigger in this rule. I played around with some instrumentation in the rule and learned it isn't the conditional decision in the actions, rather, when the dimmer is turned off and you command it to level 48 the trigger on "changed" never fires. It does fire on 47, 49 and every other discreet level I tested it at. Its just something about "changed" at level 48 that causes the rule to not trigger. Weird.
Guessing that's because it was on to 48, then turned off, then turned back on and still at 48. If you want to check on/off state, the "switch" attribute is what you need. A "level" of 0 is rare (the fact that your device seemingly reports it at all is odd...) and is generally just the last known or (if supported) staged level of the device. It's not inherently a reflection of the on/off state, and it sounds like this is your problem.
Probably because the level changes (as far as the hub is concerned) and generates an event in those cases? Logs will tell you for sure. But level is not a reliable method of detecting switch state, for the above reasons, so I wouldn't really spend much time figuring that out (depending on protocol, maybe an effect of different rounding on the underlying value?) and just use the correct approach for the intended condition instead.
Its not important to me as its a non critical use case and easily coded around. I lean to a rounding issue as well. Anyway I am moving on. Just a puzzling finding.
Update:
Here is my fix in the end. The problem is the "changed" condition for a trigger is unreliable with a dimmer level. For inexplicable reasons when you set the dimmer to 48 (from an off state) the trigger never fires no matter what what the prior on state was. So there must be something amiss in how the "changed" function is evaluated or some odd rounding issued that only happens at dimmer level 48..
I always prefer to have one rule for a situation rather than two, instead of one rule for positive event and one rule for the negative. It just keeps my rules tidy. So below is my fix. I trigger on the ceiling cans turning on "changed". this seems to fire whether turning on or off the light and at any dimmer level.
I could write two simpler rules to achieve the same thing but as stated I prefer to encapsulate into one rule instead. If any RM experts out there know of any warning for such a trigger condition please chime in. It works fine but I might be unaware of an unintended side effect although I doubt it.
