HA blocks "Delete device" (and the equivalent
config/device_registry/remove_config_entry WS call) unless an
integration implements async_remove_config_entry_device. Add the
hook returning True so users can prune devices that are gone from
their Samsung Find account without editing the registry by hand.
A returning device with the same dvceID will be recreated on the
next coordinator setup.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The reauth flow ran validate_jsessionid against HA's shared aiohttp
session, then update_cookies({"JSESSIONID": ...}) added the new value
with no domain. aiohttp's cookie jar still held the previous
JSESSIONID pinned to smartthingsfind.samsung.com (set via Set-Cookie
during the previous load), and aiohttp prefers the more-specific
domain match — so the *stale* cookie went out, Samsung returned no
_csrf header, and the user saw "Cookie was rejected by SmartThings
Find" even though their cookie was fine.
Two fixes:
* validate_jsessionid now runs in an isolated aiohttp.ClientSession
with its own jar, so the shared HA jar can't shadow the cookie
under test.
* async_setup_entry clear_domain()s the smartthingsfind.samsung.com
cookies before reseating JSESSIONID with response_url, otherwise
the same shadowing breaks the entry reload that follows a
successful UI reauth.
Also remove the QR-code login code (do_login_stage_one / _two,
gen_qr_code_base64, the legacy URL constants and qrcode/base64/
random/string/re/asyncio/io/timedelta imports) — Samsung migrated
account.samsung.com to a SPA-driven IAM/OAuth2 flow months ago, so
the QR scrape no longer works and nothing in the integration
references those helpers anymore. Drops the qrcode/pillow/requests
manifest requirements.
Tests: a minimal conftest stubs the homeassistant.* imports the
integration uses, and four async tests cover validate_jsessionid
including the regression case where a domain-bound stale cookie
sits in the shared jar.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two bugs left from the hass.data move that surfaced as soon as the
integration ran on the live HA:
* In async_setup_entry, devices were stored in hass.data AFTER
coordinator.async_config_entry_first_refresh(), but
_async_update_data reads them from hass.data — so the very first
refresh raised KeyError 'devices' and the entry stayed in
setup_retry. Move the hass.data update before first_refresh.
* SmartThingsDeviceTracker called self.async_on_update(...) which
isn't a method on TrackerEntity. Without a working listener
registration the tracker stayed restored=true / unavailable
forever. Subscribe in async_added_to_hass and use async_on_remove
for cleanup, which is the documented pattern.
Verified end-to-end on a live HA: phones/watch produce GPS, battery
sensors populate, and the Ring button triggers a SmartTag.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The local .env holds a long-lived HA token used for development;
keep it out of any push.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Samsung rebuilt account.samsung.com as a JS SPA backed by /iam/oauth2,
so the integration's HTML-scraping QR flow can no longer find the
signin URL and /accounts/v1/FMM2/signInWithQrCode now 404s. The STF
backend (chkLogin.do, getDeviceList.do, ...) is unchanged.
Replace the multi-step QR config flow with a single form that asks
the user to paste the JSESSIONID cookie copied from a logged-in
browser session at smartthingsfind.samsung.com. validate_jsessionid
hits chkLogin.do to verify the cookie before accepting it.
Also bundle in earlier compatibility fixes for newer HA: store
devices in hass.data so the coordinator can look them up by
entry_id, and use async_on_update on the device_tracker entity.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
