OH 4.1.1 - Several Bindings stop working after a few days

Setup, Configuration and Use Runtime
1
  • Platform information:
    • Hardware: Rapberry Pi 4B 4 GB memory
    • OS: openhabian 6.1.21-v8
    • Java Runtime Environment:
      • openjdk version “17.0.9” 2023-10-17
      • OpenJDK Runtime Environment (build 17.0.9+9-Raspbian-1deb11u1rpt1)
      • OpenJDK Client VM (build 17.0.9+9-Raspbian-1deb11u1rpt1, mixed mode, emulated-client)
    • openHAB version: 4.1.1

This is the successor of OH 4.0.4 - Several Bindings stop working after a few days - Many errors "org.eclipse.jetty.io.IdleTimeout", which I marked as solved, because it contained comments related to a different issue.

Since the latest update in the earlier thread I did the following:

  1. I searched the community for similar issues and found this: OH4 runs out of memory, which identified the shelly binding as the root cause (a.f.a. I understand).
  2. While I have only one active shelly device, I switched it to MQTT and removed the Shelly binding from my system.
  3. I then updated my Openhabian installation to version 4.1.1

The system ran smooth for about 9 days until I faced similar symptoms like before:

  • The Astro binding stopped working, so my rule couldn’t switch on the light when daylight finished. No information was found in the OH log even with debug level. Restarting the binding did help with the first try!
  • The NTP binding did not update the actual date. Here the restart did not help.
  • OpenWeathermap binding unexpectedly stopped updating the linked items. Again no entries in the logs. After restarting the binding, the thing kept in status INITIALIZING.
  • The notifications that should be sent by the Exec binding to a Gotify server, did not come up in the Gotify clients. I couldn’t find anything in the OH log even with debug level.

This was the overview from openhab-cli console showing a rather heavy usage of memory:
grafik

Here is the console output including the above steps and the java heap size:

grafik
grafik957×517 25.1 KB

This is the output of the console command threads --monitors --locks:
threads–monitors–locks_20240214_1432.txt (293.7 KB)

After restart of the openHAB service, the Java heap size is quite normal:
grafik

Can anyone see a reason for this behaviour?
Which further information is needed?

Regards Christoph

2

Right now after OH 4.1.1 running for 6 days I have the situation, that the UI, frontail and Zigbee2mqtt are not responding.

grafik
grafik802×580 29.4 KB

grafik
grafik810×550 26.6 KB

Stopping the bindings astro, ntp, exec, openweathermap and several others does not solve the situation. Only restart of OH helps. This time I run reboot.

3

The next time it stops, run top or htop (if available) to see your overall RAM situation. If stuff outside of OH is failing to run that points to an overall system problem (maybe you are out of RAM?).