Possible bug: rules fire more then once

The curlCmd in your weather rule contains the “”.
In my case that character was the case and my string did work without it.
You could check for the rule to be firing only once by removing this string or only those characters, however the curl command won’t work that way.

@opus I’ve changed

var String curlCmd = "curl -s \"http://site.com/api/sensorsValues?sensors=2176,2177&uuid=xxx&api_key=xxx\""

to

var String curlCmd = 'curl -s "http://site.com/api/sensorsValues?sensors=2176,2177&uuid=xxx&api_key=xxx"'

and right now only Debug rule fire twice and only at hh:mm:40, very interesting… Do you have any idea regarding this?

UPDATE:
Checked once again, it’s not fixed my problem. Some rules fire twice or even tree times!

Sorry, but I have no explanation for this. I had the same problem, even with rules fired multiple times. I could pinpoint the cause in my case to that character,. I didn’t find any reason for that, especially because the rule was running normally when saved after starting OH2.

hotfix implemented for Raspberry Pi3:

sudo nano /etc/rc.local

add this

cmd1="sleep 1m"
cmd2="touch /etc/openhab2/rules/_default.rules"
$cmd1 && $cmd2 &

before

exit 0

I have the same problem on current stable build. The main problem is, that even System started event got fired twice on a fresh openhab2 service start.

Same issue.
System started is fired 3 times after reboot

Cron triggered rules are running three times also. And I don’t have any \ in my rule files anymore. That looked like a problem, described in another thread.

I’m in the same position - eliminated string formatting as the potential problem. I only have this issue with cron rules, not any other rules (and I have a lot!)

Try to fix your string formatting and give a feedback here. Because for me this fix didn’t work.

Fixing string formatting did not helped anyone in this thread as I understand.

So how you plan resolve it?

I’ve resolved rules/sitemaps loading multiple times upon edits - sadly had to ditch my text editor (Atom) for one which saves in a different way.

I haven’t been able to resolve cron jobs firing multiple times. Seems to be a bug.

I’m seeing a similar issue using cron and Astro events. Here is my rule (partial):

rule "Set Time of Day"
when
	System started or
	Time cron "0 0 5,8,22,0 * * ? *" or           					//Times:  5:00, 8:00 , 22:00, Midnight
	Channel 'astro:sun:local:rise#event' triggered END or			//Sunrise
	Channel 'astro:sun:local:plus30:rise#event' triggered END or		//Sunrise Delayed
	Channel 'astro:sun:local:minus30:set#event' triggered START or 	//Early Sunset
	Channel 'astro:sun:local:set#event' triggered START	  		//Sunset
then
    // Sleep for just a bit to make sure we are not exactly on the time period boundary
    Thread::sleep(1000)
	logInfo("Time of Day","Set Triggered")

And here is what I’m seeing in my log file, the logInfo repeated twice with the same time stamp and sometimes the rule seems to fire random times as well

2017-02-21 17:11:01.025 [INFO ] [e.smarthome.model.script.Time of Day] - Set Triggered
2017-02-21 17:11:01.025 [INFO ] [e.smarthome.model.script.Time of Day] - Set Triggered
2017-02-21 17:11:01.072 [INFO ] [e.smarthome.model.script.Time of Day] - Current time of day is now EARLYEVENING
2017-02-21 17:11:01.072 [INFO ] [e.smarthome.model.script.Time of Day] - Current time of day is now EARLYEVENING

2017-02-21 17:14:01.028 [INFO ] [e.smarthome.model.script.Time of Day] - Set Triggered
2017-02-21 17:14:01.028 [INFO ] [e.smarthome.model.script.Time of Day] - Set Triggered

2017-02-21 17:39:01.029 [INFO ] [e.smarthome.model.script.Time of Day] - Set Triggered
2017-02-21 17:39:01.029 [INFO ] [e.smarthome.model.script.Time of Day] - Set Triggered
2017-02-21 17:39:01.089 [INFO ] [e.smarthome.model.script.Time of Day] - Current time of day is now EVENING
2017-02-21 17:39:01.089 [INFO ] [e.smarthome.model.script.Time of Day] - Current time of day is now EVENING

2017-02-21 17:42:01.021 [INFO ] [e.smarthome.model.script.Time of Day] - Set Triggered
2017-02-21 17:42:01.024 [INFO ] [e.smarthome.model.script.Time of Day] - Set Triggered

Hey did you find the solution? I’m in the same situation.

Astro binding events have changed a lot in two years. You’d best identify what version you are using, and be more specific about what problems you are having.

My rule seem to work but the infos are logged twice (and maybe so the rule)

2019-02-24 21:37:05.848 [INFO ] [g.eclipse.smarthome.model.script.SDB] - Aucun timer en cours, définition d’un timer
2019-02-24 21:37:05.852 [INFO ] [g.eclipse.smarthome.model.script.SDB] - Aucun timer en cours, définition d’un timer
2019-02-24 21:54:07.851 [INFO ] [g.eclipse.smarthome.model.script.SDB] - Fin du timer, Extinction de la ventilation
2019-02-24 21:54:07.855 [INFO ] [g.eclipse.smarthome.model.script.SDB] - Fin du timer, Extinction de la ventilation

my rule

var Timer SDBTimer = null

rule "Ventil OFF Timer"
when
    Item DomintellBIR2320_Output2 received update OFF
then
    if(SDBTimer === null) {
        logInfo("SDB", "Aucun timer en cours, définition d'un timer")
        SDBTimer = createTimer(now.plusMinutes(17), [|
            logInfo("SDB", "Fin du timer, Extinction de la ventilation")
            sendCommand(Ventilation_Switch, OFF)
            SDBTimer = null
        ])
    } else {
        logInfo("SDB", "timer en cours, reprogrammation du timer")
        SDBTimer.reschedule(now.plusMinutes(17))
    }
end

Ah, nothing to do with Astro then.

I would suspect multiple updates to your Item. There is nothing to stop other rules or any bindings updating an Item as often as they want, and to the same state if they like.

Maybe a rule trigger of changed to off would be more appropriate for you.

Good idea, will try :slight_smile:

edit : no double rules now :slight_smile: thank you!

My experience showed me that the problem points mostly to ghost rules. That can be fixed with restarting oh, maybe with cleaning the cache.

Another cause is the one from pastroboy. Several log statements, because the log was triggered several times. :slight_smile: