Sign in Subscribe
2fa Featured

Migrating Eufy Security in Homeassistant to the new eufy-sdk Stack

One evening all my Eufy cameras in Home Assistant went blank - no battery levels, no motion, no doorbell. The old eufy-security-ws stack can't talk to Eufy's new Mega cloud anymore. Here's how I cleaned it out and moved my HomeBase, cameras and doorbell to the new eufy-sdk bridge and integration.

Martin Seener

• 9 min read
Share
Migrating Eufy Security in Homeassistant to the new eufy-sdk Stack
Photo by Jakub Żerdzicki / Unsplash

Excerpt: One evening all my Eufy cameras in Home Assistant went blank - no battery levels, no motion, no doorbell. The old eufy-security-ws stack can't talk to Eufy's new Mega cloud anymore. Here's how I cleaned it out and moved my HomeBase, cameras and doorbell to the new eufy-sdk bridge and integration.

In my last post I made my Marstek Venus D ignore the wallbox with Homeassistant, and before that I got it into the Energy Dashboard. This time it's not about energy but about security - because one evening every single Eufy entity in my Home Assistant just stopped showing values, and it turned out this wasn't something a restart would fix.

The Challenge

For years the standard way to get Eufy devices into Home Assistant was a two-part stack:

  • eufy-security-ws by bropat - an App (formerly "add-on") that logs into the Eufy cloud and exposes a WebSocket API
  • Eufy Security by fuatakgun - a HACS integration that talks to that WebSocket and creates the entities

My setup is a HomeBase 3 (T8030), three eufyCam 2C Pro (T8142), an indoor camera (T8417), a video doorbell (T8214) and an water/ice sensor (T8920). Everything was loaded, the App was running - but all entities were empty.

My first suspect was myself. I had just enabled the new advanced end-to-end encryption in the Eufy app. So I disabled it again and restarted the App. Nothing changed. The App log showed the same thing on every sync:

[http] [HTTPApi.getPassportProfile] Get passport profile - Response code not ok
  code: 200, data: 'Xxx3Fd50gCLnaDeuVd...'
[http] [HTTPApi.refreshHouseData] No houses found.
[http] [HTTPApi.refreshStationData] No stations found.
[http] [HTTPApi.refreshDeviceData] No devices found.
[main] [MegaTransition.registerMegaPushToken] v6 push: register_push_token returned a non-zero code
  code: 4404, msg: 'get identity error'

The login itself worked, but the passport profile came back as an undecodable blob, and the device inventory was empty. No devices - no entities with values.

The real cause: Eufy is moving its app and cloud to a new platform called Eufy Mega, and the old client library simply doesn't speak it anymore. The open issues (eufy-security-ws #595, eufy-security-client #956) describe exactly this, and neither restarting nor recreating the container helps. My encryption toggle was just bad timing.

The good news: the old repository now points to its successor. Development moved to eufy-sdk, and there's already a matching Home Assistant stack built on top of it:

  • eufy-sdk bridge - an App that logs into Eufy once, exposes the SDK via WebSocket on port 3000 and ships with go2rtc bundled, so live video works as RTSP / WebRTC / HLS without extra software
  • eufy-sdk integration - a HACS integration that connects to the bridge and creates entities based on what each device actually reports

So the plan was: get rid of the old stack cleanly, then set up the new one.

A fair warning: this is a young project. I installed bridge 0.2.1 and integration 0.2.1, and while it works well for me, there are open issues - for example state not always staying in sync and streaming timeouts behind a HomeBase S1. If your old stack still works, there's no reason to hurry.

Prerequisites

You should already have:

  • Home Assistant OS or Supervised (you need Apps) on 2026.6.4 or newer - I'm on 2026.9.2
  • HACS installed
  • Your Eufy account credentials and access to the mailbox for the 2FA code
  • The old eufy-security-ws + Eufy Security stack installed (otherwise just skip Part 1 and 2 for a fresh installation of the new stack)

What You'll Need

Part 1: Inventory and Backup

Before deleting anything I wanted to know exactly what depended on the old integration. In my case:

What Details
Integration eufy_security with 8 devices and roughly 290 entities
Automations 2 - starting and stopping a P2P livestream on the doorbell on motion
Dashboard cards 2 custom:webrtc-camera cards showing camera.tur
HACS fuatakgun/eufy_security
App eufy-security-ws plus its App repository

