since a few weeks, my OH instance has problems with UI delays (I click on a widget and the reaction comes some seconds later) or OutOfMemoryErrors (OOME). The OOME where probably caused by IPCam binding (there was something in that way in the log file, but after shutdown -r, the log was cleaned).
Then I read in this topic something similar. Because the problems with UI delays comes now more often (=in shorter intervals), I want to follow the recommendations of that topic. But:
The topic recommends to set UPDATE_IMAGE=false in things file. But the current doc has no such config option; there are some other which sounds very familar:
updateImageWhen = Not set in my things file. Therefore default config is used, i.e. image channel never updates. Is this one equal to the recommended setting?
pollTime = Set to 5 seconds in my things file. Should it be disabled?
Here is an example from my things file: Thing ipcamera:onvif:cam01 "IP-Kamera" @ "Carport" [ ipAddress="192.168.xx.yy", username="example", password="xyz", port=80, onvifPort=8000, serverPort=9997, pollTime=5000 ]
I am running OH3 on a RPI4, 4GB (running latest nighly builds) . Since a few weeks I am experiencing OOMs as well. I get thousands of open threads, OH becomes extremely sluggish and then crashes. I have not been able to pinpoint why this started to happen.
I do not find anything obvious in the logs…
I am currently testing binding by binding. At the moment I have disabled the IP camera things, to check if they’re the culprits.
In fact, the other thread looks quite similar. Thanks for that hint!
OH version is 3.0.1. For displaying images I use
element of type “image” in sitemap; and
widget “image” in habpanel
It looks like, that the time span between these problems becomes shorter. At first time, I re-start OH after 4 weeks, then two weeks and now 10 days. Beginning of June I’ve installed a second IP cam.
If u know the console, check what version of netty is installed, I think the core updated to a new netty around the time people started to first report this. If so it is not hard to roll back the netty library that this binding uses, but yes the first step is confirm which binding is the cause.
shell:info command in the console allows you to look at thread count and more.
But I want to stress that the first step is confirm which binding causes it otherwise you will waste your time looking at possible fixes which will never do anything for your problem.
@BananaBender
Also the second point is not to look at RAM as java does NOT USE the ram like normal programs, it uses a special slice of the ram called the HEAP. You can see the heap growing and shrinking with the console command shell:info But if people are saying the threads are going out of control that is something the system info binding can look at provided that they are growing BEFORE the system runs out of heap, as when java has no more memory to use you can not trust any readings as it is not working right anymore.
Lastly another angle to try is, stop using snapshots in a image card and switch to using a mjpeg stream as it uses different code in the binding. Snapshots.mjpeg should not be used in this test as it uses snapshots so wont be using different code. The binding has three different ways to get a picture, snapshot, mjpeg and also HLS, so change to another method as a test.
Just a follow up.
Since disabling the IPcamera things, I have had no memory issues.
This could of course all be coincidental. I will delete my camera things and set them up again, eliminating any configuration issues I might have had.
Does this binding use the serial connection? could it be part of the implementation of nrjavaserial as the serial interface with OH? which has a nasty bug described here
No, the binding only uses Netty for http communications and does not use a serial port. Strangely thou the binding does seem to interact with the Zwave and Zigbee bindings, how exactly I do not understand. See thread on USB serial dongles staying offline unless openHAB is started with the cameras paused.
At this point I feel it is most likely the image card that causes it as I have changed a number of my cameras to try and reproduce this using the custom widgets and different types of streams and have not seen any issues for 10 days non stop testing. I’ll try a image card next.
@Daniel_Linder and @BananaBender how are you displaying the camera/s? what card/widget and what type of steam and is it left running non stop on a tablet?
Differences in thing config are such params like label, IP, username/password and serverport.
I’m not using a streams in this context within OH. The IP cams are used as a “smart” motion sensor. For displaying images in UI are used:
Sitemap: Element of type “image”
Habpanel: widget “image”
Refresh-rate of the images is set to 5 seconds. But AFAIK, the UI is only refreshed, if it is opened (if you open an OH UI then the initial displayed image is from last visit, e.g. some hours old). Habpanel is used on a tablet and notebook; sitemap on smartphones. OH is not permantly opened on these devices - only on demand. Most aspects are automated by rules, therefore I use the devices for OH not very often (e.g. only in the morning to check the chart with the motion alarms, in case of any problems, etc.)
Besides the images, the cellMotionAlarm channel is used by following items:
Two days ago, I’ve updated my OH from 3.1 to 3.2. Since that update it looks like, that the problem has been solved. The number of threads is not increasing anymore. I’m going to observe it in the next days, but until now it looks good!
Thank you (@all the OH developers and especially @matt1 ) for this x-mas present!!!
