LAN control fixes (#57)
Two fixes from the latest issue #57 reports, both still present after v2026.6.22.
🛠️ LAN connectivity no longer flaps to Disconnected on power-on
The LAN connectivity sensor was flipping to Disconnected the instant a device was turned on (and routing writes back to the cloud), because a verify-by-read content mismatch was treated as a transport failure.
LAN transport health is now read-driven: any inbound devStatus (poll read, push, or even a value-mismatch confirm reply) keeps it alive. A run of unconfirmed writes no longer flips the sensor — it temporarily suppresses LAN write attempts (so writes go straight to MQTT/REST without waiting on the confirm timeout) while LAN reads keep working and the sensor stays Connected. A confirmed write or a short cooldown re-arms LAN writes automatically.
📡 Discovers newer devices that ignore multicast (e.g. H707B)
Some newer models answer a directed broadcast (x.x.x.255:4001) but ignore the multicast discovery scan, so they showed device_count: 0. The integration now derives each network adapter's subnet broadcast address automatically and scans it alongside the multicast — no configuration required. The periodic rescan re-emits the broadcast, which also re-primes devices whose firmware needs a recent scan before accepting local control.
Diagnostics
lan_discovery.broadcast_target_count— how many subnet broadcasts the scan hit- per-device
transport_health.lan.write_suppressed— distinguishes "LAN reads up, writes via cloud" from "LAN down"
Full Changelog: v2026.6.22...v2026.6.23