# LocalThings: local Samsung appliance control for Home Assistant over CoAP-DTLS

> LocalThings is a Home Assistant custom integration that talks to newer Samsung appliances on your LAN instead of through Samsung's cloud. It installs through HACS, needs only an IP address for most devices, and depends on the smartthings-local library for the DTLS handshake.

**mbillow/localthings** — Local-control Home Assistant component that authenticates to newer-firmware Samsung devices and talks over CoAP-DTLS.

- Repository: https://github.com/mbillow/localthings
- Stars: 507 · Forks: 75
- Language: Python
- License: MIT
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/mbillow-localthings

## The cloud round-trip LocalThings removes

Samsung's own path for connected appliances runs through SmartThings, which means every state change and command leaves your network and comes back. LocalThings takes the other route. It is a custom component for Home Assistant that opens a CoAP-over-DTLS session directly to the appliance on your LAN, so the integration itself sends nothing to Samsung. The README is explicit that the appliance still keeps its own connection to Samsung, because that is firmware behaviour on the device side; what changes is that Home Assistant no longer depends on it.

The audience is narrow and specific. You need an appliance on Tizen RT 3.x or DAWIT 3.0+ firmware, roughly 2022 and later, which exposes a local DTLS-CoAP API. Appliances from roughly 2018 to 2022 speak token-based HTTPS to Samsung's cloud only, and the README states plainly that they are not supported. The config flow probes the appliance's local API port range during setup, so you do not have to determine the firmware generation yourself before starting; the integration tells you if it cannot find a local API.

## How the DTLS session and capability registries fit together

Two layers do the work. The low-level DTLS and CoAP handling is delegated to the smartthings-local library, which is a separate project. LocalThings itself is the Home Assistant side: a config flow, a coordinator, and a set of per-appliance-type registries.

The repository ships a by_type directory with one module per appliance family, including airconditioner.py, air_purifier.py, dehumidifier.py, dryer.py, oven.py, microwave.py, cooktop.py, range_hood.py, range.py, dishwasher.py, refrigerator.py, washer.py, water_purifier.py, vacuum_station.py, and air_dresser.py. Each of those composes shared and family-specific Capability objects from registry/capabilities/. That split matters for maintenance: a new appliance type means writing a new by_type file, not reverse-engineering the protocol again, because the auth path and CoAP primitives are shared across the fleet.

The README notes that the capability modules document individual resources and entities in more depth than the README table can stay current with. That is a fair warning about where to look, and also a hint that the README table is a summary rather than a specification. If you want to know exactly which entities a washer exposes before buying into the integration, the registry file is the source, not the table.

Device identity is keyed on the appliance's own OCF device ID rather than its name, so renaming entities in Home Assistant is safe. The README adds that some Samsung models ship the same serial number on every unit of a model, which is why the serial cannot be used to tell two identical units apart.

## Installing LocalThings through HACS and adding a first appliance

The README's Part 1 puts LocalThings in HACS's default repository list, so no custom repository entry is needed. Open HACS, go to Integrations, search for LocalThings, and download it.

After the download, restart Home Assistant. If you do not run HACS, the README gives the manual equivalent: copy the custom_components/localthings/ directory into your HA config's custom_components/ directory. The README does not print a shell command for this step, so the operation is a directory copy rather than a scripted install.

Then add the device. In Home Assistant go to Settings > Devices & Services > Add Integration > LocalThings, and paste the appliance's IP address. For most appliances that is the entire configuration. LocalThings finds the appliance, establishes the secure connection, and reads back the model and type before adding it.

A minority of newer models will not accept the automatic setup. In that case the setup screen asks for a CA Certificate (PEM) and a CA Private Key (PEM). These are the AC14K_M credentials, a pair the README describes as public for years and still shipping in current Samsung appliances. The repository does not include them; the README points to the smartthings-local project's setup_cert.py as an example of fetching the AC14K_M certificate and key and checking that they pair. You provide them once, and every appliance added afterward reuses them and asks only for an IP address.

For development, the repository includes a Dockerfile and docker-compose.yml. The compose file sets network_mode: host and explains why in a comment: DTLS runs over UDP and will not traverse Docker's bridge NAT to reach LAN appliances. The Dockerfile bakes smartthings-local into the image with the following line, because relying on Home Assistant's runtime manifest install depends on outbound network access at setup time and repeats on every container recreate.

```dockerfile
RUN pip3 install --no-cache-dir "smartthings-local>=0.1.12"
```

The compose file also mounts the component read-only into the container's config directory:

```yaml
    volumes:
      - ./ha_config:/config
      - ./custom_components/localthings:/config/custom_components/localthings:ro
```

## Where LocalThings stops being the right answer

The firmware cutoff is the hard boundary. If your appliance predates the Tizen RT 3.x / DAWIT 3.0+ generation, there is no local API to talk to and no amount of configuration will help. The config flow will fail to find a port, and that is the correct outcome, not a bug to work around.

