Script execution of rule with UID 'tmp_RULE-#' failed

Setup, Configuration and Use Scripts & Rules
1

Hi, I do experience a problem since I upgraded from 3.4 to 4.1.1. The error message is as following:

Script execution of rule with UID 'tmp_garage-8 ’ failed: ‘publishMQTT’ is not a member of ‘null’; line 144, column 3, length 67 in tmp_garage

However, there is no tmp_garage.rules - file. Never the less, the “tmp_”-rule shows up as a duplicate under “rules”.
There is a garage.rules file with the following rule

rule “Poll garadget status via MQTT”
when
Time cron “0/15 * * * * ?” // every 15 seconds
then
val mqttActions = getActions(“mqtt”,“mqtt:broker:mosquitto”)
mqttActions.publishMQTT(“garadget/Garagentor/command”,“get-status”)
end

Since the rule is triggered all 15 seconds, the error message repeats.
Restarting OH mostly solves the issue. However, the issue occasionally appears after restart (every 3rd restart or so). As far as I can see, the issue effects only this specific rule.

There seems to be a documented and solved similar issue here.

Can anyone confirm the issue or has suggestions for a solution?

Thanks

  • Platform information:
    • Hardware: x86
    • OS: Docker 25.0.0 on Ubuntu 22.04
    • Java Runtime Environment: provided with Docker 4.1.1 image
    • openHAB version: 4.1.1
2

Make sure you have nothing but active .rules files in the rules folder. There have been reports of files with other extensions, hidden files, stuff like that being picked up.

3

thanks for your immediate reply!
I cleaned up all inactive rule files (2 out of 32 in total) even though they were not related at all to the rule in question. Restarted the system 3 times and no problem so far. Will observe further.
Thanks a lot!

4

Hi @rlkoshak, sorry to say it’s back again. Same rule, same error. Folders are clean.
Any other ideas or something I can help with?

5

No ideas. The best I can offer is to have you file an issue.

6

To (hopefully) end this topic: I found a remnant in the form of an old 3.3 binding in my 4.1.1 installation. The jar file was in a “marketplace” folder and was automatically loaded at every start.
After deleting the file, the problem did not recur.