Add typed device diagnostics

[PrzemyslawKlys]

Proposed change

Add get_device_diagnostics() and async_get_device_diagnostics() as a typed view of selected diagnostic values already available through SupportInfoDump.

The result includes CPU and memory usage, temperature, active PLC time slots, Ethernet port state, gateway connectivity, and lost MAPs. Parsing is limited to the configlayer item and a fixed allowlist of keys; missing or malformed firmware values remain optional instead of failing the complete result. No web UI scraping is involved.

The generated sync/async stubs and examples are updated, with tests covering complete, partial, malformed, and missing diagnostic data.

Checklist

• Changelog is updated.

[Shutgun]

Hi @PrzemyslawKlys , at first I found this idea genius and was mad at myself that I did not have the idea. But then I tested a bit around and now am very torn.

The call can only work for Magic devices, which is fine because it is guarded by the support feature flag.

But on Magic Wi-Fi devices, it will give you the PLC values only. So if you have e.g. a Magic WiFi 6 with nothing connected to it and ask for the Ethernet port state, you will get one port (the device has two) and a connection (although nothing is connected) because the PLC chip is connected to the host chip via Ethernet.

Other example: On a Magic WiFi6 device your call will report 8 MiB of RAM although the device shows 512 MiB on its website.

So while this information seems to be useful for PLC only devices, it is confusing for Wi-Fi devices and yet the library does not want to know to which device it is talking to as long as it using the device API.

Long story short: I'm not sure if we should offer this data in that way. I will continue to investigate, if maybe parts of it are generally useful for all devices.

[PrzemyslawKlys]

Thanks, that is a really useful catch. I agree that the current names overstate the semantics: the support dump appears to expose diagnostics for the PLC-side controller, not the complete product. On LAN-only devices that distinction is mostly invisible, but on Magic Wi-Fi devices it makes the host memory and internal PLC-to-host Ethernet link look like whole-device values.

One possible model-independent direction would be to:

• rename the API and result to get_plc_diagnostics() / PlcControllerDiagnostics;
• retain fields whose PLC meaning is stable, explicitly naming CPU, memory, and temperature as PLC-controller values alongside active time slots and lost MAPs;
• remove Ethernet-port and gateway reporting until their semantics can be established reliably.

That would describe the subsystem without requiring the library to identify the product model. Please continue your investigation first, though. If there is no stable and useful subset across Magic devices, I would rather close the typed convenience API than publish a misleading abstraction.