TL;DR — If you run your SolarFlow local-only and block its cloud at the firewall (for privacy), does your local status polling / control get unreliable? I found a reproducible firmware behaviour and filed it with evidence, and I'd like to see how many of us hit the same thing.

Setup: SolarFlow 2400 AC+, firmware 1.1.23, controlled locally via zenSDK (HTTP :80) + local MQTT in Home Assistant (Zendure-HA integration). The device's cloud endpoints (mqtteu.zen-iot.com:8883 and app.zendure.tech:443) are blocked at my firewall.

What happens: with the cloud blocked, the device's own LOCAL HTTP server on port 80 degrades — local status polls fail at _40–46 errors/hour and values like state-of-charge and solar input freeze. With the cloud reachable, the same device shows ₀ errors/hour. Control (setpoint writes) still succeeds ₉₈%, so it's the status side that suffers, not control.

Why (from a packet capture): the device's cloud-MQTT client retries the unreachable cloud about every 5 seconds with no backoff, and that constant reconnecting starves its own local HTTP server (same MCU). The device also strictly validates its cloud TLS certificate, so you can't quietly redirect it to a local broker to calm it down — only a firmware change (add exponential backoff / a circuit breaker to the reconnect loop) can fix it.

This looks mechanistically identical to two earlier reports (#1060 and #1184) that were closed as "not planned." I've written it up again with much stronger, confounder-controlled evidence (error-rate A/B + the packet capture) here:
https://github.com/Zendure/Zendure-HA/issues/1414

Ask: if you also run local-only / block the cloud and see the same flakiness, a quick thumbs-up or a short "me too" on #1414 — with your model and firmware version — would really help. The more of us who confirm it, the harder it is to dismiss as a one-off, and if a firmware backoff lands, everyone running local-by-design benefits.

Thanks!