I was wondering if restarting openhab on a schedule is a good idea.
I’m on unraid and I used to do it each backup which mean daily. I removed the docker restart and I notice 2 behavior since then.
The first one is openhab slowdown. Like reaction when something get triggered from outside (let’s say I turn in a light switch from the physical switch). It take more time for the things to be updated.
The second one is binding stop working either totally or from one side. What I mean is, let’s stay with our light switch. I’ve had time where the thing just stop getting update from the current state of the light switch when it was physically turned on or off but changing the state from openhab still worked. I had other binding that would just stop working.
When any of those things happen, I put the binding on debug and trace and there’s no error, it’s the same stack trace as when it was working perfectly.
Turning on/off the things doesn’t make it work properly, it require a server reboot.
Unless there’s a memory limit in docker, it’s not running out of ram. I got 128gb and about 70gb free.
Am I the only one that need restart once in a while so everything continue to work properly? Do you restart on a schedule?
Oh dear, no. openHAB is designed to run 24x7, and all properly setup OH instances do so without any need to ever restart.
If you experience slowdown or bindings that stop working, there’s a small chance this is due to a yet unfixed bug like a memory leakage on some binding for tech in not-so-widespread-use.
I also don’t know what “unraid” means in terms of processor architecture, Linux config, Java version, memory related parameters and so on, and what software version you are running, but that behavior really is an exception to the rule that OH runs rock stable.
One thing that’s really worth highlighting is that this is actually one of openHAB’s big strengths.
Thanks to its OSGi architecture, bindings can be added or removed at runtime without ever restarting the system.
With Home Assistant, a restart is usually required for similar changes. In more critical setups, this can be a decisive advantage: no reboot means no perceptible gap in operation, which can really matter depending on the use case.
I, as many others, run OH on RPi and never had the need to move hosts or restart my production system except for some situations where I caused that trouble myself (as I’m a dev I test a lot).
You’re (IMHO) taking the wrong approach in aiming for a reliable service.
You should try to understand OH’s interaction with Java and OS limits first and analyze for potential crash or leakage reasons next. Only once you found and fixed that and your OH runs 24/7, it makes sense to think about hardware redundancy. And by then that will likely have become unnecessary, too.
I do not restart OH on a schedule. I run Docker as well. But I do update/upgrade frequently so my OH does get restarted relatively frequently (once a week or so, sometimes more than a month).
I do not experience any slowdowns nor problems with bindings. But there are hundreds of bindings and any problems with any one is likely going to be specific to that one binding and not a sign of a general problem in OH.
RAM is usually the limiting factor with OH but it’s not the only one. CPU, disk I/O, network I/O can also cause slowdowns as OH gets stuck waiting for access to some resource. When OH is slow, you need to do some analysis to discover what it’s waiting on.
There certainly can be a limit set when you start the container. The OH instructions for running in Docker does not have you set that property though.
There is also a limit in the amount of RAM Java will accept. That can be passed into the container through the JAVA_EXTRA_OPS environment variable. I don’t remember what the default amount of RAM the JVM will take is.
But when OH comes up against that limit it generates OutOfMemory exceptions.
Running docker doesn’t mean hardware redundancy. I don’t have a rpi nor do I need one. Openhab started as a way for me to open my garage door back in openhab 2.0 (or even 1.x). It was running aside other service on my old i3 with 4gb ram. There was no distro made for a computer back then, I started with a Windows server. I quickly moved to a linux one, then a small footprint linux with docker.
I later built a server for many many other things beside home automation. I wouldn’t have that beef of a server just for openhab. This is where unraid come into place. I decided to use my old i3 to replace my dying router and installed pfsense on it. Thus, I simply built a new docker in unraid and move my config file. No need to install anything else, it’s all part of the docker procedure, just copy the file, use the same docker-compose and your done.
Unraid allow me many other scaling and feature such as backup. I have 2 unraid running critical services in redundancy, OH isn’t one but all my network and backup services. Sooner or later, hardware need to be upgrade or crash. Even a rPi.
I doubt there’s any cpu, disk or even network i/o problem. Disk are dual SSD nvme gen 4 in raid 1, ram is 128gb ddr4 ECC, cpu is a xeon gold w2275 which have a load of about 25%, network is 10gbe with about 1 to 2gb use. My switch is a unifi switch pro max 48 with 2 u6-pro for wifi.
It seems to be a problem with the tp-link binding, it’s mostly this one that get trouble but I never see any error in the logs even with everything set to trace. I see him scanning properly, discovering, it’s very weird. It is an old binding that have no love for the past few years.
I love how when something doesn’t go as expected, rather than checking and confirming, so many just assert “that can’t possibly be the problem.” It’s funny how often that actually is the problem. Is it in this case The world may never know.
That’s a relatively easy test. Disable the binding and see if the slowdown continues to happen or not.
In 5.1 (maybe 5,0, I can’t remember which) a warning log statement was added in core to warn if the Thing thread pool appears to be consumed by blocking actions. But there may be something causing that not to trigger even though the binding is consuming all the threads. Runtime Commands | openHAB should tell you if there are a bunch of threads sitting around blocked.
To add some cents: I run openHAB in ProxmoxVE as LXContainer.
I do not upgrade or change openHAB settings a lot and I only restart openHAB when I restart my Proxmox environment, this is maybe once a month due to updates to the kernel.
I don’t experience any slowdown over time.
As I use ZFS as my main file system, I do backups frequently (every 15 minutes…).
openHAB 5.1.1, LXC with Debian trixie, kernel 6.17.4-2-pve (Proxmox VE 9.1.4)
Who said I didn’t check? I have monitoring 24/7 on all my dockers and all my host component that record each second what is going on, including all ressources usages for each vm, each service, the whole server and such. I even stated that my cpu never went over 25%, told about my network, etc. The SSD are far from having not enough I/O either from read or write (they don’t even reach 20% of there rated I/O). Also, the slowness is constant and get worst over time which if it was a CPU overload for instance, would calm down once the cpu is clear. Openhab docker CPU allocation never went over 2%. Same for out of ram. I know it’s not a component issue as out of ressource since there’s absolutely nothing indicating it. There’s no storm on my network causing latency, there’s no overload either on the docker system, openhab docker, the host, etc. It’s the first thing I did, check if something was locked somewhere. The log file on debug and trace showed absolutely no problem on anything, no lock, no error, it was business as usual. It doesn’t mean there’s not something going on with Java, might be a garbage collector issue or something else but not something I can see in all of that. I’m not posting for the sake of whining, I’ve been trying to understand that problem for the past 4 years. I even started a brand new openhab instance with brand new config thinking it might be old stuff in it because I did install many add-ons manually in the past. I’m pretty sure TP-Link is one culprid, but absolutely nothing shows me a problem with it in the end.
I’ll check with the threads next time to see if something is blocked.
The reason is that the host (Proxmox) runs updates via cron and for a reason I did not yet find out, openHAB becomes unreachable after the cron. Since I’m lazy, it is easier to just restart the container instead of finding the cause
I never restart openHAB without purpose.
it ran for like 10 years on a RPi (openHABian being the only stuff on it), only reboot with errors once in a while and openHAB itself restarted with updates and upgrades. Sometimes running for months without anything. (and I have and had around 2000 items from about 60 things and 20 bindings. perhaps like 500 channels or so?
I changed for docker since two years (?) now. same here. container restart on updates only.
the problem is almost ALWAYS (if noth 100%) how you built your environment. I bet there’s a very high chance of the configuration around openHAB and a very tiny chance of an NPE or something within a binding. My bet is simply on how you setup your Unraid in the first place.
I guess you don’t really know how unraid work. It’s simply a supervisor. OpenHab is running into a docker which is the official docker.
For exemple, right now, notification stopped working. Looking at the log, I’m getting these kind of error.
2026-02-17 08:47:06.251 [ERROR] [.handler.AbstractScriptModuleHandler] - Script execution of rule with UID ‘nodered-1’ failed: The name ‘sendBroadcastNotification’ cannot be resolved to an item or type; line 8, column 3, length 89 in nodered
Once I restart, it start working again.
This is a simple rule that I use all the time used by nodered to send broadcast notification, nothing crazy.
rule "Send Broadcast"
when
Item vBroadcast received update
then
if (sBroadcastIcon.state.toString == ""){
sendBroadcastNotification(vBroadcast.state.toString,"","info")
}else{
sendBroadcastNotification(vBroadcast.state.toString,sBroadcastIcon.state.toString,"info")
}
end
I had the same problem with the simple notification rule
2026-02-17 08:50:39.115 [ERROR] [.handler.AbstractScriptModuleHandler] - Script execution of rule with UID ‘nodered-3’ failed: The name ‘sendNotification’ cannot be resolved to an item or type; line 30, column 3, length 98 in nodered
rule "Send Notification to "
when
Item vNotifyMe received update
then
if (sNotifyIcon.state.toString == ""){
sendNotification("####@####", vNotifyMe.state.toString,"","info")
}else{
sendNotification("####@####", vNotifyMe.state.toString,sNotifyIcon.state.toString,"info")
}
end
Out of nowhere, this stopped working. Just restarted the openhab docker and boom, it work. Have nothing to do with Unraid.
I used to restart regularly a couple years ago. I was having an issue with what I thought was a memory leak and accumulation of running processes, so I setup a rule to restart openhab overnight whenever the process count exceeded a set number.
But the issue was resolved so I stopped doing this some time ago. Now I don’t restart unless I have a specific need. Seems to run just fine with this approach.
It’s only active if (I think org.openhab.core) DEBUG logging is enabled. And, that’s a good thing, because this “surveillance” is quite performance-demanding in itself.
Generally to @Nodiaque I’d say that no, restarting OH reguarly should not be required. I’m not one of those that think you have to run the latest updates, so mine typically runs for months at a time (it has battery backup - not a UPS as such, but batteries on the RPi).
But, there can be problems, usually they are related to some binding. If something goes wrong in a way that results in an exception/error, the problem will usually be logged if the binding is in DEBUG. But, there are other failure modes that don’t generate logs, and that’s usually thread deadlock or thread exhaustion (OH has quite small thread pools be default, so it doesn’t take much to exhaust them). It can also be that references to resources are kept when they shouldn’t, so that memory consumption grows over time until there’s too little left for the system to operate efficiently. But, in my experience, the thread issues are the most common.
I doubt that your problems are related to your hardware, OS, docker etc. That would be a rare event, like bad RAM or a failing storage device. So, most likely, the problem is with one of the bindings you use.
A good way to find out what’s wrong is making a thread dump when things are “slow”:
The problem is that not that many people know how to read one, and it can’t be a lot of work to analyze it properly. But, very obvious problems will usually be spotted easily. Another option is to enable DEBUG logging for org.openhab.core, which will log a warning for every task that runs more than - I think 5 seconds. The problem is that the number is arbitrary, you can have problems even if the tasks last shorter, and not everything that exceeds the threshold are problems. But, it can give an indication of where the problem is.
It’s even possible to use Java Flight Recorder to “record” what happens inside the JVM when running:
It’s even more job to analyze, but it provides much more details than a single thread dump, show “trends”, memory consumption over time and much more.
To fix such a problem, the problem must first be pinpointed (usually using one of the above methods), after which somebody must make a fix and the fix be released. All this can take some time, and in the meanwhile, you basically have two options:
Uninstall the problematic binding
Restart OH on a schedule that allows the problematic binding to not cause too much slowdown.
and THAT’S exactly what happens in every single “openHAB is unstable”-thread I’ve read the last 12 years using it:
number 1: people using either not supported hardware or fading SD Cards
number 2: some combination of bindings and configuration of some bindings
number 3: some totally unrelated stuff going on on the same machine running openHAB
number 4: having too much stuff going on on the very same machine, resulting in I/O errors or stressed hardware doing strange things (that’s why there’s load and performance tests in professional software development)
so, as Nadar explained => have a look at those metrics and take also a look on how your Unraid server behaves: is it stressed, because openHAB is one of many apps running on it? how is the utilization of the HDDs, CPUs, … etc. That’s where your focus should be. and a tip: please watch your language, the more it sounds insulting, the less people are keen on helping.
I’d like to point out that this isn’t quite what I tried to day. While all those are possible reasons, I personally judge it as most likely a software rather than a hardware problem, and most likely something in OH - since that’s where the symptoms manifest. “Over stressed hardware” isn’t really a thing IMO, unless things are running too hot or drivers are bugged. I myself run lots of VMs with a lot of different activity on a couple of servers where I’ve never experienced a problem from the server being “over worked”. It can be slow at times, yes, but it doesn’t magically fail because of it.
The world may never know.
