Switching from OH3.4.5 to OH4.0.4


So far the OH3 version has been running without any problems in Docker on a Synology DS918+ with DSM 7.2. A few days ago I decided to switch to version 4. To do this, I created new directories, as can be seen in the following yml file. Version 3 was then deleted via Portainer and Openhab 4 was created.

version: '3.3'
        container_name: openhab4
        network_mode: host
            - '/etc/localtime:/etc/localtime:ro'
            - '/etc/TZ:/etc/timezone:ro'
            - '/volume1/docker/openhab4/addons:/openhab/addons'
            - '/volume1/docker/openhab4/conf:/openhab/conf'
            - '/volume1/docker/openhab4/userdata:/openhab/userdata'           

            - CRYPTO_POLICY=unlimited
            - EXTRA_JAVA_OPTS=-Duser.timezone=Europe/Berlin
            - OPENHAB_HTTP_PORT=8088
            - OPENHAB_HTTPS_PORT=8443
            - USER_ID=9001
            - GROUP_ID=9001
            - LC_ALL=de_DE.UTF-8
            - LANG=de_DE.UTF-8
            - LANGUAGE=de_DE.UTF-8
        restart: always
        image: 'openhab/openhab:4.0.4'

After installing the first binding (Shelly), the log showed me the following errors:

2023-11-20 15:39:02.517 [ERROR] [y.mdns.internal.MDNSDiscoveryService] - bundle org.openhab.core.config.discovery.mdns:4.0.4 (164)[org.openhab.core.config.discovery.mdns.internal.MDNSDiscoveryService(123)] : The addMDNSDiscoveryParticipant method has thrown an exception
java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@216043b[Not completed, task = java.util.concurrent.Executors$RunnableAdapter@19d8f477[Wrapped task = javax.jmdns.impl.JmDNSImpl$1@2b1342af]] rejected from java.util.concurrent.ThreadPoolExecutor@32c3166a[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]

These messages continued to appear after several restarts of Synology. Uninstalling and reinstalling the Shelly binding didn’t help either.

In the meantime I don’t know any more advice and would like to find out how you can eliminate this error.

Thanks in advance.

Make sure that userdata/cache is empty prior docker image update. It contains files which are copied from docker image. There should be no issues with mdns out of the box, I suppose you have them because of earlier version libs are being retained.

Many thanks for the support. Unfortunately, I have to report that this tip was not successful. The user data of the OH3 version is in the directory


stored, including independent storage locations.
However, I came up with an idea. Is it possible that remnants of the old configuration still exist in the OpenhabCloud even though the UUID or the Openhab Secret have been changed? Or is it the shelly binding. I have already read that it causes problems under OH4.

Does anyone have another suggestion?

The MDNS is not tied to openhab cloud, however error message you found does not indicate which mdns participant causes exception. It could be that mdns services are indexed somehow and there is a clash. I don’t know.
Try refreshing addons (refresh $bundleId in shell), and see which bundle causes error.

I don’t know if my first message was clear enough. My approach involves a new installation. I completely deleted the Portainer stack including the OH3 container. OH4 was even installed in a different directory and you can also log in under a new username.
After the setup was completed and all entries were saved, addons such as “HTTP”, “Exec”, “OpenHAB Cloud Connector” and “Network” were installed - everything without errors. The next addon I install is the Shelly binding and then the error message appears.

Perhaps also interesting that I have some Shelly’s Series 2 Plus installed under OH3. These work almost without errors. There is now an add-on version “Shelly Beta with Plus/Pro and BLU Support”, which also produces error messages under OH4.

I am not aware of any update of the addons via the shell. It would be nice if you could describe the procedure to me in more detail.



Doesn’t any of the experts present here have any idea where the error could lie? My guess is that it’s because of the shelly binding. I’ve read that somewhere else.
Maybe someone else will get in touch, otherwise I’ll have to continue working with OH3.

Best regards

Apparently there is no solution to my problem. Then maybe someone can help me how to update $bundleId in shell. @splatch Łukasz Dywicki suggested this to me 10 days ago to update add-ons.

When you go into shell and do list, then bundle id is a number in first column. You still have to find matching name in last column. Since id is assigned during installation time it will vary on each and every installation.

Are the instructions also valid if Openhab is running in Docker on a server? When I call the command “list:bundle” in the Openhab terminal on my Synology, I get the message “unknown command”.

is a command to be executed in the karaf console. karaf console is valid/available in all environments.

Use bundle:list.

Look for yourself:

Am I even in the right place here?

No, start openHAB condole by entering

openhab-cli console 

Enter the default password.
After login, enter


I’m sorry, I haven’t found openhab-cli in the Docker version for Linux yet (only on the raspbi back then).

xxxx@ds918:/volume1/docker/openhab$ docker exec -ti openhab /openhab/runtime/bin/client
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/openhab/json": dial unix /var/run/docker.sock: connect: permission denied
xxxx@ds918:/volume1/docker/openhab$ sudo docker exec -ti openhab /openhab/runtime/bin/client
Error: No such container: openhab

Your container name is openhab3

I have bundle:list in the console now on the screen. However, I have to admit that I’m a bit overwhelmed at the moment.
This is the last line in bundle:list

251 │ Active │  80 │ 4.0.4                  │ openHAB Add-ons :: Bundles :: Shelly Binding Gen1+2

The error message always only appears after installing the SHelly binding. What do I have to do now?

In same shell window you can execute refresh 251 (number from first column) and check if log entry about MDNS discovery participant will appear. You can conduct same procedure for each binding you have. Refresh causes binding (software module in fact) to deactivate and activate again, effectively de-registering and registering back its services.

I followed your suggestion and even updated all the bindings. Unfortunately without success, the error message from my first post appears every time the Shelly binding is installed. Since this binding is very important to me, I cannot switch to openhab 4 at the moment.
My hope is still the stable version 4.1 or there are other approaches to solve my problem.