Samsung RAC local API (8888): unable to retrieve local token

layil · July 25, 2026, 7:05am

Hi Everyone,

I’m trying to integrate my Samsung Windfree AC units with Home Assistant locally, without relying on SmartThings.

My goal was to use the samsungrac integration, but I was unable to obtain the local authentication token.

I’ve been troubleshooting this together with @alerinaldi, also trying his integration, and after several tests we were trying to understand whether this is specific to my units or whether Samsung has changed something in recent firmware.

Here’s what we’ve already verified:

The AC connects correctly to my Wi-Fi.
It receives an IP address from my router.
A port scan shows that both 5050 and 8888 are open.
We captured the network traffic both from HA (tcpdump) and from a Mac during the pairing process, but couldn’t find any usable token.
We also started from scratch by removing the SmartThings integration and recreating everything.

The strange part is that the local service appears to be running (port 8888 is open), but we simply can’t retrieve the token required.

Also: when trying to reset the AC completely or just the WiFi settings, the standard button combinations doesn’t perform what requested.

Recently I read that Samsung plans to introduce paid access for third-party SmartThings APIs, so I’m wondering whether they may have already changed something regarding local authentication in newer firmware.

Has anyone successfully retrieved the local token recently (2026) on a current firmware?

If so:

Which AC model firmware version are you using?
Which method did you use to retrive the token?

At this point we’re mainly to determine whether this is an issue with my setup or whether Samsung has changed something in recent firmware.

Thank you so much!

GSzabados · July 28, 2026, 12:15pm

Try this: GitHub - ismaelrivas/samsungrac: Home Assistant Climate Device for controlling (not only) Samsung AC · GitHub

GSzabados · July 28, 2026, 12:15pm

If that doesn’t work, you can still give a try to this as well: GitHub - mbillow/localthings: Local-control Home Assistant component that authenticates to newer-firmware Samsung devices and talks over CoAP-DTLS. · GitHub

layil · July 29, 2026, 11:21am

Hi! Thanks a lot for your suggestions!

Try this: GitHub - ismaelrivas/samsungrac: Home Assistant Climate Device for controlling (not only) Samsung AC · GitHub

Alessandro’s integration was based on samsungrac: as far as I understand, failing in getting the token would affect the ability to use samsunrac as well.

If that doesn’t work, you can still give a try to this as well: GitHub - mbillow/localthings: Local-control Home Assistant component that authenticates to newer-firmware Samsung devices and talks over CoAP-DTLS. · GitHub

I tried to follow the steps here:

Installed the LocalThings integration from HACS.
Cloned the SmartThings-Local repository and ran setup_cert.py.
Successfully downloaded the AC14K_M CA bundle.
Successfully extracted the device UUID from Samsung Cloud.
Successfully generated the client certificate, private key and full certificate chain.
Tested the DTLS handshake against the appliance (including different UDP ports such as 49153, 49154 and 49155).
Also tried adding the appliance directly through the LocalThings integration using the generated AC14K_M CA certificate and private key.

Unfortunately every DTLS handshake either timed out or failed, and LocalThings ultimately reports:

“Cannot connect to the device. Verify the IP address is reachable and the CA credentials are correct.”

My AC is reachable on the network and the device is fully controllable from the SmartThings app. Really can’t figure out what’s wrong.

GSzabados · July 29, 2026, 2:21pm

I started from here: Bypass SmartThings Paywall: Local Fridge and Washer Control

Port 8888 suggests a different method, which is token based but quite similar to the CoAP one regarding structure.

@perseus177, started to work on solution for that for his washer with success. Repo here:

There are a set of tools to get the token in the repo. I am not sure, if there is a smart control button for your AC, or something similar, that should be turned on, and it should answer the token requests, if no button like that, then turn it off, and then turn it on, usually after turning on the device emits the token, at least that is how it works with the 2878 versions.

There is an issue on localthings to get the 8888 version implemented in the same integration due to the similarity.

GSzabados · July 29, 2026, 5:00pm

I am not sure, this seems to be working all local:

github.com/ismaelrivas/samsungrac

9.1.1/custom_components/climate_ip/protocol_8888.py

release

# climate_ip/protocol_8888.py
"""
Pure Python library for Samsung AC (Port 8888).
Supports Raw Sockets and SSL auto-negotiation (Legacy vs Modern).
"""
import asyncio
import json
import logging
import ssl
from functools import partial
from typing import Optional, Tuple, Dict

from .exceptions import AuthError
from .helpers import mask_sensitive_data

_LOGGER = logging.getLogger(__name__)

class ProtocolError(Exception):
    pass

This file has been truncated. show original

layil · August 13, 2026, 10:16am

@GSzabados thanks again for the suggestions.

I had a closer look at the ismaelrivas/samsungrac implementation you linked. The 8888 token acquirer uses the same mechanism we had already been troubleshooting: it sends a request to https://<AC_IP>:8888/devicetoken/request, starts a local HTTPS listener on port 8889 and waits for the AC to send the DeviceToken back.

Unfortunately, this is essentially the same 8888 pairing/token retrieval process that Alessandro and I had already tried in several ways, including packet captures during the pairing process, without ever receiving a usable token.

We also investigated whether the unit might actually be using Samsung’s newer local protocol instead. I tested LocalThings, generated and verified the AC14K_M certificates successfully using setup_cert.py, and tried the DTLS handshake on the relevant UDP ports. The AC never completed the handshake, and LocalThings itself was unable to connect. Alessandro also confirmed that the UDP port we were seeing was only being used for discovery, so this unit doesn’t appear to support the newer DTLS/CoAP protocol either.

So at this point it seems we’ve covered both possibilities:

the legacy HTTPS API on port 8888 is there, but we can’t get the token;
the newer DTLS/CoAP local API doesn’t appear to be supported by this unit.

What I’m still curious about is whether anyone has personally managed to retrieve a token from an 8888-based Samsung AC recently, particularly with current firmware. That would help establish whether something has actually changed on Samsung’s side.

For now I’ve gone back to using the official SmartThings integration to expose the AC units in Home Assistant. It’s cloud-based and not what I was hoping for, but it works reliably, so I’ll make do with it for the time being.

Thanks everyone for all the help!

GSzabados · August 13, 2026, 10:59am

There is a lot of work being done around LocalThings and SmartThings-Local for different authentication methods and protocols.

I would open an issue and provide all the details which possible, or look for similar issues, and join to that one. You have not stated here neither an exact model, firmware version, nothing, which are all usually listed in the SmartThings side of the things. You initial description of Samsung Windfree AC covers years of hardware and firmware, from spilt to multi-room and ceiling mounted 1-phase to 3-phase systems.

layil · August 13, 2026, 1:05pm

You’re right, I should have included the exact model in my original post — sorry about that. I tested both my ACs, and both are AR09KSPDBWKN.

The firmware version reported by SmartThings is 01766A200404 06010500,FFFFFFFF, with controller version AR.SC.0.123/IOS.AR.0010.106 on both units.

I’ll definitely consider opening an issue with LocalThings/SmartThings-Local including the full test results as soon as I have some more time to dig further.

Thanks for pointing out that the model/firmware information was missing — I’m adding both so the case is properly documented.