JUPnP Library version 2.7.1.OH1 in my bundle-list?

running OH4.1.2-release on a RPi4 on openHABian 1.9c ([openHAB]{2024-05-03T10:42:04+02:00}(19d3db6), just now updated to [openHAB]{2024-05-25T06:59:42+02:00}(5d4068c))

I don’t think I actively installed a JPUnP-binding, it is not listed in the Addon-Store section. It is “suggested”, though:

I came across this as a very “late” addition to my bundles while trying to restart another binding:

bundle:list
...
331 │ Active │  80 │ 4.1.2                  │ openHAB UI :: Bundles :: Basic UI
332 │ Active │  80 │ 4.1.2                  │ openHAB UI :: Bundles :: HABPanel UI
333 │ Active │  80 │ 1.0.4                  │ reactive-streams-jvm
334 │ Active │  80 │ 4.1.2                  │ openHAB Core :: Bundles :: IP-based Suggested Add-on Finder
335 │ Active │  80 │ 4.1.2                  │ openHAB Core :: Bundles :: mDNS Suggested Add-on Finder
336 │ Active │  80 │ 2.7.1.OH1              │ JUPnP Library
337 │ Active │  80 │ 4.1.2                  │ openHAB Core :: Bundles :: uPnP Suggested Add-on Finder
339 │ Active │  80 │ 4.0.5.202311240925     │ openHAB Add-ons :: Bundles :: SolarForecast Binding

so, is it OK to have a “OH1”-labelled binding active? How is that even possible? and what does it do? is it the “suggested” binding? or something different?

This bundle is a tweaked version of the JUPnP library for OH. That’s why it has OH1 at the end, but it is not specific to OH1 and not a binding. It is an underlying protocol bundle that allows to discover and communicate to UPnP devices in your network.
It is used in a few ways:

  • As an underlying library (dependency) in all binding that use UPnP.
  • As a dependency for the UPnP add-on suggestion finder.

The add-on suggestion finders run by default and will scan your network for devices that would be supported by specific add-ons.
When the UPnP binding pops up in the suggested add-ons, it just means that there is an audio device (media server or renderer) in your network that normally would be supported by the UPnP binding. It is not installed yet, just a suggestion for installation. You can ignore that if there is no need for it. Note that a Samsung TV may support UPnP, so that can be the reason it shows up.

The libary bundle has also received major updates since OH 4.1.2, so will not have the OH1 at the end going forward.

1 Like

Thanks for your answer!
so I think, that’s the source of the bundle. Because I don’t use (at least knowingly :wink: UPnP in a binding)

I am running OH 4.1.3. Does that mean I can safely uninstall 2.7.1.OH1 JUPnP bundle?

I am surprised you still have that in your bundle list. Can you run bundle:list | grep PnP in the console?

Hello,

openhab> bundle:list | grep PnP                                                                                                                                                                                          
276 │ Active │  80 │ 2.7.1.OH1              │ JUPnP Library
300 │ Active │  80 │ 4.1.3                  │ openHAB Core :: Bundles :: Configuration UPnP Discovery
309 │ Active │  80 │ 4.1.3                  │ openHAB Core :: Bundles :: UPnP Transport
321 │ Active │  80 │ 4.1.3                  │ openHAB Core :: Bundles :: uPnP Suggested Add-on Finder
openhab>

BTW, I have (among others) Kodi and SONOS Bindings installed, but not the UPnP Control Binding. And my actual problem is that my SONOS devices all are in ERROR state, so I am wondering if the outdated JUPnP bundle might be related to that…

Thanks,
Dietmar

Don’t worry too much about the OH1 in the bundle name, it is provided by the core package and if you use the Sonos binding, it is needed, so don’t uninstall it.

Ok, sure.

Thanks Mark and Hans-Jörg for your support!
Dietmar

The reason for the somewhat strange name “2.7.1.OH1” is that a nasty OpenJDK bug was patched by Use workaround to fix high CPU usage by LinkedTransferQueue by wborn · Pull Request #3756 · openhab/openhab-core · GitHub.

In 4.2, jUPnP was upgraded to a new major version, 3.0, which provided a more elegant way to use the custom patch: Upgrade jUPnP to 3.0.0 by wborn · Pull Request #4098 · openhab/openhab-core · GitHub. After this, the naming is back to normal, i.e. simply “3.0.0” (and later “3.0.1”).