homebridge-samsung-tizen: putting a 2017-era Samsung TV in HomeKit

The plugin publishes a TV accessory, not a bridge

The scope of the plugin is stated in the first paragraph of the README: control Samsung TVs running Tizen OS, 2017 and later, from Apple Home through Homebridge, covering power, inputs and apps, volume, the remote in Control Center, custom switches for scenes and automations, and Art Mode on Frame TVs.

The accessory model matters for setup. Each TV is published as its own accessory, separate from the main Homebridge bridge. Adding the bridge to Home does not add the TVs, so the pairing step has to be repeated for every TV, and each one shows up in the Home app as a separate tile. That is more work than a plugin that folds everything into one bridge, and it is the right trade, because HomeKit treats a television as a distinct accessory type with its own service model, and because it means a TV can be shared with other household members independently of the rest of the bridge.

The remote in Control Center is worth calling out on its own. Exposing the physical remote inside the Home app is what people actually mean when they say they want their TV in HomeKit, and it is a different feature from having a power switch.

The custom switches are the other unusual piece. A switch is a synthetic accessory in HomeKit, so you can put a TV action, a scene or an automation trigger behind something that behaves like a switch, which is a workaround for the fact that HomeKit has no first-class concept of a custom command on a television.

Local control is the design constraint, not a feature

The README is explicit that basic functionality runs entirely on your local network and that no internet connection is required, and that this has been a core requirement of the plugin since the first release. Cloud services such as SmartThings are optional extras, not a dependency.

That requirement explains most of the plugin's technical shape. Live power state comes through SSDP, with a fallback when announcements are missing, which is a local discovery protocol rather than a polling API. Live volume and mute come through DMR, which is UPnP, including absolute volume without SmartThings. Both are protocols that work directly between devices on a network, and both are the reason the plugin can report a TV's real state instead of a guess based on the last command it sent.

The requirements list carries the network consequences. A Samsung TV with Tizen OS, 2017 or newer, must be on the same subnet as Homebridge, because Samsung blocks WebSocket access across VLANs. Each TV needs a static IP on your router. And for live volume and mute the TV must be able to reach Homebridge, which means that if Homebridge runs in Docker you need host networking.

That last point is the kind of detail that costs an evening. A Dockerised Homebridge on a bridge network cannot be reached by the TV, and the symptom appears as volume working in one direction and not the other. Host networking resolves it, at the cost of giving the container direct access to the host network stack.

The other hard limit is hardware. TVs from 2016 and earlier, which pair with a PIN, are not supported at all. The plugin targets the WebSocket pairing model that the 2017 generation introduced.

Version 6 is a rewrite that tries not to break your house

Version 6 is a full rewrite in TypeScript, and the migration story is the most interesting part of the release notes.

The claim is backwards compatibility: existing TVs stay in Home, so you do not have to add them again, and your current config keeps working. That is a stronger promise than most rewrites make, and it is specific enough to be checkable. What does change is that SmartThings has to be authorised again, and inputs or custom switches may need their Home names and scenes set up once more. A few settings were renamed or removed, with the old names still working for now and the log telling you what to change.

The deprecation handling is the sensible part. Rather than breaking configuration outright, the plugin accepts the old keys, logs what to change, and keeps working. For a plugin that runs inside someone's home on a Raspberry Pi, where the person who set it up may not be the person who maintains it, that is the difference between a smooth upgrade and a support thread.

The new features list shows where the effort went. Configuration moved into Homebridge Config UI X, version 5.27.0 or newer, so devices, inputs and switches can be added, edited and deleted without editing JSON. Keys, inputs and switches are set once at plugin level and shared by every TV, which removes a lot of repetition for a house with several televisions. An optional volume slider lets scenes and automations set the TV volume. SmartThings moved to OAuth with automatic token refresh, replacing the old personal access tokens.

The Frame TV handling is the most specific change. Art Mode is controlled on the local network, the TV tile is ON while you watch TV and OFF while Art Mode is on, and the TV also gets Art Mode and Power switches. Mapping the tile state to the actual mode is a small detail that makes the accessory behave the way a Home user expects.

Setup is a three-step ritual, and the pairing prompt has a trap

The setup sequence in the README is short, and each step has a failure mode worth knowing before you start.

First, open the plugin settings in Homebridge UI and add a TV with its name, IP and MAC address. The Test button next to the IP address checks that the TV can be reached and is supported, and it also fills in the MAC address if the field is empty. That button does two useful things at once, and using it before filling anything else shortens the diagnosis of most problems.

Second, restart Homebridge and turn the TV on, then allow the pairing prompt that appears on the TV. There is a detail here that catches people out: if the TV was off when Homebridge started, the prompt appears as soon as you turn it on, without another restart.

Third, in the Home app tap Add Accessory, then More options..., choose the TV and enter the setup code that Homebridge prints in the log for it. As noted earlier, this is repeated for every TV, because each one is a separate accessory.

The trap is what happens if you tap Deny on the TV's prompt. The fix is on the TV itself, in Settings, General, External Device Manager, Device Connection Manager, Device List, where you allow Homebridge. On newer TVs the menu is General & Privacy instead. You can also remove the entry, and the prompt appears again the next time the TV turns on.

