Entities

Smart feature entities

The optional Smart Energy & Comfort profile adds electrical and thermal energy totals for lifetime, day and month, COP for the same periods, estimated costs, CO₂ and optional PV use, plus compressor-cycle and operating analysis. These are derived values, not additional physical meters. The required power registers must be available.

Health Monitor adds eight problem checks and a report sensor. Heating-curve and weather advisers add read-only recommendations. The Predictive Advisor adds a strictly read-only recommendation framework (status, recommendations, data quality). The optional comfort schedule changes the existing circuit room target; it does not create a second climate controller entity. Automatic DHW charging uses the existing boost controls and state machine.

Every entity these packages can create is listed with its exact name under Optional feature entities, and the sub-device grouping is described under Device groups (device hierarchy).

With device hierarchy enabled, iDM Analytics, iDM Health Monitor, iDM Comfort and Diagnostics separate these features from controller entities. Disabling optional features removes their entity registrations; re-enabling them restores the same IDs. Existing controller IDs are retained.

The integration dynamically generates entities based on your heat pump configuration (heating circuits, zones, optional features).

Entity Platforms

Exact counts depend on the detected model, active heating circuits, zones, rooms and optional features. Adding circuits, zones, cascade or web supplement data can add entities.

Entities are grouped by function in Home Assistant where possible. Configuration entities come first, followed by switches, writable values, live measurements and diagnostics.

Entity names and languages

Entity names come from the integration's translation files and follow the language configured in Home Assistant: an English installation shows English names, a German one shows the German names the integration has always used. Heating circuits and zone rooms share one name per measurement and fill in their circuit letter or zone/room number, for example Heating circuit A flow temperature and Zone 1 room 2 temperature.

Changing the Home Assistant language changes the displayed names only. Entity IDs and unique IDs stay exactly as they are, so dashboards, automations and long-term statistics keep working. An entity created after a language change derives its entity ID from the name in that language, as with every Home Assistant integration.

Sensors

Runtime diagnostics

This sensor remains available even if heat-pump polling fails, making it useful when collecting information for a bug report. The direct socket runtime is identified by the modbus_connection_version and tmodbus_version attributes.

System Temperatures & Pressures

Navigator 10 — Heat Sink (Trennwärmetauscher)

Register 1072 is a word-swapped FLOAT32 — the official IDM doc lists UCHAR, but field readings proved the float (0.23.0-b8): a plant with a live flow signal shows real L/min values. Without a plate heat exchanger the whole block reports not-present (-1.0) and these entities stay unavailable; when the web supplement serves its own flowmeter row, that value fills the flow rate in automatically (see Known Limitations).

Compressors & Pumps

Energy & Power

PV / Energy Management

