Support the HUB Navizone gateway, and only wire climate features the device reports

[mathieuletyrant]

Adds support for my HUB Navizone air conditioning gateway, and fixes a related issue it exposed.

1. modelId 1758 is missing from the model table

It falls through to the else branch and shows up as "Unknown product (1758)" in the device panel. setupviewv2 reports it as:

modelId 1758 | productId 96 | modelFamily "Air_Conditioning"
longName "HUB Navizone"

(name/customName read HUB SHOGUN - PRT pile on my install, but that is the user-editable label from the Cozytouch app, not the product designation.)

It is the gateway for the air conditioners, which on my setup are modelId 557, 558 and 559 with masterDeviceId pointing at it — the same 557-561 range the 556 Naviclim Hub drives. So 556 and 1758 look like two gateway generations for the same units.

Added to the tested devices list in the README too.

2. Optional climate features were wired regardless of hardware support

That last point has a consequence. fanModes, swingModes and quietModeAvailable are declared per model, and capability.py turned them into capability ids 100801-100804 unconditionally. climate.py then enables FAN_MODE and SWING_MODE purely on those keys being present, so the controls appeared whether or not the hardware backed them. Same for the AC presets, wired to 100505-100507 with no check.

My 557-559 units report none of 100801, 100802, 100803, 100804, 100505 or 100506. Only 100507 (eco) exists. So the model id alone cannot answer what a unit supports — the same id spans hardware with different feature sets.

The failure was silent rather than a crash: get_capability_value falls back to "0" for a capability the device does not have, so the fan and swing selectors showed a fixed bogus value and writes went to an id the device ignores.

get_capability_infos now takes the set of capability ids the device actually reports and only wires each optional feature when it is backed. Replaying my real capability list through it:

key                           my 557 unit    if all declared
fanModeCapabilityId                   no                yes
quietModeCapabilityId                 no                yes
swingModeCapabilityId                 no                yes
swingOnCapabilityId                   no                yes
activityCapabilityId                  no                yes
ecoCapabilityId                      yes                yes
boostCapabilityId                     no                yes

Right-hand column is the regression check: a device that does report them keeps everything. The gating in climate.py already keyed on these keys being present, so it needed no change.

Also drops the unused Hub.get_capability_infos, which passed a modelId int where get_capability_infos expects a modelInfos dict and would have raised on any call. Happy to keep it if you would rather.

Note this touches hub.py, as does #161 — different functions, and they cherry-picked onto each other cleanly, but flagging it.

🤖 Generated with Claude Code

[mathieuletyrant]

Correction after dumping the raw setupviewv2 payload: the product name is HUB Navizone, not "HUB Shogun" as I first proposed. Force-pushed.

name and customName both read HUB SHOGUN - PRT pile on my setup, but that is the user-editable label from the Cozytouch app. The product designation is in longName:

modelId 1758 | productId 96 | modelFamily "Air_Conditioning"
longName     "HUB Navizone"
name         "HUB SHOGUN - PRT pile"   <- user-editable

The dump also settles what sits behind it: the three AC units are modelId 557, 558 and 559, with masterDeviceId pointing at the 1758. That is the same 557-561 range the 556 Naviclim Hub drives, so 556 and 1758 look like two gateway generations for the same units rather than separate product lines. I reworded the code comment accordingly.

Worth noting for anyone reading the table later: since the AC modelId does not change across hub generations, it cannot be used on its own to infer what a unit supports. I hit that concretely — see the separate report I am filing about fanModes/swingModes/quietModeAvailable being declared for 557-561 units that do not expose the matching capabilities.

[mathieuletyrant]

[mathieuletyrant]

Cross-referencing: this covers two open reports of the same device.

• PAC air/air gainable Atlantic Navizone Shogun (2025) #117 (March) — "PAC air/air gainable Atlantic Navizone Shogun", reports Unknown product (1758)
• Support nouveaux produits Atlantic : Hub Shogun (1758) et Zone (1734) #143 (July) — "Hub Shogun (1758) et Zone (1734)", same Unknown product (1758)

Worth noting on naming, since the two issues call it Shogun and this PR names it HUB Navizone: on my install name/customName also read HUB SHOGUN - PRT pile, but those are the user-editable labels from the Cozytouch app. The product designation in longName is HUB Navizone, and #117 frames the whole system as "Navizone Shogun". I went with the value Atlantic's own API reports, but if you would rather the table match what users see in the app, HUB Shogun is a one-line change — your call.

