Help ! Samsung TV Bindings with >2016 Samsung TV

Maven is a Build-Management-Tool. specifically for java

I would like to use this new binding for my Samsung Qled (65Q7FAM) 2017 model. I’m using openhab 2.4 with openhabian on my Rapberry Pi 3b, with the standard samsung TV binding. I’m able to see if the TV is on or off, which is superb and i’m using this to replace a remote to turn on and of my Denon receiver. Also setting the lights to TV mode is a nice feature.

Now i’m unable to see the Input source of the TV. I’m hoping this would be able with this binding, so i can set the lights to Game mode, Movie mode, TV mode etc.

My problem is, i’m unable to install this binding. After a lot of search this morning, I downloaded the jar file from : ( and placed it in the addon folder, but i got an error in the log file:

2019-12-28 11:57:46.930 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.samsungtv-2.5.1-SNAPSHOT.jar

org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.samsungtv [238]

  Unresolved requirement: Import-Package:; version="[2.8.0,3.0.0)"

	at org.eclipse.osgi.container.Module.start( ~[?:?]

	at org.eclipse.osgi.internal.framework.EquinoxBundle.start( ~[?:?]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle( [10:org.apache.felix.fileinstall:3.6.4]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles( [10:org.apache.felix.fileinstall:3.6.4]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess( [10:org.apache.felix.fileinstall:3.6.4]

	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process( [10:org.apache.felix.fileinstall:3.6.4]

	at [10:org.apache.felix.fileinstall:3.6.4]

I’m scared to use the maven method as mentioned above. I’m not sure what it will do with openhab. It’s very important the current samsung TV binding doesn’t break. Also, i depend a lot on openhab as it controls all my lighting at home flawlessly. I can’t find anything about reverting to the old samsung TV binding, if the new binding isn’t working. If my old binding isn’t working anymore, I can’t turn on my receiver with the current remote control which is unaccaptable.

Hope someone can give me some help and anwsers!

This package is missing:

See this post, maybe it helps?


Using the stable binding-samsungtv - 2.5.0 with a 2016 Samsung KU6300, configured entirely in Paper UI.

Getting a WARN from the internal protocol that the webSocketV2 is not running, even when the TV thing is working:

2020-01-03 08:22:17.335 [WARN ] [l.protocol.RemoteControllerWebSocket] - Cannot retrieve current app webSocketV2 is not connected

More importantly, the TV thing breaks after a while. It stops updating its power status (which is the only information state I need and use). Removing the thing and rediscovering in Paper UI restores functionality until the next breakage.

The TV is using port 8001. Any suggestions?

I’m experiencing the same behavior (It stops updating power status and other commands do not work anymore.
I don’t have those log entries because mine is an old model not using websocket.

1 Like

I have this same issue with all of my TVs. Next time this happens, restart jupnp and see if it resolves the issue before doing any config changes. SSH to the console on port 8101 and run “bundle:restart org.jupnp”. It can take several minutes for this to cycle through. There is an ongoing issue with jupnp which seems to randomly crop up and cause things to fail. See Too much time before a Sonos thing becomes definitively ONLINE for similar with the Sonos speakers. is the bug ID for jupnp.

Hi @morph166955, thanks for pushing this jupnp topic, I am waiting for a fix since a year now :roll_eyes:

1 Like

Well, at least I can take solace this is not another user configuration error that I made… :blush:

1 Like

The bundle restart of jupnp does not work for me…so by now no workaround for me :pensive:

having the same problem on an RU8009…
it works for a while after initial discovery, but stops working at some undefined point. I noticed that everytime I checked when it stopped working, the websocket secure token seems to have vanished from the configuration in PaperUI… might that be related?

Are we sure is the jupnp problem? Any official confirmation from the binding developer?! (Is this @arjanmels ?)

Does anyone have a workaround for this? I heavily rely on this binding in my day to day use also to limit kids.

Thnx! this worked! Unfortunately I only can turn on and off my TV (Qled 65 inch Q7F, 2017 model)

Does anyone own this TV and got reading the input source to work?

Facing the same issue. Furthermore the remote control protocol remains “none” even if I change it to secure web socket. How can this be configured by .things file? from time to time it works, but not all the time.
I am using 2.5.0 binding and TV is a 55Q6F.

I am also using the 2.5.0 version of the binding & after a restart of Openhab it detects the power state change to ON but then nothing else gets updated. I am only using the binding to monitor the power state for rules to control lighting. I did try the bundle:restart org.jupnp above but it made no difference.

I may have found the root of my issue.

Under 2.5.0 my TV config in the JSONDB (org.eclipse.smarthome.core.thing.Thing.json) is as follows:

      "configuration": {
        "properties": {
          "hostName": "",
          "protocol": "WebSocket",
          "port": 8001,
          "refreshInterval": 1000

But under 2.4.0 it was:

      "configuration": {
        "properties": {
          "hostName": "",
          "port": 55000,
          "refreshInterval": 1000

I have manually changed the JSONDB (org.eclipse.smarthome.core.thing.Thing.json) file to what was configured in my 2.4.0 setup & it is now working again in 2.5.0.

So it may just be mis-identifying the control type for my TV?

Mine seems fine…but it does not work anyway:

"configuration": {
        "properties": {
          "hostName": "",
          "protocol": "Legacy",
          "macAddress": "60:6B:BD:D1:4C:CB",
          "port": 55000,
          "refreshInterval": 1000

Does yours keep working in the long run?

1 Like

So far it has continued to work 12+ hours later. Before it would only work for minutes at a time.

This binding seems to be badly written. I’m on 2.5.2 now and the behavior I see is that the moment I use this binding openhab goes into R state in htop (uninterruptable sleep) which doesn’t normally happen. The plugin works ok though UNTILL a restart occurs. Then it loses all ability to control my TV (usually the token is wiped and cannot be restored). Openhab usually takes a few minutes to shutdown at this point (I’m guessing it is actually killed off by systemctl because the plugin actually hangs dead). Can Any logs be provided to finally fix these issues? I don’t want workarounds to detect if the TV is on or not. I want the full functionality.

I’m guessing that for everyone that see that it stops after some time - try to configure it and restart openhab. I guess this is the point at which it stops working.

Please be aware there are some fundamental issues with this binding and jUpNp. It was taking down my Sonos devices for over a year until we figure out it was the SamsungTV binding.

Here’s the active debug on it right now.

Best, Jay

Hi All,
to echo previous comments, I observe lost of reliability in binding 2.5.2. What I found too is that in the jsondb file I have settings:

          "protocol": "None",
          "port": 55000,

whereas if I click on the thing settings for some reason it forces in the GUI Websocket (2016 and above) and port change 8001. Pressing OK often (not every time) breaks the thing but I didn’t see it written to the jsondb file which I intended to change as some of the guys suggested above (any I was surprised it didn’t change). Any try in the GUI of changing from Websocket/8001 to None port 55000 is unsuccessful, it still displays the same

Losing the token is driving me nuts. I find that I can keep it working… but every time openhab restarts I have to be near the TV to accept the “new” connection with the remote. None of the settings in the TV allow for and always allow type connection.

Hopefully @arjanmels is able to take a look at this when he has some time.

Otherwise the binding seems to work well.