To find references, search your automations for eufy_security and your dashboards for the camera entity IDs. Scripts, scenes and helpers are worth a quick look, too.

Then take a full backup under Settings → System → Backups and wait until it's finished. Deleting an integration removes its devices and entities for good - the backup is your only way back.

Part 2: Removing the Old Stack

The order matters here, so nothing is left pointing at something that doesn't exist anymore:

  1. Delete the automations using the old entities or eufy_security.* actions
  2. Remove (or change) the dashboard cards showing the old cameras
  3. Delete the Eufy Security integration under Settings → Devices & Services - this takes all devices and entities with it
  4. Remove fuatakgun/eufy_security in HACS
  5. Stop and uninstall the eufy-security-ws App, then remove its repository under Settings → Apps → App Store → ⋮ → Repositories
  6. Restart Home Assistant

Removing the old App isn't just cosmetic - the old and the new bridge both want port 3000.

Part 3: Installing the Bridge App

  1. Add the repository: Settings → Apps → App Store → ⋮ → Repositories → https://github.com/mega-yfue/ha-eufy-sdk-addon
  2. Install eufy-sdk bridge - but don't start it yet
  3. Open the Configuration tab and fill in your Eufy email and password
  4. Set the country code - it defaults to GB, mine is DE
  5. On the Info tab, enable the Watchdog, so the Supervisor restarts the bridge if it crashes

Everything else I left at the defaults:

poll_ms: 600000
stream_idle_ms: 300000
rtsp_idle_off_ms: 300000
prewarm: false
event_log: true

And here the challenges started:

Challenge 1: The country code matters. The default is GB. If your Eufy account lives in another region, you'll end up with exactly the "no devices found" situation you just escaped from. Set it to your account's country before the first start.

Challenge 2: Don't brute-force the login. Enter your password carefully and only once. Repeated failed logins can trigger a captcha or a temporary cooldown on Eufy's side, and then you're waiting instead of migrating.

Challenge 3: Port 1984 is already in use. My first start attempt failed with:

Cannot start app x9x8x4xx_eufy_sdk_bridge because port 1984 is already in use

Port 1984 is go2rtc's default API port. The culprit was the WebRTC Camera integration by AlexxIT, which runs its own go2rtc there. I only used it for the two old doorbell cards, which were already gone - so I removed it (integration entry first, then the HACS files). The new stack streams through the bridge's own go2rtc and Home Assistant's native WebRTC, so I don't need it anymore.

If you still need WebRTC Camera for other cameras, you can instead remap the bridge's host port 1984 in the App's Network section. Just be aware that this isn't the documented default.

After that the bridge started and told me right away what it wanted next:

[bridge] listening on 0.0.0.0:3000
[bridge] auth required: require_2fa — drive it over WS /ws (auth.status / auth.submit)

Part 4: Installing the Integration and Finishing the Login

  1. Add the repository to HACS: Integrations → Custom repositories → mega-yfue/ha-eufy-sdk, category Integration
  2. Install "eufy-sdk"
  3. Restart Home Assistant
  4. Add via Settings → Devices & Services → Add Integration → eufy-sdk

The config flow found the bridge App on its own. If it doesn't for you, use the App's hostname and port 3000.

Challenge 4: The 2FA happens in the integration, not in the App. The bridge doesn't have its own UI for the verification code. Since it was waiting for 2FA, the config flow asked for the code Eufy had just mailed me. Enter it promptly - these codes don't live long. If it fails, request a new one instead of retrying the old one. A captcha, if Eufy wants one, is solved in the same dialog.

A few seconds later the bridge log looked a lot happier:

[bridge] ready — 7 devices, 5 camera stream(s)
go2rtc platform=linux/amd64 version=1.9.9
[api] listen addr=:1984
[rtsp] listen addr=:8554

Part 5: Does It Work?

Yes. All devices are back - 7 devices with 311 entities, none of them unavailable. Battery levels, temperatures, detection toggles, night vision, power source and the HomeBase guard mode all show real values again.

If you counted along: 8 devices before, 7 now. The old integration showed my inhouse camera twice because I had renamed it once. So this was not an error.

Why are so many entities "unknown"?