The 1734 half of #143 is already mapped on main via the or modelId == 1734 case, so this PR should close out what remains of both.

[mathieuletyrant]

Added a fourth commit extending the same rule to the current temperature, which also gives an answer to #138.

The 557-561 / 1734 branch sets currentTemperatureAvailable = False, so currentValueCapabilityId is never wired and those climate entities have no ambient reading — only a setpoint. Capability 117 is mapped as its own sensor regardless, so the temperature shows up in HA while the climate entity itself reports nothing, which leaves thermostat cards, current_temperature consumers and Matter bridges without it.

My three units do report 117, with a distinct value per room (24.14 / 24.95 / 24.83), so the flag is wrong for this hardware — same conclusion #138 reaches.

Where I would differ from #138 is the remedy. Flipping the flag to True for the whole range repeats the original mistake in the other direction: get_capability_value falls back to "0" for a capability the device lacks, so a unit in that range without 117 would display a confident 0 °C. A wrong number is worse than a missing one.

So the model flag stays as an explicit opt-out and the device gets the final say, exactly as this PR already does for the fan, swing and preset ids:

if (
    modelInfos.get("currentTemperatureAvailable", True)
    and 117 in availableCapabilityIds
):
    capability["currentValueCapabilityId"] = 117

Replayed both ways:

my units (117 reported)          current_temperature -> 117
unit in range without 117        current_temperature -> not wired

Applied to the heat pump z1/z2 overrides too (117 and 118), so every path that wires a current temperature checks the device first.

Credit to @rafal83 for spotting the underlying problem in #138 — this is the same fix with a guard against the range being wrong for someone else.

[mathieuletyrant]

Fifth commit, and this one explains a user-visible confusion I could not account for before.

On a zoned install only the master room picks the operating mode. A slave accepts a mode write and stores it, but keeps running whatever the master imposes. So capability 7 is a request, not a state — and the integration only ever read 7.

Reproduced on my install. I set a slave room to heat from HA:

ROOM_1 (slave)   capability   7 = 4   modified t=1786611193   <- my write, accepted and persisted
                 capability 181 = 3   modified t=1786611058   <- effective mode, never followed
ROOM_0 (master)  capability   7 = 3                           <- master is on cool

The write was not rejected — no Execution_state error, the value stuck. The room simply kept blowing cold while HA displayed heat with nothing to contradict it. Atlantic's own app has the same blind spot: it colours the room warm.

Capability 181 carries the effective mode, on the same value scale as 7, so it is read through the model's HVACModes and translated to HVACAction. climate.py had no hvac_action at all until now.

What makes this workable is that it removes the need to identify the master. I had parked this problem precisely because nothing in the payload reliably designates the master room, and guessing would have broken installs whose master is not the first unit. With 181 the question disappears — every room reports what it is doing.

Result on the same slave: hvac_mode: heat, hvac_action: cooling. The contradiction becomes legible instead of invisible.

Two caveats stated plainly:

• I only observed 181 at 0 and 3. Values 4, 7 and 8 are extrapolated from the capability 7 scale.
• HVACMode.AUTO is deliberately left unmapped. A system in auto is really heating, cooling or idle, and HVACAction has no auto, so returning nothing beats guessing.

Gated on 181 being reported, like everything else here, so devices that do not expose it are unaffected.

[mathieuletyrant]

The capability list in #86 confirms what capability 181 is:

181  SERVICE_IN_PROGRESS_MODE
117  ROOM_AMBIENT_TEMPERATURE

SERVICE_IN_PROGRESS_MODE is literally the service currently running, which is what this PR reads it as: what the unit is actually doing, as opposed to what it was asked for. That is the distinction hvac_action exists for.

The caveat about values 4, 7 and 8 being extrapolated from the capability 7 scale still stands — the list gives names, not value tables.

It also settles a red herring I chased on the way. 217 and 100023 read 3083 on all three of my rooms, which looked temptingly like 30.83 °C next to an outdoor reading of 30 on the wall unit. They are SYSTEM_AVAILABLE_MODES_CAPABILITIES and SYSTEM_SUPPORTED_MODES_CAPABILITIES — bitmasks. For what it is worth, no capability in the list contains OUTDOOR, OUTSIDE or EXTERIOR, so outdoor temperature does not appear to live in this namespace at all.