Okay, here’s what I see.
You stop and restart openHAB as part of your backup process, around 03:00
The restart causes all Items to get state NULL. (Maybe you restore-on-startup some)
Item Thermostate_AnAus gets changed NULL to OFF at 03:04
This will trigger your rule “Thermostate An-Aus”, all expected so far.
Or rather, it will trigger the rule when a thread becomes available.
At 04:03 we see the first evidence of that rule actually running, a command it issues.
Also at 04:03 some homematic Items get a routine update from NULL to xxx.
Bearing in mind these will have been NULL since reboot at 03:00, why do these unconnected things suddenly get an update too?
I am deeply suspicious of this almost exactly one hour gap. Do you have anything in logs from between these times? Any chance your system clock is adjusting, maybe some NTP feed or something?
Assuming the one hour gap is genuine, it would seem something has grabbed system resources and blocked any openHAB tasks from running.
The rule you have shown is a horrible thing, it blocks a rule thread for around 5 minutes with its long sleeps. But that is not going to cause an hour loss, unless you have many such rules.
A closer look at this rule’s results is interesting., though.
It should send three heating commands, wait around a minute, send three more, wait, send more.
What we actually see in the events.log timestamps however is just a stream of ALL the rule commands, with no one minute gaps.
I think what has happened here is that the rule is all finished before the logging takes place. Could it actually have finished an hour ago?
I’ve no idea if the bottleneck, be it an hour or be it five minutes, could be just in the logging - waiting for disc write?? - or the openHAB event bus has a queue/backlog of commands?.
For an outright guess - something is hogging your system i/o for an hour after backup. How long does an ordinary reboot take on your system?