How I Moved My Samsung Washer from SmartThings to LocalThings in Home Assistant

My Samsung washer-dryer was already useful in Home Assistant. I had its current state and remaining time on my dashboards, a notification at the end of a cycle, and an Alexa announcement. I had been using the SmartThings integration for that since May 2026.

What changed my mind was the cost of keeping that path. SmartThings announced a planned $4.99-per-month API plan for individual developers, targeted for October 2026. The announcement says that the SmartThings app itself is unaffected, but my Home Assistant integration relied on the API. SmartThings’ announcement made the decision straightforward for me: I did not want to pay a monthly subscription just to keep reading my washer’s state in my smart home.

So I moved the monitoring side of my Samsung WD90DG6G94BBU2 washer-dryer from SmartThings to LocalThings. This is not a claim that the appliance is completely cloud-free. My goal was narrower: keep the information Home Assistant needs on a local path, while retaining the official app for the things it still does better for me.

What LocalThings changed—and what it did not

The cloud route had never been ideal for me. It worked, but I occasionally had to sign in again when data stopped arriving. LocalThings gave me another route for the Home Assistant part of the setup.

The LocalThings project describes itself as a Home Assistant custom integration that talks directly to supported newer Samsung appliances over DTLS and CoAP. Its documentation also makes an important distinction: the integration’s own traffic can remain local even though the appliance may still keep its Samsung cloud connection. LocalThings documentation

That distinction fit my goal. I wanted local monitoring for status, remaining time, and my completion automation. I was not trying to recreate every Samsung feature in a Home Assistant dashboard.

The part I underestimated: certificates

I expected a normal Home Assistant integration setup. For my washer-dryer, it was more involved: LocalThings asked for certificate material.

LocalThings currently says that most appliances only need an IP address, while a minority of newer models need additional credentials during setup. That is external project guidance; my own device was one of the models for which I had to do the extra certificate work. Read the current credential guidance

My first attempt to install OpenSSL did not work. This command returned an HTTP 404 for me:

winget install ShiningLight.OpenSSL.LTS.Light

I used the following package instead:

winget install FireDaemon.OpenSSL

In a new PowerShell session, I read the Samsung UUID from the certificate subject:

openssl s_client -connect connect-v2.samsungiotcloud.com:443 -servername connect-v2.samsungiotcloud.com -showcerts | openssl x509 -noout -subject

The relevant part of the output had this shape:

subject=C = KR, O = Samsung Electronics, OU = uuid:<UUID>, CN = *.samsungiotcloud.com

<UUID> is deliberately a placeholder here. It became the input for the next step, where I cloned SmartThings-Local and ran its setup script:

git clone https://github.com/QuiteYellow/SmartThings-Local.git
cd C:\Workspace\SmartThings-Local
$env:UUID="<UUID>"
python setup_cert.py

The session variable disappears when PowerShell closes. The script generated certificate material under certs\.bundle, which I then supplied to LocalThings. I am intentionally not showing the generated files: certificates and private keys do not belong in a public article.

That was the moment when this stopped being a quick integration swap. Still, the effort was worth it to me because it removed a recurring dependency from a workflow I already used.

Installing the integration was only half the migration

I kept SmartThings running while I brought LocalThings online. That gave me a fallback, but it also exposed the actual migration work: my dashboards and automation still referenced the old integration.

I used OpenCode with my Home Assistant MCP setup to find those references before I edited them. These are the entity and state changes from my setup. They are not universal LocalThings entity names; they are the mappings I had to make in my own configuration.

The data model for remaining time changed as well. SmartThings had supplied me with a date and time that I converted in my HA-Fusion dashboard. LocalThings supplied remaining minutes, so I no longer needed that old conversion.

Here is the template I now use. This is adapted only for an English-language article: the reader-facing output labels are translated, while the entity IDs, state values, Jinja flow, and calculation logic are unchanged from my original configuration.

{% set state = states('sensor.samsung_washer_da_wm_tp1_21_common_progress') %}

