This post is meant to summarize the most often encountered problems to appear after you upgraded your system to 2.5 (or 2.5.x, actually). I’ll update/extend it over time.
Let me know if you feel there’s substantial stuff missing (issues) or insufficient (explanations how to fix).
** Anyone: **
** Please check these out first before posting about your problem. **
This post assumes you ran 2.4 before your upgrade. If you upgraded from some earlier version or some non-release version “somewhere inbetween releases”, there of course can be other issues. These are not to be attributed to the 2.4->2.5 step like for example the well-known need to recreate your zwave things was in effect already when you upgraded to 2.4. Those issues are not listed here.
For reference and your own studies, here’s the 2.5 Release Notes.
Also remember OH development moves on while this text is mostly static so it may be outdated by the time you read it.
high CPU usage
- OH to constantly use a lot of CPU (more than 100% = a single CPU core is hogged)
- OH logging to show restart of bindings or any other module every minute
- eventually errors such as
Dispatching event to subscriber ‘(... some name or ID ...)’ takes more than 5000ms
Out of memory, high memory usage
- top, free or any other tool to show abnormally high memory usage
Do not arbitrarily restart OH. That’s NEVER the right fix. Find out and fix the root cause first.
Note that there’s a “coincidence” factor involved whenever you restart OH. The order the software modules are loaded in may remain or change every time.
And issues can show up in one order while they may hide in another. But that does not mean they’re “fixed”. And no, you cannot enforce any proper startup order.
High CPU usage
Enable OH logging on DEBUG level for:
org.apache.karaf org.openhab.core (eventually) org.openhab.binding.* (eventually, just one-by-one, just those you use)
Out of mem
Identify the component to have a memory leak
Use system tools
swapon -s for a first diagnosis. Watch memory and swap use over time. It shouldn’t grow and settle quickly. Absolute figures depend on bindings etc you use, but as an orientation, you can expect the OH java process to use on the order of 600-750MB on 32bit ARM (all RPIs).
On 64bit x86 it can be up to 4 times as much.
If memory usage is constantly growing, analyze by removing components (bindings) from config, then see if that stabilizes memory use. You can do that one-by-one or in batches.
The common cause to many issues is that the location of some code inside OH changed but the configuration was not properly changed to reflect that.
- it may be required to restart OH after you made the changes below
- you should clear the cache.
How to fix these depends on whether you use PaperUI or textual configs.
In text config, there are lines in
$OH_CONF/services/addons.cfg labelled (starting with)
Be aware though that config lines to take effect may hide in any config file in the same directory to be named
*.cfg. And think of duplicates so double cross-check all
ATTENTION: always check BOTH,
*.cfg AND PaperUI, regardless of whether you only “ever” have been using one config mode or the other “exclusively”.
restdocs moved to ui
The REST documentation package used to be located in the MISC tab in PaperUI under
Configuration / Services.
In 2.5 it’s the
UI tab now. In
addons.cfg it was the
misc= line and now has to be in
The fix is to remove it from the
misc= line. Make sure
restdocs does no longer exist in the old line or that there’s two equally-labelled lines across all of
new 2.x bindings to conflict with OHv1 actions
Known bindings this applies to are:
But remember that this list is not guaranteed to be comprehensive.
Some bindings are new since 2.5 that used to be available as OHv1 actions before (actions actually all are a OHv1 thing that never changed in OH2.X).
In PaperUI these used to be on the
ACTIONS tab under
Now if you on the one hand side installed the binding but on the other hand side the old v1 action was not removed at the same time, this results in problems when the old action (from the action bundle) is still used instead of the action from the binding bundle.
The fix is to remove the action from the
Out of memory
Remove the component to have a memory leak
Your prime candidate is the Amazon Echo Control binding. It is widely used and - at the time of writing - has a memory leak. Read on here for latest news.
That is fixed in the snapshot version of OH so either upgrade there or remove if if you want to stay on stable.