Migration of DSL rule from 2.5 to 3.2

Setup, Configuration and Use Migration
1

I have a rule that broke during the migration from 2.5 to 3.2. In the rule, there is a condition I check for - a string becoming null:

when Item EcobeeThermostat_EquipmentStatus changed to “”

This worked correctly in 2.5. After the migration, when I look at the rule in the UI, it shows the body of the rule as it existed, but at the top shows the trigger condition:

// Triggers:
// - When EcobeeThermostat_EquipmentStatus changed

and in fact it does now triggers on any change - not the desired behavior.

So where does this migrated trigger condition actually exist so that I might fix it. It is not in the rules folder and can’t be edited in the UI. There is a lock icon on the top right that says: “This rule is not editable because it has been provisioned from a file”

2

As the UI states that it cannot be edited it must be in the rules folder.
In OH3 the rules folder is in /etc/openhab/rules assumed you use a linux environment.
In case that does not help you may look into /var/lib/openhab/jsondb/ where UI stored sutff can be found. Be careful in case you edit these files.It may break stuff…

3

In the /etc/openhab/rules folder, the original rule from OH2.5 exits with the correct trigger configuration. I did also look in /var/lib/openhab/jsondb/automation_rules.json but the trigger/rule does not exist there. It almost seems like the original rule is loaded/interpreted (incorrectly) at run time from the rules folder in which case how might I fix it?.

4

Did you try to add an additional if clause inside of the rule that does the check as you want it ?

5

This is all good and expected. You cannot edit a xxx.rules based rule from the GUI, so it doesn’t really matter how it is displayed, and it certainly will not appear in the JSONDB. So we can ignore all that.

What is in your xxx.rules file right now? This is what counts. Can you show us the events.log that you did not expect to trigger it? How do you know it was triggered?
It may well be that there is something odd about empty strings (which are not the same as null) here.

6

Here’s my rule which I now have gotten to work by doing as Wolfgang suggested and adding an if clause around the whole rule to confirm the null string which is missed by the trigger for some reason - in OH3.2, it triggers on every string change - and yes it DID work in OH2.5, only triggering when the string changes to empty. So everything is good with the updated rule with the workaround but clearly there is some problem in OH3.2 with triggering rules on empty strings. Thanks for the feedback.

import org.opehab.core.persistence

val PressureLimit = 0.05
val MaxLimits = 6
var LimitCount = 0
var FanCount = 0
var Number DiffPressure
var Timer myTimer = null

// check pressure drop across filter when fan stops

rule “HVAC Filter Fan Trigger”

when
Item EcobeeThermostat_EquipmentStatus changed to “”
then
logInfo(“HVAC”,“Filter Rule Running”)
if (EcobeeThermostat_EquipmentStatus.state.toString == “”) {
logInfo(“HVAC”,“Fan stopped, waiting for pressure update”)
var Number PrevPressure = Sonoff1_FurnacePressure.minimumSince(now.minusMinutes(5)).state
// wait 10 secs for pressure to update
createTimer(now.plusSeconds(30), [|
logInfo(“HVAC”,“Checking off pressure”)
var Number CurrPressure = Sonoff1_FurnacePressure.state
DiffPressure = CurrPressure - PrevPressure
// only log results > 0
if (DiffPressure > 0.01) Filter_Pressure_Drop.sendCommand(DiffPressure)
else logInfo(“HVAC”,"Bogus DiffPressure ignored: " + DiffPressure)
if (DiffPressure >= PressureLimit) {
FanCount = FanCount + 1
logInfo(“HVAC”,"Fan Off Pressure Delta Exceeded: " + DiffPressure + “mmHg " + FanCount + " times”)
if ( FanCount >= MaxLimits ) {
getActions(“mail”, “mail:smtp:gmail”).sendMail(“xxxxx@xxxx.com”,“HVAC Check Filter”,“HVAC Filter may need attention. Check it.”)
FanCount = 0
}
} else {
if (DiffPressure > 0.01) {
FanCount = 0
logInfo(“HVAC”,"Fan Off Pressure Delta OK: " + DiffPressure + “mmHg”)
}
}
])
}
end

Here’s an example rule trigger where the value changed - but not to a null string:

2022-02-19 14:41:53.937 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘EcobeeThermostat_EquipmentStatus’ changed from auxHeat1,humidifier to fan

==> /var/log/openhab/openhab.log <==

2022-02-19 14:41:53.947 [INFO ] [org.openhab.core.model.script.HVAC ] - Filter Rule Running

7

Hi Ron,
Did you ever sort this out?
I have just migrated my rules from 2.5, and most (?all) the rules have lost their trigger condition. Like your example, the condition shows as a comment in the top of the file. None of the rules will trigger on their own, but will run (for the most part) correctly when choosing ‘run now’.

What was your solution? Recreate them all in MainUI?
Thanks

8

My problem was that the rule was triggering on every change to the string, so more often than it should have. I just used the if block around the whole body of the rule to filter out only the change to a null string and it worked. It sounds like your situation is that it’s not triggering at all so a different scenario. Hope you find a solution.

1 Like