Identify where is a condition


I’m running 3.4.2 Debian package. Starting from Openhab 3.4.1 (or maybe 3.4.0), I face a rule that does not operate anymore. Looking at the logs, I can see :

[ule.handler.ItemStateConditionHandler] - Received a QuantityType state '4 lx' with unit for item Living_Luminance, but the condition is defined as a plain number without unit (300), please consider adding a unit to the condition.

Clear enough : I have to rewrite my condition to add a unit. But the problem is : where is this condition defined ?

If I look at the only rule I have related to this, the condition is

when Item Living_Luminance changed

No clue about a value of 300, whether hard-coded or computed.

More surprising : if I remove the rule from the folder and restart openhab, the warning still triggers.

Clean-cache does change nothing.

Can you please advise where to search in order to identify the incriminated condition ?


see here

Review Rules | openHAB, in particular the “Conditions” section.

That’s the trigger, not the condition.

Than it’s not that rule.

Somewhere you have a rule defined in the UI that has a Condition defined (the “But only if…” section of the rule). That Condition is testing to see if Living_Luminance’s state against 300. To get rid of the warning, add an “lx” after the 300: 300 lx.

Note, this is only a warning, it’s not an error.

If you still can’t find it, open up $OH_USERDATA/jsondb/automation_rules.json and search for "Living_Luminance " until you find where it appears in a “condition” section of a rule. Take note of the rule ID and you can search for that in MainUI → Rules.

That’s a different issue. That’s using units in a trigger. OP’s problem is not using units in a condition. These are separate parts of a rule in the UI (conditions do not exist for text based rules).

1 Like

Thank you once again master @rlkoshak !

I had indeed made a UI-based rule to give it a try, and then forgot about it as I am still mainly file based.

Now I have to understand why my file based rule does not work any more after the 3.4.x upgrade, but this is a different story, not related to this warning.


Note, I filed an issue to include the ruleID in the warning message.

1 Like