Skip to content

Improve handling of redundant cloud commands and error 411 diagnostics - #1848

Open
aferende wants to merge 1 commit into
AlexxIT:masterfrom
aferende:agent/upstream-cloud-error-411
Open

Improve handling of redundant cloud commands and error 411 diagnostics#1848
aferende wants to merge 1 commit into
AlexxIT:masterfrom
aferende:agent/upstream-cloud-error-411

Conversation

@aferende

@aferende aferende commented Jul 29, 2026

Copy link
Copy Markdown

Hi AlexxIT,

First of all, thank you for your work on SonoffLAN. It is a very useful component, and this proposal is intended to improve its reliability and troubleshooting capabilities while preserving its existing design.

My name is Andrea. I investigated the intermittent eWeLink cloud error 411 reported in #1533 on my Home Assistant installation, with the assistance of Codex. I have been successfully testing this approach in my fork. During the observation period after removing redundant automatic commands in the installation and applying the cloud handling and diagnostics changes, the recurring 411 errors disappeared. This PR adds an integration-level guard so that the same prevention does not depend only on automation design.

Observed cause

In my installation, some Zigbee children are connected through a Sonoff ZBBridge-P and therefore use the eWeLink cloud path. I observed that a cloud command can be issued when the integration already knows that the target switch is in the requested state (for example, an off request for an already-off device). I also observed closely timed commands for the same device, for example from overlapping Home Assistant automations or a manual command near an automation action.

Those redundant or concurrent cloud requests were the plausible triggering condition for the sporadic 411 responses in this setup. This does not claim that every 411 has the same root cause or that it proves a LAN/Wi-Fi fault; it addresses the command pattern that was reproducibly correlated with the errors here.

What this PR changes

  • Serializes cloud commands per device.
  • Re-checks an explicit single switch: on/switch: off command while holding that lock and skips it if the known device state already matches. This prevents an unnecessary cloud request such as turning an already-off device off again.
  • Queues the non-actuating post-command state query before releasing the same device lock, reducing command overlap and improving the state available to the next command.
  • Treats an error: 0 response without params as a successful acknowledgement instead of an unknown-response warning.
  • Handles 411 and 504 responses with a delayed, non-actuating state reconciliation.
  • Adds an opt-in retry, disabled by default, only for an unconfirmed and idempotent single switch: on or switch: off command. It never retries toggles, scenes, multi-parameter commands, or other non-idempotent actuator commands.
  • Adds bounded command-error diagnostics with transport, parameter names, latency, parent model, bridge firmware and RSSI context.
  • Redacts exported diagnostics explicitly: app/cloud credentials, device and bridge identifiers, sequence values, device names, local IP/network addresses, and the same values embedded in diagnostic copies of system-log messages. Local logs remain useful, while downloadable diagnostics are safe to attach to a public issue.
  • Adds tests for safe retry eligibility, redundant-command detection, reconciliation, ZBBridge-P context, and diagnostics redaction.

Validation

  • python -m pytest -q --capture=no tests/test_cloud_errors.py tests/test_diagnostics_redaction.py
  • Result: 7 passed.

No personal Home Assistant configuration, credentials, devices, or automations are included in this PR.

Thanks again for maintaining SonoffLAN. I hope this can help improve the component's effectiveness for users who encounter ambiguous cloud command responses.

@aferende
aferende marked this pull request as ready for review July 29, 2026 08:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant