Problems with rule conditions?

1

He everyone, I think I need a hand :slight_smile: Im a bit confused because I could swear that this isn’t how it’s supposed to work. I’ve upgraded to 5.0.1 and i have the most basic of rules with one condition which I start manually :
Switch turns ON, but only when the air con is in DRY mode.


configuration: {}
triggers: []
conditions:
  - inputs: {}
    id: "3"
    configuration:
      itemName: master_bedroom_ac_Mode
      operator: =
      state: DRY
    type: core.ItemStateCondition
actions:
  - inputs: {}
    id: "1"
    configuration:
      itemName: teste
      command: ON
    type: core.ItemCommandAction

That’s it. This is just a test because one of my rules started misbehaving and I started troubleshooting. I’ve tried with numbers, switches etc and from what I can see the conditions aren’t being respected.
I also tried going with dsl rules but whatever I put in the condition filled is not being respected from what I can see.
I even created dummy items, created rules to set items to the needed states but… nothing

Can anyone see what I’m doing wrong?

IMG_7365
IMG_73651170×2532 173 KB

2

Manually running the rule from the UI buttons always ignores the conditions. I believe the rule conditions are only checked if 1) the rule is trigger by one of the rule’s triggers or 2) the rule is triggered from a some other script using the rule manager and the condition boolean is set.

This usage, where you want to trigger it manually and still have a check, should probably be done with a simple script action instead of the basic item action. otherwise, you’d need two rules. One rule which you trigger manually that then uses the rule action to call the second rule (you can set the check the condition boolean in the run rule action).

1 Like
3

Oh I had no idea that was a thing… maybe I should update the first post. But wait that raises more questions for me…

So the rule I describe is my troubleshooting one that I was using to try to understand what the problem was. If you tell me it doesn’t work like that, then let’s ignore it and focus on the actual automation I am trying to setup.

I have two rules, which are being triggered by humidity values changing. I just confirmed and based on rule 1, the ac turns on, when humidity is high and switches to dry mode. All good there.
But, on rule 2, the “only if mode is DRY” is not being respected because the AC turns off regardless of the mode it is in. (E.g.: ac in cool, rule runs and turns off the ac).
I’m very confused right now… it has to be something dumb I did.
Here are the rules:

Rule 1 - turn on air con in dry mode when humidity is high


configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: Master_bedroom_temperature_and_humidity_sensor_0x00158d0003a4027e_5Fhumidity_5Fzigbee2mqtt_Sensor
    type: core.ItemStateUpdateTrigger
conditions:
  - inputs: {}
    id: "3"
    configuration:
      itemName: Master_bedroom_temperature_and_humidity_sensor_0x00158d0003a4027e_5Fhumidity_5Fzigbee2mqtt_Sensor
      operator: ">="
      state: "70"
    type: core.ItemStateCondition
  - inputs: {}
    id: "4"
    configuration:
      itemName: master_bedroom_ac_Mode
      operator: "!="
      state: DRY
    type: core.ItemStateCondition
actions:
  - inputs: {}
    id: "2"
    configuration:
      command: DRY
      itemName: master_bedroom_ac_Mode
    type: core.ItemCommandAction

Rule 2 - turn off air con when humidity is acceptable BUT only when mode is DRY. (Should not turn off when in any other mode)


configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: Master_bedroom_temperature_and_humidity_sensor_0x00158d0003a4027e_5Fhumidity_5Fzigbee2mqtt_Sensor
    type: core.ItemStateUpdateTrigger
conditions:
  - inputs: {}
    id: "3"
    configuration:
      itemName: Master_bedroom_temperature_and_humidity_sensor_0x00158d0003a4027e_5Fhumidity_5Fzigbee2mqtt_Sensor
      operator: "<="
      state: "55"
    type: core.ItemStateCondition
  - inputs: {}
    id: "4"
    configuration:
      itemName: master_bedroom_ac_Mode
      operator: =
      state: DRY
    type: core.ItemStateCondition
actions:
  - inputs: {}
    id: "2"
    configuration:
      itemName: master_bedroom_ac_Mode
      command: OFF
    type: core.ItemCommandAction
4

Edit: misread configs.

Everything looks correct to me, so I’m not sure why the second rule is ignoring the conditions. I’m on a 5.1 snapshot and I can’t say I’ve seen any errors with rules ignoring conditions.

5