Battery SOC accepts 0–100; -1 means that no battery value is available. Treating address 86 like the surrounding two-register FLOAT values produces an implausible result. When a battery is used, IDM support also requires that register 84 (battery_discharge) is written; mapping SoC alone is not sufficient (#493).

PV surplus operation (derived diagnostic)

The Navigator controllers do not expose an internal "PV surplus charging active" state register — the whole PV block (74–88) consists of GLT measurement inputs written by an external energy manager. The integration therefore provides the derived diagnostic binary sensor PV-Überschussbetrieb (calculated_pv_surplus_operation, issue #353). It is on when both halves of the state are true:

1. Surplus is currently signalled to the controller: pv_surplus (register
   74. ≥ 0.05 kW or the SG-Ready signal smart_grid_status (register 90) reports Supergreen.
2. The heat pump is actually drawing electrical power: power_consumption_hp (register 4122) ≥ 0.05 kW, falling back to hp_operating_mode (register 1090) ≠ Off on installations without the Nav 10 power measurement.

The entity is only created when at least one source per half exists on the detected installation; thresholds and the currently active sources are exposed as attributes. Note for installations where the surplus is measured behind the heat pump feeder: pv_surplus collapses toward zero while the heat pump absorbs the surplus it is charged with — there the SG-Ready signal (or pv_production) remains the reliable indicator, and the SG-Ready source keeps the diagnostic meaningful.

Solar Thermal

These entities only exist while the solar thermal system option is enabled (default). Plants without collectors can switch the option off in the integration settings: the solar registers leave the poll and the empty Solaranlage device group disappears after a reload. Re-enabling it restores the entities with their previous IDs.

The integration also notices on its own: when every solar register reports "not configured" for a full day, a repair suggestion offers to switch the module off (or keep it, which dismisses that round of the suggestion).

ISC (Intelligent Surface Cooling)

Booster A/B (2nd heat generator)

Cascade (multi-heat pump)

Heating Circuit Sensors (per circuit A–G)

Calculated Sensors

These sensors are derived from register values of the same snapshot. Nothing is estimated: every operand is a decoded register value, and the sensor reports no value rather than a guess when its sources are not meaningful.

Flow deviation per heating circuit compares the measured flow temperature of a circuit (hc_{x}_flow_temp) with the flow setpoint the controller currently requests for that circuit (hc_{x}_setpoint_flow_temp):

• Positive — the circuit runs above the requested setpoint (overshoot, typically a heating curve set too high or a mixer that opens too far).
• Around zero — the circuit follows its heating curve.
• Negative — the circuit does not reach its setpoint (undersized heat source, high load, defrost, or a limiting setting).

The sensor becomes unavailable while the circuit is idle (the controller reports 0.0) and on circuits that are not configured (-1.0). That is intentional: a deviation calculated from a placeholder value would be meaningless. The entity itself is created as soon as both registers exist, so a Home Assistant restart during standby does not make it disappear.

Heat pump flow deviation (calculated_hp_flow_deviation) compares the heat pump's own flow temperature (hp_flow_temp, register 1050) with the highest circuit setpoint currently requesting flow. No register exists for a heat-pump-level flow setpoint (verified against the full Navigator 10 map), so the requested level is derived from the active circuit setpoints — idle circuits reporting 0.0 and unconfigured circuits reporting -1.0 are excluded. The sensor publishes only while the heat pump reports pure heating mode (register 1090): during a DHW charge the heat-pump flow rises to charging temperature while the circuit setpoints stay at their curve values, and reporting that difference as a "deviation" would be misleading — the same applies to cooling, defrost, standby and combined states, which report no value instead. Field evidence: 2026-10-20 probe on the reference plant, see docs/dev/open-work-audit.md.

Optional Web Supplement Sensors

When Web supplement data is enabled and a local Navigator web PIN is configured, the integration adds read-only diagnostic sensors from the local web API. These sensors are additive; Modbus entities remain the primary data source.

Typical web-only sensors include:

The heat pump model is deliberately no entity of its own: Navigator 10 firmware 20.24-1580 (installed from 2026-09-29) removed the model row from the sensor page, and no other accessible web frame reports it — live-verified against the controller, an entity would sit unavailable forever on current firmware. Where a firmware still delivers the row (Navigator 2.0 web, older Navigator 10 firmware) the value appears as the heatpump_model attribute of the Navigator version (Web) sensor.

Demand reason from the web interface (Navigator 10 only)

The Navigator controllers expose no internal PV-mode state register over Modbus, but the Navigator 10 web interface renders the display's "Anforderungsgrund" — including PV — from a bitmask in the WebSocket home/detail frame. With the web supplement active on a Navigator 10, the integration evaluates that frame every web poll and exposes:

• Anforderungsgrund (Web) (web_demand_reason): the human-readable demand reason, worded like the controller's own display — for example PV, Heizkreis A, Zeitprogramm, Mehrere Anforderungen, Keine Anforderung or Aus — with the raw operationMode/info values of every contributing widget as attributes.
• PV-Anforderungsgrund (Web) (web_demand_reason_pv): binary sensor that is on while the controller itself reports PV as its demand reason (bit 32), in the heating as well as the domestic-hot-water reason table.

This is the device-reported counterpart of the derived calculated_pv_surplus_operation diagnostic: the web entity reflects what the controller decided, the Modbus entity works without a web PIN. On Navigator 2.0 (different, PHP-based web interface) only the derived Modbus entity is available.

With the device hierarchy enabled, all PV entities — the PV registers (pv_surplus, pv_production, pv_target_value), smart_grid_status, the derived diagnostic and the two web entities — share the dedicated Photovoltaik subdevice instead of the main device. | Info system notifications (Web) | Summary of active Navigator 10 infosystem notifications | | Hot gas temperature (Web) | Web-only diagnostic temperature when available | | Evaporator pressure (Web) | Web-only refrigerant pressure when available | | Board temperature (Web) | Controller board temperature when available | | Current/projected heating / cooling / hot water power (Web) | The controller's current or projected thermal power for that mode |

"Momentane/prognostizierte Leistung" is not a live measurement

The Navigator labels these three values mom./prog. Leistung Heizen, mom./prog. Leistung Kühlen and mom./prog. Leistung Vorrang — momentane bzw. prognostizierte power. They report what the controller currently expects to deliver for that mode, so a non-zero value while heating or cooling is switched off is normal and not a fault. A value that changes while the compressor is idle is the controller re-planning, not the heat pump running.

For actual electrical draw, use Wärmepumpe Aufnahmeleistung / current_electrical_power instead.

Device-side heat quantities, DHW detail and controller clock (Navigator 10 only)

Three further read-only WebSocket controllers are evaluated on every web poll (live-verified on firmware jsonVersion 11, September 2026):

• Heat quantity heating/hot water, total and today (Web) (web_heat_quantity_heating_total, web_heat_quantity_hotwater_total, web_heat_quantity_heating_today, web_heat_quantity_hotwater_today): the controller's own statistic/detail heat-quantity block — the lifetime totals and today's values in kWh. They are an independent cross-check for the integration's own energy statistics and work without any Modbus access.
• Hot water circulation (Web) (web_dhw_circulation_active): binary sensor for the domestic-hot-water circulation pump from the system.freshwater/overview frame — a state the Modbus map does not expose.
• Hot water status info (Web) (web_dhw_status_info): the numeric status of the freshwater block, diagnostic category.
• Controller clock (Web) (web_controller_clock): the controller's own clock as a timestamp sensor, with jsonVersion, active user level, language, notification count, frost-protection flag and network flag as attributes. The controller clock can drift — this sensor makes the drift visible.

Connection state

Diagnostic entities make the effective connection visible on the dashboard — they exist in every connection mode, so a fallback is visible at a glance:

• Connection mode (connection_mode): which transports are actually live right now — Modbus + Web, Modbus only or Web only. The web half reflects the last web refresh (a supplement that stopped answering flips the state to Modbus only and back on recovery). The attributes carry the configured mode (the connection_mode option from Configure → Modbus section, default auto) and the detected web variant (nav10 or nav20). Every transport transition is written to the log at INFO level (IDM connection state changed: …), so support cases can answer "since when does the web path not answer" without log spam.
• Reload connection (connection_reload, diagnostic button): reloads this integration entry, restarting setup and connection validation without waiting for Home Assistant's setup-retry backoff. This does not reboot the heat pump. The connection must succeed before an outage is resolved.
• Last web update (Web) (web_last_success): when the local web interface last answered successfully — the web counterpart of the Modbus last success diagnostic, always available when a web PIN is configured.

System controllers (Navigator 10)

Four read-only WebSocket controllers that the shipped frontend uses for its performance page, weather tile, iON status and energy-flow widget are part of the web supplement (idm-heatpump-api 2.12.0 or newer). They are additive — the frames are read with the regular web poll, and every entity reports unavailable until its frame has landed:

• Heat pump power consumption (Web) (web_hp_power_consumption): the live electrical consumption power in kW, with the performance mode, the system mode, the measurement source, the battery flag and the production flow temperature as attributes.
• Heat pump environment power (Web) (web_hp_power_environment): the source-side power in kW, with the environment source and the source inlet temperature as attributes.
• Heating rod (Web) (web_hp_heating_rod): binary sensor for the heating-rod state of the performance page.
• Grid power (Web) (web_energyflow_grid) and PV power (Web) (web_energyflow_pv): the energy-flow widget's grid and PV power in kW — placed on the PV subdevice when the device hierarchy is enabled. Firmware T_NAV10_20.24-1580 removed the house channel from the frame; when an older firmware still delivers it, it is exposed as an attribute.
• Weather forecast (Web) (web_weather_forecast): the controller's own forecast, which it pulls through the myiDM service — today's temperature as the state, and today plus up to six forecast days (min/max/actual temperature, cloud cover, rain probability, sunshine seconds, weather symbol, wind speed) as attributes.
• iON optimization active (Web) (web_ion_active): diagnostic binary sensor for IDM's cloud energy optimization, with the enable setting and the subscription status as attributes.

Web-only controls (Navigator 10, Phase 4)

A web-only entry is no longer purely read-only: with the WebSocket variant connected it gains two controls that write through the local web interface — every other connection mode keeps writing through Modbus exactly as before:

• Betriebsart (Web) (web_system_mode): select for the operating mode. It reads the current mode and the controller's own selectable values from the home/overview tile and writes through home/save — the same numbering as the Modbus system_mode register, validated before sending. A rejected write raises instead of silently failing.
• Fehler quittieren (Web) (web_acknowledge_errors): the acknowledge button, writing notification/save.
• Warmwasser-Solltemperatur (Web) (web_dhw_setpoint): the hot-water setpoint as a number entity. Bounds, step and the current value come from the device's own declared parameter definition, and every write is validated against that range before sending — the same write safety as the register path.
• Heizkreis X (Web) climate card per circuit (room temperature, target temperature, mode; HVACAction from the pump state) and the Warmwasser (Web) water-heater card (tank top temperature + setpoint) — the same validated web writes, presented as the standard Home Assistant cards.
• Heizkreis X Raumsolltemperatur (Web) / Heizkreis X Betriebsart (Web) (per configured circuit): the normal room setpoint (parameter HK<x>04) as a number and the circuit mode (parameter HK<x>01) as a select, with the device's own declared bounds/options. One system.heatingcircuit/detail frame per circuit also carries the room temperature and pump state. The DHW one-shot boost deliberately stays off the web path: this firmware exposes it only as a weekly timetable, and writing whole timetable strings is out of scope.

The set_system_mode and acknowledge_errors services use the same web path automatically for web-only entries. Writes reuse the authorized web session of the poll loop and read the state back after every write, like the official web UI. KNX bus commands route through the same web writes for the everyday controls (system mode, hot-water setpoint, circuit mode/setpoint, acknowledge); other registers still require Modbus.

On Navigator 2.0, the statistics pages deliver the same shape from the older web interface: runtime / heat quantity / electrical energy, total per category (Web 2.0) sensors — hours for runtime, kWh for the energy types, normalized with the page's own unit scale.

If a firmware does not answer one of these controllers, the affected entities simply stay unavailable; the rest of the web snapshot is unaffected.

If a web value duplicates an existing Modbus entity, the web entity is skipped. This prevents duplicate dashboard values and keeps Modbus as the authoritative source for register-backed data.

Only values returned by the current local web snapshot are available. Optional Navigator 10 infosystem notifications are read independently; if that optional request fails, the other valid web values remain available. See Local Navigator Web Interface for protocol and web-only-mode details.

Internal Message Sensor

The internal_message diagnostic sensor exposes the active IDM internal message as readable text, for example a code plus message description. It also provides the structured attributes message_code and message_text so automations can react either to the numeric code or to the human-readable description.

Binary Sensors

Navigator 1.0/1.7 — momentary coils (c3000/c3003)

The 1.x coil block (ma_de_812049 Rev.1) consists of momentary command bits, not status signals: the controller executes a request the moment the bit is set and the bit immediately falls back to 0 (verified on real 1.7 hardware, issue #319). The coils therefore carry no state entities:

• c3003 — Anforderung Vorrangladung backs the Request DHW priority charge button (see Button): a single-coil write of ON (function code 05), the 1.x hot-water boost. No switch exists by design — a switch would also write OFF, which a momentary command bit must never receive.
• c3000 — Störung quittieren backs the Acknowledge errors button (see Services), single-coil write (FC05) on the 1.x family and holding-register write on the shared Navigator 2.0/10 family.
• c3001/c3002 — Anforderung Heizen/Kühlen are not exposed: requesting heating or cooling is what the operating-mode selects are for.

Numbers (Writable)

DHW

Heating Circuit (per circuit)

Entries marked expert shape the heating curve of the whole installation and write to EEPROM registers. They are created disabled on new installations — enable them under Settings -> Devices & Services -> IDM Heatpump -> Entities. Existing installations keep whatever state the entity already had. hc_{x}_setpoint_flow_constant and hc_{x}_setpoint_flow_cooling are expert entities for the same reason.

hc_{x}_ext_room_temp can be controlled manually like any other number entity or filled automatically by optional room temperature forwarding. When forwarding is enabled, selected Home Assistant temperature sensors are written to these external room temperature registers on state changes and periodically with a 300 second default interval.

GLT / External Control

Power Limits

These registers are model-dependent and disabled by default. Do not use them for legal or contractual load control until the behavior is verified for your exact hardware and firmware.

Selects

Switches

Climate

Climate entities combine a mode selector and a temperature target into the standard Home Assistant thermostat card. Two types are created:

Heating Circuit Climate (climate.hc_x)

One per configured heating circuit (A–G). Controls the circuit operating mode and its normal (day) room setpoint temperature.

Zone Room Climate (climate.zm{z}_room{r})

One per configured room in each zone module. Controls the room operating mode and its temperature setpoint.

Writes go through the coordinator's centralized write path with optimistic updates and translated error messages.

Water Heater

A single water heater entity (water_heater.idm_heatpump) provides DHW target temperature control with current temperature readback. Created when the target register (dhw_setpoint) and a DHW tank temperature register exist — the shared family reports dhw_temp_top, the Navigator 1.0/1.7 map offers dhw_temp (tank temperature, address 1012) instead.

Uses the same coordinator write path as climate entities.

Button

Buttons are one-shot actions. Which buttons exist depends on the Navigator model, the feature profile and the connection mode:

In a web-only entry on a Navigator 10 the web supplement adds its own acknowledge button with the same name, backed by the web interface instead of Modbus. The Modbus buttons are not created in web-only mode.

The primary button (button.idm_heatpump_acknowledge_errors) acknowledges active errors on the heat pump by writing 1 to the error_acknowledge write-only register. Always available so automations can trigger on alarm state changes.

On a detected Navigator 1.0/1.7 a second button (button.idm_heatpump_request_dhw_priority_charge, Vorrangladung anfordern) requests a DHW priority charge: a single FC05 write of ON to coil c3003. Manual use only — the official table puts the coil block under the EEPROM note, so it must not be driven by a schedule or a timed automation.

On at least one 1.x firmware the coil-triggered priority charge does not terminate by itself: the controller stays in DHW mode until error 020 (Wärmepumpenvorlauf Maximaltemperatur) trips (issue #319). If your unit behaves this way, use the system mode Warmwasser einmalig (the system_mode select, or the DHW boost) instead — that path ends the charge normally on the affected hardware. On verified firmware the coil falls back to 0 immediately after the write, which is why the button never writes OFF; please report your firmware behavior in the issue.

Optional feature entities

The optional feature packages add the entities below. The tables list every entity each package can create, with the exact name Home Assistant shows in an English installation (German installations show the German names from the translation files). Entities of a disabled feature are removed from the registry; re-enabling the feature restores the same entity IDs.

Operating analysis (Smart profile)

Derived from observed compressor, defrost and operating-mode transitions. Restart-safe: the counters persist across Home Assistant restarts, and communication gaps are never counted as operating events.

Energy statistics (Smart profile)

Persistent totals computed from the power registers and stored per config entry — day, month and lifetime. They survive restarts; the device's own register meters (energy heating, energy DHW, …) are separate entities listed under Energy & Power. Costs and CO₂ use the optional price and emission factors configured in the Smart profile.

Health monitor (Smart profile option)

Read-only problem checks plus one combined report. Every check is a binary sensor that turns on when its criterion is met; the report bundles the findings as attributes.

Comfort advisory (Smart profile options)

Read-only recommendations, one entity each:

The heating-curve entity is created for the circuit selected in the comfort schedule option; the weather entity requires a configured weather integration.

Predictive advisor (Smart profile option)

Strictly read-only recommendation framework — the advisor never writes to the heat pump. See Predictive Advisor for thresholds, observation levels and the idm_advisor_recommendation event.

AI plant adviser (experimental, off by default)

Deterministic measured-data reports with optional free-form explanations via local Ollama, an HA AI Task entity or explicitly consented cloud requests. See Experimental AI Adviser and Local Ollama for the privacy boundary.

The four buttons are also listed under Button. With the device hierarchy disabled the AI entities still move to their own iDM KI-Anlagenberater device — the AI group is the one sub-device that exists regardless of the hierarchy option.

Assist agent (always on)

A local, deterministic conversation entity. It answers natural-language questions about the running plant — why the heat pump is running, advisor recommendations, temperatures, hot water, consumption/COP and status — in German or English. Everything is computed from the local coordinator snapshot by keyword routing; no utterance leaves the instance and no language model is involved. See Configuration → Assist.

Device groups (device hierarchy)

With Device hierarchy enabled (Configure → Features), the integration distributes its entities over sub-devices so the main heat-pump device stays focused on the controller. These groups are child devices of the heat pump; an upgrade from an older integration release converts the previously via_device-linked devices in place, keeping their device IDs. Zone modules stay ordinary linked devices — separate hardware, not a logical part — and their rooms are children of the module.

The predictive advisor entities (advisor_*) deliberately stay on the main heat-pump device: they describe the plant as a whole, not one removable module. Disabling the hierarchy moves every group back onto the main device (except the AI group); entity IDs never change either way.

Zone Modules

For each enabled zone module (up to 10), room-level entities are created:

Plus per-zone: zm{z}_mode_heat_cool, zm{z}_dehumidification

Differential-temperature controlled heating circuits

For a Navigator 10 circuit configured as Differential temperature control (German controller label: Differenztemperaturgeregelt), select the circuit in Configure → Plant → Differential-temperature controlled circuits, as well as in the installed heating-circuit list. In the advanced form the same selection appears next to Heating circuits. The default is an empty list; normal heating circuits keep their existing behavior. The manual selection is authoritative and separate from the controller's internal differential-control module; with a configured web PIN, Navigator 10 circuits of this type are additionally detected automatically through the local web interface.

For HC D, the measurements reported in issue #429 are mapped as follows; other selected circuits use their corresponding library registers rather than fixed HC D addresses:

The difference is available in every feature profile. Missing, unsupported or invalid measurements produce no usable difference. Status does not substitute for a pump measurement or infer charging from the temperature difference.

Migration: the storage and reference sensors keep their original unique IDs and existing entity IDs (hc_d_flow_temp / hc_d_room_temp); their default names change, while user-customized names remain under user control. Existing automations referencing these IDs continue to work. Normal circuit setpoints, heating curves, heating/cooling limits, external room-temperature inputs, climate entities, flow deviation and web mixer/flow sensors are removed from the registry for selected differential circuits. Update dashboards and automations that referenced those controls. Turning the option off recreates normal circuit entities and removes the difference sensor; customizations of removed controls are not preserved.

Entity IDs: the circuit device is named Heizkreis D and carries the type as its model (Differential temperature control), because Home Assistant prefixes every new entity ID of a device with the device-name slug — a type suffix in the name would double the length of every ID. Entity IDs registered while the device name still ended in (Differenztemperaturgeregelt) (0.20.1-b1…b4) are shortened automatically on the next start: sensor.heizkreis_d_differenztemperaturgeregelt_temperaturdifferenz_hk_d becomes sensor.heizkreis_d_temperaturdifferenz_hk_d. Update dashboards written against those long prerelease IDs; entity IDs you renamed yourself and short IDs already owned by another entity are left untouched.

Unverified parameters: the API does not provide a circuit-type detection register or confirmed differential hysteresis/threshold/maximum-temperature registers. In particular, the reported 60 °C at hc_d_setpoint_flow_constant (1452) is not enough to identify it as the differential threshold. These parameters are deliberately not exposed under guessed names and no new writes are added. This mapping is based on the Navigator 10 report in #429; it still needs confirmation on the reporter's hardware.

Independent firmware observations

Under Reconfigure → Firmware query, a separate explicit switch enables Latest reported firmware. It is off by default and never inherits consent from telemetry. Firmware-only operation works without a myIDM ID or telemetry. Disabling telemetry does not disable separately authorized firmware queries. Disabling firmware queries cancels the request and removes the sensor and its registry entry immediately. Without firmware consent there is no catalog contact.

The query sends only Navigator family, controller/plant model and installed firmware, after a random startup delay of up to 30 minutes, then every six hours plus up to 30 minutes of random delay. It sends no myIDM ID, operating counters, temperatures, credentials or other HA data. There is no persistent firmware queue; the integration keeps only the current result. HA may retain sensor states according to the local Recorder/backup configuration. The server uses metadata transiently and does not save a plant report. The connection IP is technically visible; short-lived rate identifiers expire within two hours at the next hourly cleanup. Both features have a prominent link to the full privacy notice before their consent switch.

The catalog uses community telemetry observations only, never old diagnostic ZIPs. Matching requires the same Navigator/controller and known plant model, firmware prefix/channel and major line. Missing plant types match only other missing-type reports in that same known controller/software series. Test and stable channels remain separate. Ordering includes numeric build numbers. Unknown metadata or absent observations produce no version recommendation.

This is not official IDM availability, installation permission or compatibility approval. Only IDM/your installer can assess and install firmware. Sharing telemetry helps build the catalog, but is not required to use firmware queries. Telemetry notice v3 remains unchanged; independent firmware consent uses idm-firmware-v1. The locally recorded consent time/revision is not sent in firmware queries. Only telemetry uploads carry their own identity and consent.

Privacy and delivery details.

With device hierarchy enabled, Latest reported firmware and the unconfirmed newer-version indicator belong to the logical Diagnostics device alongside the installed software version. Without hierarchy they remain diagnostic entities on the plant device. Existing unique IDs and entity history are preserved. A newer matching observation can create a Repairs notice; acknowledgement is persisted per device/version. See activation and interpretation.