[ptr727]

Why

When a button press doesn't do what was expected, or a module drops off its bus, the place to find out why is InFusion Diagnostics: its History view shows which object started which task, and its Log view shows the controller's warnings and module offline/online messages. Neither is reachable from aiovantage today.

This adds the read-only side of the IDiagnostic ACI interface that those views use.

This is the first of three PRs split from #404, as asked. The live trigger log and the live system log follow as their own PRs, stacked on this one, since they reuse its log type enums.

How it is implemented

• DiagnosticInterface (config client) wraps four read-only IDiagnostic methods:

  • get_event_log returns the trigger history: which object (button, timer, sensor, module) started which task, and how.
  • get_event_log_next returns one history entry by position.
  • get_sys_log returns the system log.
  • get_modules returns the modules answering on an enclosure's bus, with their status bytes and error counts.

  Each takes master=, like the other interfaces.

• TriggerType and SysLogType enums name the trigger and log type codes. They live in their own module, so the live event types in the follow-up PRs don't depend on the config client. Both are exported from aiovantage.config_client.

• Example: examples/config_client/dump_diagnostics.py.

Protocol notes

Verified against an IC-II controller on 4.11 firmware:

• GetEventLog and GetSysLog answer only when an empty <call/> element is sent. A bare <GetEventLog/> gets no reply.
• An integer parameter has to be a <call>N</call> element.
• GetEventLogNext(n) returns entry n with Position set to the next position, or -1 on the last entry, and an empty <return/> past the end. How many entries the controller keeps, and what it drops once full, isn't known, so the docstring says to check timestamps rather than rely on positions alone.
• A module losing a line feed records trigger code 0xA004 from the module, with what looks like the feed number in param1. TriggerType.MODULE_ALERT is marked as observed rather than documented.
• History timestamps are the controller's local time with no offset, so EventLogEntry keeps them as text and its timestamp property returns a naive datetime. The registered converter would otherwise mark them UTC.

How it was tested

• New tests for each IDiagnostic call, including empty replies, addressing another master, and unreadable fields.
• pytest, ruff check, ruff format --check and pyright pass.
• Run against a live controller, reading the trigger history, the system log and the modules on its bus.

Home Assistant

A companion change to home-assistant-vantage uses these calls for trigger history, system log and module status actions, and per-module connectivity sensors. It will follow as focused PRs once an aiovantage release carrying these changes is available to pin.

🤖 Generated with Claude Code

[Copilot]

🔵 Needs a closer look

get_event_log must use the response Position field to distinguish a valid entry with a missing or unreadable timestamp from an empty response.

No open issues 🎉

What changed in this PR

Adds read-only IDiagnostic support to the config client for retrieving trigger history, system logs, and module status information.

Changes:

• Implements diagnostic RPC models and DiagnosticInterface methods.
• Adds public TriggerType and SysLogType enums.
• Adds parsing tests and a diagnostic-dumping example.

File	Description
tests/​config_client/​test_diagnostic.py	Tests diagnostic RPC requests, parsing, empty responses, master addressing, and unreadable fields.
src/​aiovantage/​config_client.py	Exports the diagnostic interface, result models, and log-type enums.
src/​aiovantage/​_log_types.py	Defines trigger and system-log type enums.
src/​aiovantage/​_config_client/​interfaces/​diagnostic.py	Implements diagnostic response models and read-only RPC methods.
examples/​config_client/​dump_diagnostics.py	Demonstrates reading and displaying diagnostic data.

_{Review effort: Lite}