Conflicting rules that shouldn't

[heghmohqib]

Has anyone else had issues with one set of rules interfering with rules set for a different day/time/mode?

Example: I use a temp sensor to determine when to activate my A/C (it's energy save mode sucks).

Mon-Fri:
      At 1645, If Home mode Then A/C=on
Sat-Sun:
      At 0830, If Home mode Then A/C=on
Mon-Fri:
   Between 1700 and 2300
      If (A/C=off) + Home mode + (Temp=76°F) Then A/C=on
      If (A/C=on) + Home mode + (Temp=73°F) Then A/C=off
Sat-Sun:
   Between 0845 and 2300
      If (A/C=off) + Home mode + (Temp=76°F) Then A/C=on
      If (A/C=on) + Home mode + (Temp=73°F) Then A/C=off
Sun-Sat:
      At 23:00, wait 300sec A/C=off
Sun-Sat:
      If Away Mode, wait 300sec A/C off

Lets say it's 1645 on Saturday and the Temp sensor reads 73°F.  The A/C should simply turn off.  What will actually happen is the A/C will power on and off rapidly until it's breaker trips.  Sometimes it's that predictable and I can just turn off the incorrectly conflicting rule.  Other times I have no idea what's causing it to freak out.  I have to turn the rules off one by one in order to figure out the conflict.  Sometimes it's not even related.  It almost seems like it reads half the rule and ignores the rest.  It also seems like it's trying to turn it on, even though it's already on.  But instead of just setting to on, it toggles (I never use toggle).

Is it possible that, if a rule calls for a state that is already present, it toggles instead?  Because that would be the worse.  I suppose, either way, it would be ignoring some portion of the rule.  Anyone have any ideas?


On a somewhat unrelated note: Add Relational Expressions (<,>,<=,>=,!=)

[Ashok]

@ heghmohqib,

If you are creating a simple Time based or Sensor based rule, we shouldn't be facing any issues. However, when it comes to the temperature, even if there is any small difference the rule won't execute like 75.9 or 76.1 or something like that, hopefully our next firmware would give the ability to use greater than or less than equal to options that should take care of the issue.

[fillibar]

I hope that greater than/less than does come up soon...  I have temperature rules I definitely want it for and energy use rules I MIGHT try.

[heghmohqib]

Thanks for the reply.

I agree that temp is an issue as it needs to be exact (this temp sensor does not poll frequently enough to hit the rule every time).  And while I hope that's all it is, I am skeptical based on the issues I've seen.  It seems like rules that should only apply on certain days are influencing other rules outside the specified time.  I've modified the rules so that they shouldn't conflict anymore by making them a bit more vague.  It's not ideal but it's confusing the rules engine less.

[d.kiran]

I have had problems trying to understand this myself. The way almond works, I believe they should have the time after the device trigger.

The expectation is "If between 7-8 A.C. Turns ON do something", when the actual rule is more like " If A.C. Turns ON and it is between 7-8' then do something"

The time itself is not a trigger, the device status is. It's counterintuitive, but there is no good solution to represent it in a rules interface.

[heghmohqib]

This is why I quit programming.  My logical perspective always seems to clash with the syntactical perspective.  I will try taking (what I perceive to be) the current power state out of the "IF" statement and see what happens.