I have a 2 yr old eufy smart lock S230 with finger print. It lost connection to wifi and even after resetting I can’t get it online. The support was useless and instead looking for resources they simply pointed me to my expired warranty and suggested buy a new one. What’s the point of adding waste, why can’t they have some troubleshooting done to fix things that maybe just a software bug. I would hate to throw away a working lock if the software can be fixed. What’s has other done in this situation. Whats would you suggest.
2 the battery won’t last more than a week now. My initial guess is it might due to the device trying to connect forever.

Any advice on this? Trying to decide between the e30 Solocam x4 or having c31 and c35 cameras for my house. Anybody have recommendations or have any feedback?

Hi all,

I'm hoping someone has seen this before.

I have a Eufy T8214 Doorbell connected to a HomeBase 2 (T8010) using the Eufy Security HACS integration v8.2.4.

Everything had been working perfectly with automations based on doorbell ringing and motion detection.

Now, both doorbell ring and motion events have completely stopped updating in Home Assistant.

What still works

• Doorbell functions normally in the Eufy app.
• I receive instant ring and motion notifications on my phone.
• Home Assistant can still communicate with the doorbell as i can switch the status led on and off via HA
• I can change settings such as the Status LED, speaker volume and other configuration options from Home Assistant.
• The WebSocket server connects successfully and both stations connect without issue.

What doesn't work

• Ringing entity never changes from Not running.
• Motion entities never update.
• No doorbell or motion automations trigger.
• The add-on log shows no ring or motion events when the doorbell is pressed.

What I've already tried

• Restarted Home Assistant.
• Restarted the Eufy Security WebSocket add-on.
• Reloaded the Eufy integration.
• Verified the Eufy app notification settings (Doorbell Ring and Motion are enabled).
• Confirmed the doorbell is working correctly in the Eufy app.

About 9 months ago I had a very similar issue and simply restarting the Eufy WebSocket add-on fixed it, but this time it hasn't made any difference.

Has anyone seen a situation where Home Assistant can still control the device but no longer receives motion or doorbell events?

Any ideas would be greatly appreciated.

Thanks in advance

I own an Eufy NVR S4 (T8N00) with 8 PoE cameras, and the fact that I can't pull live streams locally into Home Assistant is baffling. Everything goes through Eufy's cloud, and the P2P protocol they use (NDT, not PPCS) isn't supported by any existing integration.

So I started reverse-engineering the device.

What I've done so far:

Found the UART console on the mainboard, three solder pads on the bottom edge of the PCB (RX, TX, GND in a neat little test-point header). Soldered in an FTDI adapter, fired it up at 1.5Mbaud, and got a full boot log. Turns out the SoC is a Rockchip with verified-boot enabled .

The blocker:

The device has hotkeys for CTRL+C at the SPL and U-Boot level, which on Rockchip usually triggers download mode (rockusb) a path to dump the firmware and potentially access the internals without breaking security. But here's the catch: Eufy compiled U-Boot with Cmd interface: disabled. There's a hotkey listener, but no shell prompt. And when I try to send CTRL+C over the serial line to trigger download mode, nothing happens.

The read side works perfectly I'm getting full visibility into the boot process. The write side is what's failing. Whether it's:

• The actual CTRL+C isn't reaching the device (some kind of serial flow control issue)
• The hotkey is compiled out even though the string is there
• The USB-C port isn't the one connected to the SoC's OTG (most likely)

...I haven't pinned down yet.

Why this matters:

The camera feeds are sitting on an isolated PoE subnet behind the NVR. They're literally never leaving my network. I'd like to at least try to pull them into Home Assistant without routing everything through Eufy's servers. I'm not trying to hack anyone else's device, I'm not ignoring warranty (I made a full backup before touching anything), and I'm not selling this. I just want local streams.

The ask:

Has anyone else poked around Rockchip devices with disabled U-Boot shells? Or hit a wall with write-only serial interfaces? Curious if there's a path I'm missing whether it's a different trigger for download mode, or if the USB-C is a red herring and I need to look at the DP/DM test pads instead.

Also open to alternative approaches if anyone's got them.

----

06/26 EDIT / UPDATE — progress + a correction:

Spent a long session on this and learned a lot. TL;DR: a couple of my original assumptions were wrong.

1. The write side actually works fine. This was the big one. I confirmed the serial TX→device RX is solid: U-Boot prints a Hotkey: <key> line during boot, and it reflects whatever control char I'm spamming — send CTRL+C and it prints Hotkey: ctrl+c, send CTRL+U and it prints Hotkey: ctrl+u. If my input weren't reaching the SoC, that line couldn't change. So it was never a flow-control or contact problem. Lesson: don't assume the write path is broken just because nothing "happens."

2. Correction on the hotkeys. It's not CTRL+C at both stages. The SPL stage uses CTRL+U (SPL Hotkey: ctrl+u), and U-Boot proper uses CTRL+C. On Rockchip the SPL ctrl+u is normally the rockusb/download trigger — so that should be the way in.

3. ...except it isn't, on this build. I spammed CTRL+U continuously (various timings, from 30ms gaps down to a full no-gap flood), captured both hotkey banners cleanly each time, and the box always boots straight through to Starting kernel. No rockusb device ever enumerates. Combined with Cmd interface: disabled on U-Boot, it really looks like Eufy neutered both the U-Boot shell and the SPL download action — the banner prints but the action is gone.

4. USB-C is a red herring (confirmed). It never enumerates anything on the host, in any boot state. So it's host-only, not wired to the SoC's USB OTG. The OTG is almost certainly broken out on the DP/DM/ID/VBUS test pads instead.

Net result: the UART→download path on this firmware is a dead end. UART is read-only in practice here. Not a wiring issue — it's locked down by design.

Next plan: go lower than U-Boot entirely and force maskrom (BootROM) mode — short the eMMC clock at power-on so the BootROM can't find the boot device and falls back to USB download. That can't be disabled in firmware. Then dump the eMMC over the SoC's real USB OTG (the DP/DM pads) with rkdeveloptool. If/when that works I'll post the dump.

Still very open to other ideas — especially from anyone who's pulled a maskrom dump off a locked-down Rockchip box, or knows whether the SPL download being dead means I'm wasting my time vs. just needing the right pins.

https://preview.redd.it/uj0m6u9qd19h1.jpg?width=2606&format=pjpg&auto=webp&s=f2b419de00dffe390d8d6b128a1816008f6f5a7a