Bug? or Why? Rule working with Temperature

I am running a Kernel = Linux 5.10.63-v7l+ ## Platform = Raspberry Pi 4 Model B Rev 1.4

Using the UI rule maker, “when an item temp changed” in the “When” line and a script in the “Then” line, I use a script since I have multiple switches. Showing the code below. The problem I ran into, the script would not run unless I inserted a “But Only If” statement in. Simple using When and Then won’t work. Am I looking at this wrong? I spent many hours scratching my head before I took that long shot and gave the “But Only If” a value.

  - id: "1"
      itemName: EyeBall2_Sensortemperature
    type: core.ItemStateChangeTrigger
  - inputs: {}
    id: "3"
      itemName: EyeBall2_Sensortemperature
      state: "90"
      operator: <
    type: core.ItemStateCondition
  - inputs: {}
    id: "2"
      type: application/vnd.openhab.dsl.rule
      script: >-
        // Radiator
        // 1st sync switch states incase swithes were turned off manually
        if (PwrCord1_Switch.state==(ON)) {PwrC1_Sw.sendCommand(ON)}
        if (PwrCord2_Switch.state==(ON)) {PwrC2_Sw.sendCommand(ON)}
        if (PwrPlugDual1_Switch1.state==ON) {PwrDP1_Sw1.sendCommand(ON)}

        // Compare temps with the state (and it override is used)
        if (EyeBall2_Sensortemperature.state <(72 |°F ) && PwrDP1_Sw1.state==OFF) {PwrPlugDual1_Switch1.sendCommand(ON) PwrDP1_Sw1.sendCommand(ON) }
        if (EyeBall2_Sensortemperature.state >(72 |°F ) && PwrDP1_Sw1.state==ON) {PwrPlugDual1_Switch1.sendCommand(OFF) PwrDP1_Sw1.sendCommand(OFF) }
        // Bath
        if (EyeBall2_Sensortemperature.state<68 |°F && PwrC2_Sw.state==OFF && Override_Sw.state==OFF) {PwrCord2_Switch.sendCommand(ON) PwrC2_Sw.sendCommand(ON) }
        if (EyeBall2_Sensortemperature.state>69 |°F && PwrC2_Sw.state==ON && Override_Sw.state==OFF) {PwrCord2_Switch.sendCommand(OFF) PwrC2_Sw.sendCommand(OFF) }
        // Bed 
        if (EyeBall2_Sensortemperature.state<67 |°F && PwrC1_Sw.state==OFF && Override_Sw.state==OFF) {PwrCord1_Switch.sendCommand(ON) PwrC1_Sw.sendCommand(ON) }
        if (EyeBall2_Sensortemperature.state>68 |°F && PwrC1_Sw.state==ON && Override_Sw.state==OFF) {PwrCord1_Switch.sendCommand(OFF) PwrC1_Sw.sendCommand(OFF) }
    type: script.ScriptAction

If you use GUI rule entry, it takes care of the when-then-end structure you find in DSL file based rules. Simple; no when-then in GUI rule script section, ever.

I think you need to be clear about if this Item state has units or not.

Not understanding. Shouldn’t the rule work with just the When “the trigger” and Then “the script”?

Your statement of “I think you need to be clear about if this Item state has units or not.” really confuses me. What does that have to do with the action of the rule?

Yes. Can we see the one that doesn’t work for you? I was guessing that you may have put textual whn/then sections in your script.

Well here -

you wish to compare the Item state with 90 (no units)
but here -

you wish to compare the same Item state with 72°F (obviously with units)
Readers here cannot tell if your Item really does have units or not.

The rule does not function without the Condition. Simply using the When “a trigger that works” and a Then which is my script

  if (EyeBall2_Sensortemperature.state <70 |°F) {PwrPlugDual1_Switch1.sendCommand(ON)}
  if (EyeBall2_Sensortemperature.state >73 |°F) {PwrPlugDual1_Switch1.sendCommand(OFF)}
  if (EyeBall2_Sensortemperature.state <68 |°F && Override_Sw.state==OFF) {PwrCord2_Switch.sendCommand(ON)}
  if (EyeBall2_Sensortemperature.state >69 |°F && Override_Sw.state==OFF) {PwrCord2_Switch.sendCommand(OFF)}
  if (EyeBall2_Sensortemperature.state <67 |°F && Override_Sw.state==OFF) {PwrCord1_Switch.sendCommand(ON)}
  if (EyeBall2_Sensortemperature.state >68 |°F && Override_Sw.state==OFF) {PwrCord1_Switch.sendCommand(OFF)}

Won’t work until in the UI I add the condition. I used 90 since I want the rule to always work. You mentioned units, the UI does not allow unit definition.

So is this a bug?

How can you tell? “Did not do what I expect” is not the same as “didn’t do anything”. A common investigative approach is to put a logInfo() at the head of your rule script section, to confirm triggering. You can also use to log out key info, like an important Item state.

What type is your Item? Can you show us what you tried to define?

I doubt it, but bear in mind we have not yet seen the failing rule.

EDIT - I have a feeling the following is still true, meaning that a simple “but only if” condition still does not work with quantity state (with units)

The workaround is to script the condition instead - but you don’t care about that, because you don’t want the condition at all here.

MORE EDIT - looks like this will not be made to work (simple comparison with quantities) but clearer warnings will be given

Again, this does not affect you if you don’t want any condition.

It does in 3.2. In fact it will complain in then logs (but still work assuming the default units) if you neglect to include units and the Items that trigger it has units.

There must be something else going on. All three parts of the rule are optional. You can have a rule without a condition. In fact most of my rules don’t have conditions. But adding a condition creates a new place for something to go wrong.

Maybe you need to be more specific about “won’t work”. Those two words contain infinities.

Yes it should.

You’ve got a Condition defined in your rule as posted. So we must take that into consideration.

There’s no logging in there. How do we know that the rule isn’t running and just not working the way you expect it to?

That shows you are using units with this Item to compare in the if statements. Is this Item defined as a Number:Temperature?

:man_shrugging: We don’t have enough information from you to guess. I’d probably say it’s a config problem since no one else is reporting this as a problem.

Thank you for the info, you are correct about not working the way I expect it to.

I am not savvy enough in programming to understand all of what you said. I learn by trial and error from example of others. I am not interested in becoming a programming tech just a guy that loves Openhab and the PI to make an automation system for my home. Been using Openhab for going on 5 years now. Again thank you!