enableDevice for outdoor PT cameras (type 48) does not sync state to Eufy cloud — Eufy app shows no change

[stephanevalk]

Device info

• Camera: T8170 (SoloCam S340), device_type: 48 (OUTDOOR_PT_CAMERA)
• Station: T8030 (HomeBase 3), firmware 3.8.2.8
• eufy-security-client: v4.0.0

Description

When calling Station.enableDevice() for an outdoor PT camera (type 48), the P2P command is sent correctly via CMD_SET_PAYLOAD (1350) wrapping CMD_INDOOR_ENABLE_PRIVACY_MODE_S350 (cmd 6250) — this was fixed in v4.0.0. The HB3 acknowledges with ERROR_PPCS_SUCCESSFUL and the camera is physically disabled.

However, the Eufy cloud param param_type 6254 (the cloud-side enabled/privacy state) is never updated via the HTTP API. As a result:

• HA (and eufy-security-ws) correctly reflects enabled: false from the P2P command response
• The Eufy mobile app shows the camera as fully operational — no visual indication it was disabled
• If a family member opens the Eufy app, they see no change and cannot tell the camera was disabled from HA

Evidence from debug logs

At startup, param_type 6254 for T8170T10242521C2 reads:

{ "param_type": 6254, "param_value": "0", "update_time": 1743827584 }

After enableDevice(..., false) succeeds (P2P ACK received), the next cloud poll still shows the same update_time: 1743827584 — param_type 6254 was never written.

Relevant P2P command that IS sent correctly:

CMD_SET_PAYLOAD (1350) → { cmd: 6250, mChannel: 0, payload: { switch: 1 } }
→ returnCode: 0 (ERROR_PPCS_SUCCESSFUL)

Expected behavior

After disabling the camera via P2P, the HTTP API should also be called to update param_type 6254 in the cloud, matching what the Eufy iOS app does (it writes both the cloud param and sends the P2P command).

Suggested fix

After the P2P command for enableDevice succeeds on outdoor PT cameras, call the HTTP API to update param_type 6254 (0 = enabled, 1 = disabled / privacy on), similar to how other property writes update both transports.

[stephanevalk]

Root cause clarification

After further analysis, I can clarify why this regressed with v4.0.0.

Before v4.0.0 (e.g. v3.8.0):

DeviceEnabled was not registered in DeviceProperties for CAMERA_S4 (device type 48 / T8170). So when Station.enableDevice() was called, the !device.hasProperty(propertyData.name) guard threw a NotSupportedError. The HACS integration (fuatakgun/eufy_security) caught that error and fell back to a direct HTTP API call to set param_type 6254 in the cloud. This updated the Eufy mobile app correctly. The camera was not physically disabled (HB3 silently dropped the raw CMD_DEVS_SWITCH P2P command), but both HA and the Eufy app agreed on the state.

After v4.0.0:

• PR fix: read enabled state for outdoor PT cams from the wrapped privacy-mode key #874 registered DeviceEnabled for CAMERA_S4 → hasProperty() now returns true → no NotSupportedError is thrown → the old HTTP fallback in HACS is never reached
• PR fix: route enableDevice for outdoor PT cams through CMD_SET_PAYLOAD #873 fixed the P2P command → the camera is now physically disabled correctly
• But the cloud write (param_type 6254) that was previously done via the HTTP fallback no longer happens

So v4.0.0 inadvertently replaced a working (if indirect) cloud-sync path with a correct P2P path that is missing the cloud write side. The result: HA reflects enabled: false correctly, but the Eufy mobile app sees no change.

The fix should add the HTTP API call to update param_type 6254 within enableDevice for outdoor PT cameras, alongside the P2P command.