@Nicholas_Waterton
The model is: UE48J6250
I’ve tried all the other options in the past and it did not work because this series requires a pin to be entered that is displayed on tv.
All is fine here so for despite the fact that the tc is showing on by the power switch when it is turned on manually. But when I turn it on in Openhab afterwards it turns off.
As a workaround I check now if the switch is on and do not send a command.
This nice guy recommended „none“
Ah, yes, the J series are encrypted, and are not supported.
Hi,
I’m somewhat perplexed because the current response diverges slightly from the previous one. Nevertheless, if the Wake-on-LAN (WoL) signal during a call fails to deliver positive feedback for any reason—irrespective of ongoing active processes—we should refrain from transitioning the device to offline mode or toggling the power switch to the off position. This issue could also arise if the device does not support WoL or if the feature is disabled.
Hi,
I have Samsung QE65Q9FNA TV. It is a model from 2018 and is using SecureWebSocket.
Everything works fine, except that 3 or 4 times a day, it is detected as a new thing “Added new thing ‘samsungtv:tv:’ to inbox.”. Normally I could just ignore, because the thing itself is already file based configured and it is working as expected.
The annoying part is, that every time, when it is detected as a new thing, a new popup occurs on my TV. Either I wait 30 seconds until this popup disappears or I confirm the openhab request every time again.
On my TV in device manager setting, openhab is configured as always accept.
Here is my setup:
‘’’
samsungtv:tv:livingroom “Gerät Fernseher” [ hostName=“XXX.XXX.XXX.XXX”, macAddress=“XX:XX:XX:XX:XX:XX”, protocol=“SecureWebSocket”, port=8002, refreshInterval=1000, webSocketToken=“XXXXXXXXXXXXXX”, subscription=true ]
‘’’
‘’’
2025-02-10 15:32:04.210 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘samsungtv.things’
2025-02-10 16:10:00.102 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘samsungtv:tv:{same-samsung-tv-uuid}’ to inbox.
2025-02-10 16:41:30.211 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘samsungtv:tv:{same-samsung-tv-uuid}’ to inbox.
2025-02-10 18:29:16.056 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘samsungtv:tv:{same-samsung-tv-uuid}’ to inbox.
2025-02-10 20:07:43.157 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘samsungtv:tv:{same-samsung-tv-uuid}’ to inbox.
2025-02-10 20:14:58.171 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘samsungtv:tv:{same-samsung-tv-uuid}’ to inbox.
2025-02-10 20:20:58.181 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘samsungtv:tv:{same-samsung-tv-uuid}’ to inbox.
2025-02-10 20:25:58.186 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘samsungtv:tv:{same-samsung-tv-uuid}’ to inbox.
2025-02-10 20:26:58.206 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘samsungtv:tv:{same-samsung-tv-uuid}’ to inbox.
‘’’
@holger_hees
On your TV do you have device manager set to ask “First Time Only”?
When you say “container”, do you mean a docker container?
If you could post the ‘samsungtv’ log (set to TRACE) from when this happens, it would help.
I suspect that it’s something to do with the container, as I don’t have any other reports of this, but most OpenHab docker configurations don’t work with UpNP (which is what is used for discovery).
Thanks for the fast response,
“First Time Only” is already active
and the docker container is running on a “host” network, means it is running with the same network behavior as openhab running without docker.
and I enabled TRACE log level now and will provide more details when it occurs next time.
So, it is a docker container?
Even using host network in a docker container is not enough to get UpNP to work. Multicast messages are not passed by docker correctly.
So, I suspect the problems are caused by the container filtering UpNP multicast.
I will wait for the log to confirm this though.
I guess it was a firewall problem. Before I was thinking that everything related to upnp works correctly, because the TV was detected. But it seams that it was not the case.
First I added “-Dorg.jupnp.network.useInterfaces=eth0” and “-Dorg.jupnp.network.useAddresses=192.168.40.88” to openhab EXTRA args.
Container itself still runs in host mode.
But my nftables rules are forbidding anything what is not explicit allowed.
now, after I added
table inet filter {
chain INPUT {
type filter hook input priority filter; policy drop;
.
.
.
ip daddr 224.0.0.1 accept comment "accept IGMPv1 & IGMPv3 multicasts"
ip daddr 224.0.0.2 accept comment "accept IGMPv2 multicasts"
ip daddr 224.0.0.4 accept comment "accept IGMPv3 multicasts"
ip daddr 224.0.0.251 accept comment "accept mDNS multicasts"
ip daddr 239.255.255.250 accept comment "accept service (1900:ssdp, 3702:ws-discovery) broadcast"
.
.
.
log prefix "DROP [INET INPUT]: "
}
it works without these popup since 5 days now. 
btw. only IGMP multicast is important for samsung TV
I’ve upgrade to OH 4.3.5 and I was wondering if this latest binding is still valid above OR is it native to 4.3.5 now?
Best, Jay
It’s native now, so you don’t need the marketplace binding.
I do have a fix for TV source switching (if you switch to anything other than HDMI sources), but I haven’t posted that here.
I might do if anyone else runs into it, but it seems rare.
HI, I’m struggling with deleting images….quite new to Openhab so still learning the ropes. I got the image I need uploading and being set but I now need to delete. (Basically i’m uploading a image of a weekly planner to the samsung frame which I’m generating daily so need to delete the previous one). I’m ok with getting the reference id etc I just can’t get it to delete. I think I’m doing something stupid with the delete_image_list. Has anyone had it working on a frame tv (pre 2022) and if so could you share what you are passing through?
Thanks
I need more clues as to what you are doing, or what the problem is.
For example, the Samsung TV binding has no delete_image_list function, so you need to explain better what you are doing.
My Python websocket interface library does have a delete_image_list() function, but that has nothing to do with Openhab, or the Openhab binding.
can you clarify the problem? Perhaps with example code of what you are doing?
Hi Nicholas,
Thanks for responding - don’t worry I sorted it out. I was reading the documentation and using artjson. I was passing delete_image_list through to it but I should have been passing a “delete_image” request with the content_id, category_id and content_type. Using that it works fine!
Thanks again for responding!
No problem, I figured out later that you were probably using the artjson channel to send direct api calls.
Glad you got it figured out. Early (v1) api calls use delete_image, the later api (v2) uses delete_image_list, and you have to pass it a list (a list of one say). 2021 and earlier TV’s use v1, 2022 and later use v2.
Model: Samsung TU24F6005FKXSP (24" FHD, Tizen, entry-level TU series, 2024)
openHAB version: 5.2 (official stable binding)
Connection: WiFi, same VLAN as openHAB server, AP in Bridge mode (not Tunnel), IGMP snooping disabled
Symptom: Thing stays OFFLINE indefinitely, no pairing popup ever appears on the TV, despite the TV being fully reachable on the network.
What I’ve already ruled out:
1. Websocket connectivity works fine. Manual curl to the TV confirms the API is reachable and returns full device info:
curl -k https://192.168.0.50:8002/api/v2/
{"device":{"...","OS":"Tizen","PowerState":"on","TokenAuthSupport":"true",...
"modelName":"TU24F6005FKXSP","networkType":"wireless",...}}
2. Multicast SSDP traffic reaches the openHAB host fine. Captured with netcat -ukl 1900 while power-cycling the TV several times (same VLAN, AP Bridge mode, IGMP snooping off). Traffic arrives reliably, but the TV only ever advertises:
NT: upnp:rootdevice
NT: uuid:b052e9ac-bae1-4b13-8708-e138e729e0ce
NT: urn:dial-multiscreen-org:device:dialreceiver:1
NT: urn:dial-multiscreen-org:service:dial:1
urn:schemas-upnp-org:device:MediaRenderer:1 is never announced, across multiple power-on/off cycles.
3. DEBUG log for org.openhab.binding.samsungtv on Thing init:
09:54:34.591 [DEBUG] ... Create a Samsung TV Handler for thing 'samsungtv:tv:TVMatrimonio'
09:54:34.611 [DEBUG] ... Updated artModeSupported: false PowerState: true(on) artMode2022: false
09:54:34.611 [DEBUG] ... Configuration: SecureWebSocket, port: 8002, token: , MAC: 80:0d:3f:f9:66:d6, subscription: false
09:54:34.611 [DEBUG] ... Check and create missing services
09:54:34.612 [DEBUG] ... TV is OFFLINE
No connection attempt to the websocket remote is ever logged — the handler appears to stop before that point due to the missing UPnP MediaRenderer detection.
Question: Since this TV’s UPnP stack only exposes rootdevice/DIAL and not MediaRenderer, is there (or could there be) a fallback online-detection path — e.g. using the websocket API response (PowerState field, which correctly reports "on") instead of/alongside the UPnP MediaRenderer NOTIFY — for entry-level 2023+ Tizen models that don’t implement the classic AllShare/DMR stack?
Happy to provide a TRACE-level log capture (power on → 30s → power off) if useful.
The API https://192.168.0.50:8002/api/v2/ Is not the websocket, it’s just an http api endpoint.
The binding uses the UPNP multicast MediaRenderer to detect when the TV is on or off - this triggers everything else in the binding, and there is no easy way around this.
Having said that, every Samsung consumer TV that I have seen in the last 20 years advertises this service.
You should make sure your TV is configured correctly (remote via IP enabled, power on remotely, WOL etc).
What I have seen is Openhab, or the host not receiving multicasts.
This can be due to running OpenHab in a docker container (it is very complicated to configure docker to receive multicasts - it’s not just setting host mode) - or some other network configuration filtering the multicasts out.
I have also seen OpenHab ignoring UPNP due to configuration or build issues.
Can you give me your OpenHab configuration? OS, are you using docker, what network you are using etc. Also a full TRACE level log from the binding during a TV power cycle would be helpful.
You can also load a UPNP sniffer app on your phone or tablet - that will show you what UPNP services are being advertised on your network. This is what I use to show that my network is correctly passing UPNP and multicast data, and what services are being offered.