As long as you are not doing something a little off, there is no need to increase it. By a little off I mean:
- Using Thread::sleep with a sleep time of more than 200. This increases the amount of time that a thread remains unavailable.
- Reentrant Locks which have two risks. First it runs the risk of breaking which will force all the threads to become consumed awaiting access to the lock. Second and related is it consumes a thread while it is awaiting the lock instead of allowing some other Rule that can actually do something from using it.
- Long running Actions like the sendHttp*Request actions and executeCommandLine for the same reasons as Thread::sleep. Long running Rules block other Rules from access to the threads.
If you are not doing any of the above, than you are probably fine. A Rule not doing the above typically only takes 100-200 msec to start, run and complete, returning the thread back to the pool. That means you can run up to 50 Rules a second with a thread pool of 5 without any delays in Rule processing. And you would have to move up to 500 rules per second before you might notice a delay of 1 second between when an event occurs and a starved Rule executes because you’ve used up all your thread pool.
I doubt your Roomba is triggering that often.
If you are not noticing any delays in Rules triggering, you are fine. If you are seeing delays on when Rules start, first review Why have my Rules stopped running? Why Thread::sleep is a bad idea for alternative approaches you can use to get your existing Rules to behave better. Only then if you’ve determined that you need more threads you can add org.eclipse.smarthome.threadpool:RuleEngine=5 to runtime.cfg and increase the number to something larger.