Slow/delayed responses and output to devices


my current OH setup is now getting to be a bit bigger than most i would say and I think that that is causing OH to respond very slowly.
For example I can hit the button to say turn on a light which I see populate in the OH debug screen instantly but it is more than a second (or 2 or 3) before it actually communicates to the device as seen in the debug screen.

Therefore when a rule runs it can take quite sometime for all of the devices to receive their information.

Is anyone else having this problem?

Is there a way of “breaking up” the system to have it respond quicker?

Some have reported great performance improvements switching to the JSR233 and jython in their rules.

There are certainly many performance improvements that could be made to your existing rules. I’d be willing to take a look if you post one or two rules you are having particular trouble with.

But first one would ask:

  • what are you running on?
  • how many Items?
  • how many groups?
  • how many rules?
  • how many bindings?
  • what are you using for persistence?
  • how much CPU and RAM is OH using and its that close to the machine’s limit?

Perhaps but in order to really answer that it will require a far greater understanding of what is causing the slow down. The first and most obvious thing would be to see if there is a way to partition your configurations into independent segments and deploy them to separate OH servers running on separate hardware or VMs.

The most likely culprit, without further information, is that your OH instance is consuming too much RAM on your machine.


FYI this issue is not to rules, just a single ON for a light will still take 2 ( just checked again now and it is 5 ) to complete!

I have had it running on several different machines, currently WIN10 i7 3.4GHz 8 RAM, no noticable affect on CPU or ram usage- just idling over.

Around 150 Items

35 groups

20 or so Rules

Currently using myopenhab for persistence, There was other persist loading and i got rid of them and performance improved slightly but still.

Mmh, I sometimes do experience this, too, but of course it’s hard to say if the root cause is the same.

First thing to check are config or rule changes that result in the need to internally recompile at times when the code is used for the first time (which can be quite some time after the actual change). I’m seeing CPU spikes at times, but I didn’t investigate further. Either way, try to not change anything for an hour and see if your problem (accessing the same items/rules) can be reproduced an hour later.
For me, that helped a lot. Very few to no visible occurences as long as I don’t change anything. I guess that’s the origin of the saying ‘Never touch a running system’ :slight_smile: .

But from my experience, when things get slow, it’s rarely OH main software or HW but a communication channel that enforces serialization and sometimes message queueing adds up to noticeable delays.
I have ~100 devices, several groups and rules, and run it on a RPi2. It’s far less powerful than your HW, still it’s idling most of the time (except when restarting OH).

Now I didn’t cross-check with the code, but the usual way of programming is to log messages AFTER a successful operation. So it doesn’t mean that in the 2-3 seconds of apparent inactivity there’s NO OH communication to the device. Could mean as well there IS, but it ain’t successful. Or could mean the comms channel is blocked so OH cannot send.

Radio delay and timers add up. If you do the math, to send a series of commands (as you do if you address groups of items) WILL take quite some time.
Remember radio comms is a SINGLE, completely serialized channel with a potentially large queue. You can have many rules at the same time waiting for the radio commands to finish that they issued.
Think of it as a sports event: many people rush to the stadium in fast cars, but then everybody has to lineup at a single entrance for access control. A faster car won’t help.

There’s a lot happening at the radio layer that you usually don’t notice: status (reachability) messages, radio interference resulting in retransmits. You don’t get OH debug messages for most of these things.

Plus, there’s a regulatory rule that each device using the 868MHz frequency (EU) may occupy at most 1% of the bandwidth, and as far as I know, device manufacturers properly implemented it. That also applies to the controller(s), effectively introducing delay, especially at peak times. I’ve seen that happen.

Plus, some effects are hard to find. You can’t properly see them in logs, such as this one:
I recently noticed that after sending a couple of zwave commands, I kept getting log messages about my maxcube (thermostat management server) not responding properly.
maxcube communicates with thermostats using a proprietary radio protocol using the same radio frequency as zwave does. The zwave binding ensures that zwave messages don’t collide, and probably so does maxcube, but if you think about it, it becomes obvious that at peak times, zwave and maxcube messages interfere because the two subsystems don’t know of each other. Once a zwave and a maxcube message collide, both subsystems will resort to a series of retransmits, still independent of each other, in effect greatly reducing the effectiveness of the radio band.

What to do? Well, I’m struggling somewhat, too.
I’ve checked radio timers and retransmit options (to the extent possible).
I’ve rearranged the order of commands to obtain zwave and maxcube ‘blocks’ of messages and put a Thread::sleep() inbetween.
See if that might apply to your setup as well.



Thanks for the input,

I don’t use any radios in my setup, all hardwired via ethernet using UDP.
It all seems to be in OH, if I debug it you can follow the timestamps through as it finds a socket, creates one, transforms via the map and then actually sends it.

I also just started a OH2 installation and with the same items etc, it seems to be far more responsive. Having said that I can’t convert to OH2 yet because I don’t understand how it works and how to configure it all so I must get OH1.8 working.

For OH2, you can almost copy your whole configuration and use it as in OH1, certainly without the benefits like autoconfig. Be aware that OH2 is still in beta state, though it is very reliable yet.

openhab.cfg has been split in one-file-for-each-binding, see the wiki for details

150 items and 20 rules does not sound like an overly large setup. I’ve seen postings with setups with twice that. 35 groups could be lot depending on how you are using them and it might be a source of delay. If the bulk of your Items are dealing with a single binding that could be a bottle neck.