Understood, then if rules are ok… I wonder if it’s something on the values being sent… back to troubleshooting.. thank you @JustinG , at least I know I’m not totally crazy :rofl:

6

I’m not familiar with the formats, but are quotes optional on the operators? The = is without quotes (unlike the others). Or should it be “==”?

7

Yeah, the quotes are just following yaml format. The = doesn’t need quotes because yaml is going to interpret that as a string by default but > has a special meaning in yaml so >= has to be in quotes to ensure it is properly read as the property value there.

As for ==, these are not formal operators, these are property values for the condition as it is then passed on to core. So, I guess when this was created it was decided that = was sufficiently clear as the property indicating an equality test.

1 Like
8

Oh I’m just using the OpenHAB gui for the rules :slight_smile: no code from me, just basic if this then that, unless. :smiley:

9

Another random thought, maybe in evaluating the state it sees the enum for DRY. Like the number 3?

1 Like
10

deleted response as initial statement was incorrect and only applies to triggers

11

Multiple triggers are treated as OR (of course, because instantaneous events can never be truly simultaneous), but conditions have always been AND. All conditions must evaluate to true for the rule to run.

12

I stand corrected I knew there was some nuance to the UI rules.

I and I did test with a cron trigger every 1 second and 3 simple switch items with conditions of if one switch was off and one switch on as defined in the conditions it only triggers the 3rd switch to on and it does evaluate and only trigger the action if both are in the correct state. However, as you also pointed out if you manually play the rule it does send the command to the 3rd switch and ignores the conditions.

this proves your statement

configuration: {}
triggers:
  - id: "1"
    configuration:
      cronExpression: "* * * * * ? *"
    type: timer.GenericCronTrigger
conditions:
  - inputs: {}
    id: "3"
    configuration:
      itemName: test_item2
      operator: =
      state: OFF
    type: core.ItemStateCondition
  - inputs: {}
    id: "4"
    configuration:
      itemName: test_item3
      operator: =
      state: ON
    type: core.ItemStateCondition
actions:
  - inputs: {}
    id: "2"
    configuration:
      itemName: test_item1
      command: ON
    type: core.ItemCommandAction

if that was the problem then the rule should never trigger to turn the AC off correct? because the 2 conditions would never resolve as true
Yet the OP says

Also the DRY value must be correct because rule 1 runs correctly

and sets the AC to DRY based on OP’s problem statement
So, the only way the OP should be seeing the rule not behave correctly is if the rule is manually played for any real trigger event it should work as he has shown it.
So, the question goes back to OP does this only get ignored when you manually play the rule or does it also occur when you have a valid trigger running the rule?
As a side note it does seem confusing that the play button to manually run the rule ignores the condition checks and just fires the action regardless. Most users would expect that clicking the play button would only bypass/simulate the trigger condition and run the entire rest of the rule including “But only if” conditions normally.

13

Are you certain it’s the != DRY condition that’s failing and it’s not the <= 55 that’s failing?

I don’t see any meaningful differences between rule 1 and rule 2 to explain why one is working and the other isn’t, so my thought goes to other things that might be going wrong.

Is it possible that the tests you’ve run make it seem like the DRY condition is the problem but it might really be the humidity comparison?

Is teh humidity Item a Number:Dimensionless Items or just Number Items? If Number:Dimensionless, did you set the unit or are you using the default?

I’m just trying to eliminate any other potential problems.

14

But Rich if that was the case then it should never trigger the off action as both of the “But only if” conditions would not be evaluated to true right?

15

Exactly, and the problem as I understand it is that the off condition is not firing the action for rule 2 even when the Item’s state is DRY. So I want to make sure it’s not the other Item in the condition that is preventing the action to run and we are mistakenly blaming the Mode Item.

16

That is not what I understood the OP as saying. He is saying it is firing and turning off the A/C when it is any mode ie cool so I interpret that is the action is triggered.

17

Then I had it backwards, but it’s still probably worth verifying what the numbers are and whether they have units.

It would also be helpful to confirm that the first rule doesn’t run the actions when the Mode Item is DRY. != is going to be true for all sorts of things and if there is an issue with that comparison, neither rule is working correctly, which can help us further diagnose the problem .

@Pedro_Liberal , is there any sort of transformation on the master_bedroom_ac_Mode? State Description metadata? Transformation profile on the link? Are you certain the actual state of the Item is DRY and not some other value that gets transformed to DRY?

In events.log, what do you see this Item’s state as?

18

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.