Docker is the second constraint. The compose file requires host networking for DTLS over UDP. If your Home Assistant runs in a bridged container on a host where you cannot change that, the appliance will not be reachable, and the failure will look like a network problem rather than a configuration one.

The third limit is coverage. The README lists fifteen appliance types, and the gas cooktop entry is read-only burner status. Anything outside those types is unproven. The README argues that other Tizen RT and DAWIT-family appliances almost certainly speak the same protocol, but that is an inference from shared auth and CoAP primitives, not a tested claim. If your appliance is not on the list, you are signing up to write a by_type registry file.

Finally, the AC14K_M credentials come from outside this repository. The README directs you to another project's setup_cert.py for obtaining them. That is an external dependency in the setup path, and if that project's instructions change, this README's pointer does not update itself.

## LocalThings against the SmartThings integration

The obvious comparison is Home Assistant's built-in SmartThings integration. That one authenticates through Samsung's cloud with a personal access token and receives state over the internet. It works with a much wider range of devices, including older firmware and non-appliance Samsung products, and it exposes whatever Samsung's cloud API exposes.

The difference is where the control loop lives. SmartThings routes commands and state through Samsung's servers, so an internet outage or an API change affects your automations. LocalThings keeps the loop on the LAN and does not require Samsung's cloud to be reachable when you add a second appliance. The trade is coverage and setup friction: LocalThings supports a fixed list of appliance types and may ask for a credential pair that the cloud integration never needs.

If you have a mix of old and new appliances, running both is coherent. The cloud integration covers what the local protocol cannot, and LocalThings handles the newer units without a round trip. They are separate integrations and do not conflict at the Home Assistant level.

## Maintenance, licence, and upgrade cost

The repository is not archived, and the last push was on 2026-09-17. Recent releases include v0.26.1 on 2026-09-08, v0.26.0 on 2026-09-08, and v0.25.0 on 2026-08-31, so the version numbers are moving quickly. That pace cuts both ways: fixes and new appliance types arrive, and you should expect to update the component more often than a stable core integration.

The project is MIT licensed, which permits commercial and private use, modification, and redistribution provided the copyright notice and permission notice are retained. That is a general description of the licence text, not legal advice; if you plan to redistribute the component or bundle it into a product, read LICENSE and, where it matters, consult someone qualified.

Upgrading is the same operation as installing: pull the new version through HACS and restart Home Assistant. The README does not document a rollback procedure. If a release breaks an appliance, the practical fallback is to reinstall the previous version through HACS, which means you should keep track of which version worked before you update. Because the integration depends on smartthings-local at version >=0.1.12, a dependency bump can also change behaviour without a visible change in the LocalThings version number.

Development requirements are Python 3.13 or newer, per pyproject.toml, with ruff configured for py313 and a 100-character line length. Tests run under pytest with asyncio_mode set to auto.

## Conclusion

LocalThings suits Home Assistant users with 2022-or-newer Samsung appliances who want state to stay on the LAN and are willing to run a custom component. It is the wrong tool for older token-based HTTPS firmware, for anyone who wants Samsung's cloud features, and for Docker users who cannot switch to host networking. Before adopting, confirm your appliance's firmware generation, check whether the config flow asks for the AC14K_M credential pair, and read the by_type registry for your appliance to see which entities actually exist.

## FAQ

### Do I need SmartThings to use LocalThings?

No. LocalThings talks CoAP-over-DTLS directly to the appliance on your LAN, and Samsung's cloud sees nothing from the integration. The README notes the appliance still keeps its own connection to Samsung as a matter of firmware behaviour, which is outside the integration's control.

### Is there a monthly fee for LocalThings?

The README describes no subscription, account, or payment step. Setup is a HACS download, a Home Assistant restart, and adding the appliance by IP address, with the AC14K_M credential pair requested only for the minority of models that need it.

### Is SmartThings being discontinued?

The README does not discuss SmartThings service status. It only distinguishes the cloud path from the local one: appliances on roughly 2018-2022 firmware talk to Samsung's cloud over token-based HTTPS and are not supported by LocalThings, while 2022-and-later firmware exposes a local DTLS-CoAP API.

### Can I connect SmartThings appliances to Home Assistant locally?

Only for appliances on Tizen RT 3.x or DAWIT 3.0+ firmware, roughly 2022 and later. The config flow probes the appliance's local API port range during setup and reports plainly when it finds none, which is what happens with older token-based firmware.

## Sources

- [Issues](https://github.com/mbillow/localthings/issues)
- [License: MIT](https://github.com/mbillow/localthings/blob/main/LICENSE)
- [mbillow/localthings on GitHub](https://github.com/mbillow/localthings)
- [README](https://github.com/mbillow/localthings/blob/main/README.md)
- [Releases](https://github.com/mbillow/localthings/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mbillow-localthings