openHAB limitations


I am building my home automation and the numbers are starting to grow: number of item files, number of items, number of rules etc. The reason is that I try to decouple as much as possible things.

My question: I know it depends on the system, I run on RPI3, openhabian only, is there any known limitation that I should not exceed:

  1. Number of item files
  2. Number of rule files
  3. Number of items
  4. Number of rules

I am mainly concern about performance (not boot time performance)


1 Like

I’m not an expert of openHab (yet), so someone should correct me or make it more specific, but I don’t think that there is a limit on these files/items. The more file you have the little slower it might get during booting, because it has to parse each file individually, but it won’t affect the performace later, since it’s parsed - ie.: loaded.

The number of items/rules, I haven’t heard anyone complaining about this. There are a couple of users who run OH on RPi and has more than 1000 items for example.

1 Like

There should be no limit.

However you should do what you can to apply DRY (Don’t Repeat Yourself) and avoid writing too many Rules that run at the same time as well as Rules that take a long time to Run.

The more lines of Rules files you have the longer boot times and loading and parsing of edits.

Finally, decoupled is good but don’t go out of your way to add decoupling for decoupling sake. There is already a huge amount of decoupling built into OH itself. You should focus on making your Items best represent the model of your home automation in a way that makes sense to you and others. If your model is so decoupled that it doesn’t make sense without grokking the gestalt, no one will be able to help you with problems.

1 Like


Sorry, too many idioms.

Grokking comes from Robert Heinlein’s novel Stranger in a Strange Land and means

to understand intuitively or by empathy, to establish rapport with; to empathize or communicate sympathetically (with); also, to experience enjoyment


Gestalt is a German word that has entered English, at least in America, through psychology and it means in a context like this “the sum total” with an implied meaning that the total is more than the sum of its parts. If you think of the phrase “Can’t see the forest for the trees”, the forest would be the gestalt.

It’s been awhile since I’ve slipped up with such an obscure idiom on this forum. I think the last one I had to explain was “red herring.” Ain’t English grand! :smiley:


This is is BTW why I think priority should be added to rules …

Boot time is not an issue. It doesn’t happen that often …

After more then 20 years working as software engineer, I will probably know how to handle this issues :slight_smile:

I know form another thread that there are limits for threads.

Threadpool = 10
which means 10 parallel rules or sleep inside a rule?

Is there a limit number for timers too?
Is there a limit for item naming? (I read somewhere in the past it is important to use no number as first character, item names are not different then)

And are there other important limitations and how to find them out?

10 simultaneously running Rules. When you have a sleep in a Rule you are keeping that Rule running but not doing anything, using up one of the threads. By default there are only 5 for Rules (unless this changed in 2.4).

Yes. By default only two Timers or cron triggered Rules can run at the same time (unless this changed in 2.4).

Item naming requirements are documented here. There is no arbitrary limit to the number of Items. A given computer will eventually run out of memory but that would be tens of thousands of Items.

There are always limits because everything at a minimum takes up some resources on a machine. But the there are so many variables involved to calculate what those would be is so high as to not be worth calculating. For example, if you have 1,000 Rules you may only be able to have 10,000 Items but if you have 10 Rules you can have up to 100,000 Items. Everything interacts. It usually isn’t worth trying to figure out unless you have a real problem.

I think this is not correct, or maybe I misinterpret this.

Since OH2.1 I use 8 timers in parallel for a random close/open of my rollershutter. They do not trigger at the same moment but they are running at the same time.

I want to use more timers to controll if a light is switched on for to long. This means I need maybe 10 or more timers run in parallel. (yes, I can use expire-binding for that, but I want to configure timer maximum run time by a number item)

Yes a bit.
You can have as many timers as you want. The limitation is with the timer execution. Only two can run at the same time. Does that make sense?

Ah, ok.

Is the 3rd timer delayed regarding execution? Or does nothing happen with this one?

I made a small test.
The 3rd one is just delayed and wait for a free slot to execute

1 Like