I used to see this type of thing under openHAB 1.6, but I made two key changes that eliminated the issues:
[ul][li]a) I fixed a Threading issue in openHAB Core impacting Rule execution.
The case it exercised involved having 2 or more Rules “sharing” the same Trigger. As you grow your system, this tends to happen more and more frequently, and it was hit-n-miss as to whether you’d see the problem (and partly, how fast your Processor is)
If you haven’t already, move up to openHAB 1.7.0 to pickup the change.
[/li]
[li]b) I moved to using locking in my Rules.
openHAB fires off your code using one thread per concurrent Rule execution. If you’ve got 3 rules, and they all fire “near” to each other, then they could all be running at the same time (each via different Rule execution contexts). This is very different from the Vera model, where stuff is [largely] running serially.
As a result, it’s possible for resources in one of the Rule contexts to need to be locked by another. The most common case occurs when you’re using sharable resources like Timers in your Rules, but there are other cases also.
See these examples, using ReentrantLock objects, for examples of the coding style:
MiOS Binding Example · openhab/openhab1-addons Wiki · GitHub
[/li][/ul]
Anyhow, before going further, take a crack and (a) and (b) above. If you still have problems, I can look at the logs to see if there’s anything obviously amiss (if provided in concert with the Rule & Item defs, and the timeframe of the key events, I can also double check if there’s something else wrong)
Separately, I was also having issues with the Nest Binding, due to a different set of threading problems. These have been sorted by @watou in the latest Nest Binding, and also more broadly fixed in 1.7.1 Core (releasing this week).
These will impact a few different Bindings, based upon where they’re at in the code but if you’re only running the MiOS Binding it’s unlikely you’ll hit those issues.