{% set translations = {
  'idle': 'Idle',
  'air_wash': 'Air wash',
  'ai_rinse': 'AI rinse',
  'ai_spin': 'AI spin',
  'ai_wash': 'AI wash',
  'cooling': 'Cooling',
  'delay_wash': 'Delayed wash start',
  'drying': 'Drying',
  'finish': 'Finished',
  'none': 'No cycle',
  'pre_wash': 'Pre-wash',
  'rinse': 'Rinsing',
  'spin': 'Spinning',
  'wash': 'Washing',
  'weight_sensing': 'Weight sensing',
  'wrinkle_prevent': 'Wrinkle prevention',
  'freeze_protection': 'Freeze protection'
} %}

{% set translated = translations.get(state, state) %}
{% set diff = states('sensor.samsung_washer_da_wm_tp1_21_common_completion_time') | int(0) %}

{% if state == 'finish' %}
  Finished
{% elif state == 'idle' %}
  Off
{% elif diff > 60 %}
  {{ translated }} · {{ (diff / 60) | int }} h {{ diff % 60 }} min
{% elif diff > 0 %}
  {{ translated }} · {{ diff }} minutes
{% else %}
  {{ translated }}
{% endif %}

The important point was not the template alone. I had to find every downstream reference before deleting the old integration. Installing LocalThings was only the beginning.

The automation I kept running

My completion automation still works after the migration. The important change was the trigger entity: it now listens to the LocalThings progress entity, while finish remains the target state.

This is my complete automation as it runs in my setup. I am preserving it because it is the clearest record of what I changed. It is not a drop-in automation for another Home Assistant installation: script.benachrichtigung is my own notification-distribution script, and its data fields are specific to my system.

alias: Waschmaschine fertig
description: >-
  Sendet eine Benachrichtigung, wenn die Waschmaschine nach einem plausiblen
  Waschgang beendet wurde.
triggers:
  - entity_id:
      - sensor.samsung_washer_da_wm_tp1_21_common_progress
    to:
      - finish
    trigger: state
conditions: []
actions:
  - action: ai_task.generate_data
    metadata: {}
    data:
      task_name: Waschmaschine fertig Meldung
      instructions: >-
        Liefere einen kurzen und lustigen Satz, der mich darüber informiert,
        dass die Waschmaschine fertig ist. Keine Emojis, möglichst kurz und als
        reinen Text.
    response_variable: content
  - data:
      benachrichtigungstext: '{{ content.data }}'
      an_sprachassistenten_senden: true
      immer_per_pushnachricht_senden: false
      an_lametric_senden: true
      prioritaet: normal
    action: script.benachrichtigung
mode: single

The notification script decides whether to send a voice announcement, a push notification, or a LaMetric message. The AI step only varies the wording so I do not learn to ignore the same message. Neither element is required for LocalThings; they are part of my existing smart-home setup around the washer.

Why I ran both integrations for four weeks

I ran SmartThings and LocalThings in parallel from August 9 to September 5, 2026. I wanted an easy way back if the local path turned out to be unsuitable, and I had already identified the configuration changes I would have to reverse.

During that period, I did not encounter functional problems with LocalThings. The washer continued to report status and remaining time, the completion automation continued to notify me, and I did not have to reauthenticate the local integration. By September 5, SmartThings had stopped delivering data for the previous week even though the washer-dryer had run in the meantime. I removed the old Home Assistant integration.

That is a positive observation from one appliance in my environment, not a general reliability result. It was enough for my decision because the fallback path existed and the local integration was doing the monitoring job I had moved it for.

Why I still use the SmartThings app

Local monitoring did not make me want to remove the SmartThings app. I still use it for choosing programmes and for phone notifications.

That is deliberate. In my view, programme selection is much more convenient in the official app than it would be in a Home Assistant dashboard. Rebuilding it would mainly move controls to a local path without giving me a benefit that justified the work.

So I ended up with two paths for two jobs: LocalThings for the appliance information I want in Home Assistant, and the SmartThings app for controls and notifications I prefer to keep there.

Would I make the move again?

Yes. The certificate work and migration were more involved than I expected, but they were worth it for my setup. I no longer depend on the SmartThings API route for the washer information used by my dashboards and automation, and I did not have to give up the parts of the official app that work better for me.

If you are considering this route, first check the current LocalThings documentation for your appliance, then map every dashboard and automation reference before removing SmartThings. The installation matters, but the entity and automation migration is where the change becomes real.