2.5 issues after upgrade

Tags: #<Tag:0x00007f616f7196c0> #<Tag:0x00007f616f719580>

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. **

Assumptions

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.

Symptoms

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
  • java.lang.OutOfMemoryError

Analyse

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 top / htop and free / 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.

Fix

CPU usage

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.

NOTE:

  • 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) ui, misc and action.
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 .cfgs.

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 ui=.
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 *.cfg.

new 2.x bindings to conflict with OHv1 actions

Known bindings this applies to are: mail, pushbullet, telegram
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 Add-ons.
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 action= line.

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.

14 Likes

9 posts were split to a new topic: Addons.cfg vs addons.config

Since S1566, when clearing the cache, you will need to start OH then restart again after things settle down. There used to be a lot of errors in the log, but these seem to be mostly cleaned up.
If you don’t, many people see this issue…

My understanding is that addons.config is the result of aggregating all of the sources (addons.cfg and Paper UI). Also, if you touch a line in addons.cfg, that line takes priority.

This post should be made a sticky!

2 Likes

2.5.4 mihome binding stopped working with second gateway.

Strange… I went looking for this post, but it no longer looks like it is pinned.

It was out of TTL.

1 Like

OpenWeatherMap does not provide all available channels when upgraded from 2.4 to 2.5.
Uninstalling and installing the Thing seems to be necessary.

Details here: [SOLVED] Openweathermap Binding - no difference between condition-id and icon-id