About a third of the entities showed unknown for me, and that's expected. Event entities, buttons and the "Last event" images stay unknown until something happens. A few more are features the hardware simply doesn't report - my entry sensor, for example, currently only exposes its battery.

Entity names changed

It's a different integration, so names and IDs are different, too. The ones I use:

What Old entity New entity
Doorbell camera camera.tur camera.tur
Indoor mechanical chime switch.tur_indoor_chime_enabled switch.tur_mechanical_chime_switch
Person detected binary_sensor.tur_person_detected binary_sensor.tur_person
Doorbell ring binary_sensor.tur_ringing event.tur_doorbell
Battery sensor.tur_battery_percentage sensor.tur_battery

The chime one tripped me up. The switch to silence the indoor chime is now called Mechanical Chime Switch. There's also a binary_sensor.tur_chime_switch, but that one is read-only. Test it once: switch off, ring the doorbell, listen.

You can use this switch if you want to "disable" the inhouse chime during the night for example.

Part 6: Dashboard Cards and Automations

Without WebRTC Camera, the doorbell card is now Home Assistant's built-in picture-entity card:

type: picture-entity
entity: camera.tur
name: Tür
camera_view: auto
show_state: false

Why camera_view: auto and not live?

Because the doorbell runs on battery. With auto the card shows a still image and opens the live stream when you tap it. With live, a dashboard left open on a wall tablet would keep the doorbell streaming all day.

Why I didn't port my old automations

My old automations did one thing: start a P2P livestream on the doorbell when motion was detected and stop it when motion cleared, so the stream was already warm when I opened it.

The new integration has no start/stop stream actions, and the camera entity only supports streaming, not on/off. Instead, a stream starts when someone opens it and stops by itself after stream_idle_ms (5 minutes by default) without a viewer. The job of my old automations is now built in, so I deleted them for good.

What the new integration offers instead are proper event entities:

  • event.tur_doorbell fires with event type pressed when someone rings
  • event.tur_detection fires with types like person, motion, vehicle, stranger, package_delivered or package_taken

That makes a doorbell notification with a snapshot pretty straightforward:

alias: "Eufy: Doorbell notification"
description: >-
  Sends a push notification with a snapshot of the doorbell
  camera when someone rings.
triggers:
  - trigger: state
    entity_id: event.tur_doorbell
    not_from: unavailable
actions:
  - action: notify.mobile_app_your_phone
    data:
      title: "Doorbell"
      message: "Someone is at the door"
      data:
        image: /api/camera_proxy/camera.tur
mode: single

Replace notify.mobile_app_your_phone with your own notification target. For person detection, trigger on event.tur_detection and add a state condition on its event_type attribute being person.

Why not_from: unavailable?

Event entities change state whenever an event fires - but also when the integration reloads or Home Assistant restarts and the entity comes back from unavailable. Without not_from, every restart would send you a doorbell notification.

Troubleshooting

The bridge won't start: "port 1984 is already in use"

Another go2rtc is running - most likely WebRTC Camera, or a standalone go2rtc App. Remove it or remap the bridge's host port (see Part 3).

The bridge log says "auth required: require_2fa"

That's not an error. Add (or reconfigure) the eufy-sdk integration - it walks you through the verification code.

No devices found with the new stack

Check the country code in the App configuration first. Then make sure the account in the App actually owns the devices or has accepted the share invitation in the Eufy app.

Captcha or login cooldown

Too many login attempts. Stop the bridge, wait a while, double-check your credentials and try once more.

The live stream doesn't load

Battery cameras sometimes need a moment to wake up. If it keeps failing, look at the bridge log for stream timeouts - devices behind a HomeBase S1 have known issues right now.

Conclusion

The old Eufy stack won't come back for accounts that have been moved to Eufy Mega, and no amount of restarting fixes it. The move to eufy-sdk took me about an hour - most of it for inventory and cleanup, not for the new setup itself.

The key insights: take inventory and a backup before deleting anything, remove the old App so it doesn't block port 3000, watch out for a second go2rtc on port 1984, set the right country code, and do the 2FA in the integration's config flow. After that, the new stack feels cleaner than the old one - one App with go2rtc built in, entities based on what the hardware really supports, streaming that manages itself, and event entities that are much nicer to automate on.

Additional Resources