The install itself is a one-liner from the command line, using the Homebridge service manager:

hb-service add homebridge-samsung-tizen

or you search for homebridge-samsung-tizen in the Plugins tab of Homebridge UI and install it there.

SmartThings covers the three things the local path cannot

SmartThings is optional, and the README is precise about what it adds: it adds what Samsung only offers through its cloud. The three items are selecting a source such as HDMI, picture and sound modes, and a full power off on Frame TVs.

That list explains the whole architecture. On the local network the plugin can do what the WebSocket and UPnP protocols expose, which is power, volume, mute, inputs, apps and Art Mode. Changing the picture mode or the sound mode or fully cutting power on a Frame is a cloud operation on Samsung's side, so the plugin has to go through the cloud for those three.

The setup is a wizard in the same settings screen. You create a SmartThings app once, paste the client ID and secret, and the plugin refreshes the access token on its own. The OAuth flow is the change from the previous version, which used personal access tokens. If the authorisation ever expires, the plugin writes it in the log and the settings screen shows it as expired, and you go through the wizard again and the plugin picks up the new authorisation.

The failure mode is therefore a cloud outage rather than a broken plugin. If Samsung's SmartThings service is down, or your authorisation lapses, three features stop working while everything else keeps running. That is a much better failure mode than the alternative, where the whole plugin depends on a remote service being reachable, and it is the reason the design puts the cloud behind an opt-in.

The build setup tells you how the project is maintained

The repository layout is that of a plugin with its own configuration UI. There is a src/ directory, a homebridge-ui/ directory with a public/ folder and a server.js, a config.schema.json at the root, an eslint.config.js, a .prettierrc and a .prettierignore, a nodemon.json and a tsconfig.json. The package is an ES module with main pointing at dist/index.js and types at dist/index.d.ts, and the published files list is dist, the homebridge-ui public folder, the UI server file, the config schema and the changelog.

The scripts in package.json describe the workflow. The build script clears the dist and homebridge-ui public directories, runs tsc, and then runs a Vite build against the UI's Vite config. The watch script builds, links the package with npm link and starts nodemon, and there is a separate watch:ui script that rebuilds only the UI in watch mode. Linting runs eslint with --max-warnings=0, which means a warning fails the lint, and prettier has both a check and a write script. The prepublishOnly hook runs lint and then build, so a published package has been linted and built.

The engine constraints are declared in the package as Node.js ^22.10.0, ^24.0.0 or ^26.0.0, and Homebridge ^1.8.0 or ^2.0.0, which matches the README's requirements of Homebridge 1.8 or newer with 2.0 recommended, and Node.js 22.10+, 24 or 26. The dev dependencies show a Vue-based UI, with @vitejs/plugin-vue and eslint-plugin-vue alongside the Vue plugin, plus prettier with a sort-imports plugin, which suggests import order is enforced as well as formatting.

The release history is worth a note. The recent tags are v6.1.0 from 2026-10-16, and two debug prereleases, 6.0.1-debug.0 and 6.0.1-debug.1, from the same day, which is what a rewrite looks like in a tag history. The last push was on 2026-10-16 and the project is not archived. The licence is MIT.

Getting unstuck is a documentation problem, not an issue tracker problem

The help section reflects how the maintainer expects the plugin to be used. Most pairing, network and Home app questions are already answered on the common issues page in the documentation, and there is a how to open a new issue page with details.

The specific instruction for the remaining cases is that you should open an issue and include debug logs from Homebridge. That is the right ask, because a HomeKit pairing problem is almost always a question about what the TV did or did not say, and the log is where that is recorded.

The project also carries a verified by Homebridge badge, which links to the Homebridge wiki page listing verified plugins. The meaning of that list is a curation signal rather than a technical one, and it is a reasonable proxy for whether a plugin is maintained in a way that follows the platform's conventions, particularly around the configuration UI and the accessory lifecycle.

The funding arrangement is the usual one for a plugin like this: PayPal, Buy Me a Coffee and GitHub Sponsors, with a note that the money goes toward new features, maintenance and support, all of it in the maintainer's spare time. That is worth factoring into any assessment, because a plugin that depends on one person's evenings will slow down when that person is busy, and there is no company behind it to absorb that.

The homepage of the project is the documentation site, and the step-by-step guides with screenshots live there rather than in the README, which is a sensible split for a plugin with this many setup paths.

Editorial conclusion

Adopt homebridge-samsung-tizen if you have a 2017 or newer Samsung Tizen TV and want it in Apple Home with local control, especially if you would rather not route your TV through a vendor cloud. Do not adopt it for a 2016 or earlier TV, which pairs with a PIN and is not supported, and expect the local path to stop short of source selection, picture and sound modes and a full power off on Frame models, since those need SmartThings. Before you commit, give each TV a static IP on the same subnet as Homebridge, run the Test button in the plugin settings to confirm the TV is reachable, and check the version 6 upgrade guide, because SmartThings has to be authorised again and inputs and custom switches may need their names and scenes set up once more.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tavicu/homebridge-samsung-tizen on GitHub