v2026.6.23

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