The Doctor Binding helps find issues with your system [4.0.0;4.9.9]

Ah, sorry, somehow I interpreted more of the info to be published as channels. Nothing to worry about then :slightly_smiling_face:

If you want the data as channels, then just use the system info binding. This binding is about being SIMPLE and nothing to setup, so that no mistakes can be made in the setup or interruption of the data. Data that is not able to be gained another way, is provided as a channel. Any feedback to improve the logs if your getting too much info or false positives would be appreciated. The goal is to make sure that people who have trouble with openHAB do not blame openHAB and move away, instead they can work out that their instability/crashes or any negative experience may be a simple bad USB lead that is not providing enough power to their raspberry PI, or something is eating all their ram outside of java VM.

1 Like

Hi, I am using the doctor binding with OH 4.3.5 on a RaspberryPi 4.
Problem: The binding frequently vanishes from the system and has to be reinstalled.
After doing this the related thing works perfectly again - until the binding goes away some days later.

The binding should only vanish after system upgrades or after cleaning the cache.
This is the default behavior for a marketplace binding.
Because I wanted to avoid these reinstalations I deinstalled and put the jar to the addons folder. The binding works fine after that but if I create a new thing I don’t see the doctor binding. I don’t have a problem with that as the things is already created but does anybody know why this is the case?

I have some heap size Problems and installed the doctor some days ago.

But where should I See the log messages? In the openHAB.log? There is nothing, but the System crashed again with 99% heap used.

Maybe somebody can describe what needs to be done to use this binding.

Thank you very much!

yes, the binding writes directly to the log when the heap increases. And you can connect an item to the channel to monitor the size too.

What are you typing into the terminal or other method to see the heap is at 99%? The binding should be telling you in the log at a INFO level long before you are full in the heap.

Thank you for the response. But it was not working on my system. No output from the Doc at all….

I use the system info binding to get the values of Java heap and put it into a chart with RRD4J.

During time I found the root cause. The Hue binding seems to be the problem. I opened another thread for that some minutes ago.

Will there be a 5.* version of this binding?

the current version from the marketplace works fine with 5.0 and 5.0.1 and probably future versions.
The only thing I noticed is that the average usage of heap is much higher in OH5 than it was in OH4.

If you moved from 32-bit to 64-bit in the process of upgrading that is expected.

I was on 64 bit already with OH4. But as I got no performance problems at all I don’t see anything to worry about

I have compiled the binding into a V5 jar found here in the marketplace:

I am planning on adding some new functionality to the binding soon so I have been testing the V5 for the past 3 weeks and it is working fine on my system.

Yes I also saw my heap jump in size when moving to V5….

You have changed some or all of the following :

1. a 64bit OS

  1. 64bit java or a different java version number.
  2. openhab compiled for the newer java, will be optimized for 64bit.

I believe I was using a 64bit OS and JAVA already, but now all of openHAB is compiled for the newer java. It may also be how this binding ‘cleans’ the heap before taking a reading of the used heap. When you ask the heap to be cleaned, it can be a recommendation to clean the heap, and there are two types of garbage collection that can be run. Each java VM may implement the garbage collection in its own way, so changing to a different java version or brand of JVM can result in a different result.

I am no expert but as you said its nothing to worry about unless your heap is now close to being full.

1 Like