Platform = Raspberry Pi 3 Model B Rev 1.2
OS: openHABian v1.3-299(533a314) (NOT ua-netinst)
Services: openHAB2.1, Homegear, Grafana, influxDB
Updates = 0 apt-get updates available.
I´ve used the openHABian Configuration Tool to upgrade OH2 to OH2.1. Fixed permission also with the openHABian Configuration Tool. So everithings look fine.
Now, since a few day i randomly cannot connect to the Services. When i try to connct via SSH, i get the promt for username and password. After entering the password…nothing happens.
I can ping the PI.
Today at 15:18 i´ve restarted the system via power cut.
Here some cutouts from the logs:
openhab.log
2017-07-13 13:58:18.259 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.model.rule.runtime.internal.engine.RuleEngineImpl@1112b97' takes more than 5000ms.
2017-07-13 13:58:18.378 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.model.rule.runtime.internal.engine.RuleEngineImpl@1112b97' takes more than 5000ms.
2017-07-13 13:58:19.474 [WARN ] [org.openhab.io.net.http.HttpUtil ] - Method failed: HTTP/1.1 500 Internal Server Error
2017-07-13 13:58:27.892 [ERROR] [.script.engine.ScriptExecutionThread] - Rule 'Stromverbrauch': java.lang.Number
2017-07-13 15:18:44.554 [INFO ] [marthome.model.script.praesenz.rules] - Jemand ist Zuhause
So it seems, something (or nothing) happend between 13:58 and 15:18.
syslog, dmesg, debug, kern.log, messages didnot really show errors.
Hello, I have exactly the same problem - after approx. one day, the openhabian installation freezes. This means: no access via web or app, but I can connect to the RPi via SSH. Although “top” shows the system is almost fully idle, it takes ages to e.g. enter the karaf console (approx. 30-45 seconds waiting for the “passwort” prompt coming up).
All logs I have looked at, don’t show any hint - no error messages, no problems, just regular messages.
The system is completely unstable and unusable since the upgrade to 2.1.
@ThomDietrich: Are we the only two ones who experience this behaviour?
But there are “takes more than 5000ms” messages in my log. This is new; earlier I only had them at the beginning for my Harmony Hub - but not during the regular operation:
2017-07-15 14:07:45.930 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@b38333' takes more than 5000ms.
2017-07-15 14:09:38.777 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@b38333' takes more than 5000ms.
2017-07-15 14:11:20.654 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.io.monitor.internal.EventLogger@1746b8' takes more than 5000ms.
2017-07-15 14:11:32.999 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@b38333' takes more than 5000ms.
2017-07-15 14:12:08.033 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.io.monitor.internal.EventLogger@1746b8' takes more than 5000ms.
2017-07-15 14:12:29.550 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.io.monitor.internal.EventLogger@1746b8' takes more than 5000ms.
2017-07-15 14:12:41.111 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.openhab.core.events.internal.EventBridge@f2de2b' takes more than 5000ms.
2017-07-15 14:12:51.533 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.openhab.core.events.internal.EventBridge@f2de2b' takes more than 5000ms.
2017-07-15 14:13:34.581 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.thing.internal.ThingManager@37d1d4' takes more than 5000ms.
2017-07-15 14:13:44.734 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.openhab.core.events.internal.EventBridge@f2de2b' takes more than 5000ms.
2017-07-15 14:14:15.917 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@b38333' takes more than 5000ms.
2017-07-15 14:14:55.504 [WARN ] [ore.internal.events.OSGiEventManager] - Dispatching event to subscriber 'org.eclipse.smarthome.core.internal.items.ItemUpdater@b38333' takes more than 5000ms.
I don’t know what could be wrong, but let’s try some things:
first of all, stop OH2.1 to see if the Raspberry becomes more responsive (or the freezes are due to some other process)
sudo systemctl stop openhab2
Then, install htop (a better version of top) and check the situation.
sudo apt-get install htop
sudo htop
check cpu/mem/swap usage (press F6 and sort by percent_cpu and/or percent_mem)
It wouldn’t hurt to stop OH2.1, clean /var/lib/openhab2/cache/ & /var/lib/openhab2/tmp/ and start again to see if things improve.
I haven’t changed anything since the update from 2.0 to 2.1 - and before everything worked fine. I guess, I’ll try to reinstall mosquitto again, just to exclude this as possible source of my problems.
MQTT persistence is deactivated now; eventbus-CFG is available but not activated:
# Name of the broker as it is defined in the openhab.cfg. If this property is not available, no event bus MQTT binding will be created.
#broker=
# When available, all status updates which occur on the openHAB event bus are published to the provided topic. The message content will
# be the status. The variable ${item} will be replaced during publishing with the item name for which the state was received.
#statePublishTopic=
# When available, all commands which occur on the openHAB event bus are published to the provided topic. The message content will be the
# command. The variable ${item} will be replaced during publishing with the item name for which the command was received.
#commandPublishTopic=
# When available, all status updates received on this topic will be posted to the openHAB event bus. The message content is assumed to be
# a string representation of the status. The topic should include the variable ${item} to indicate which part of the topic contains the
# item name which can be used for posting the received value to the event bus.
#stateSubscribeTopic=
# When available, all commands received on this topic will be posted to the openHAB event bus. The message content is assumed to be a
# string representation of the command. The topic should include the variable ${item} to indicate which part of the topic contains the
# item name which can be used for posting the received value to the event bus.
#commandSubscribeTopic=
