Decode the NY9100DW burner entities when no Fuel_ token is reported - #779

What is wrong

The per-burner entities from #450 are gated on a Fuel_Gas token in /mode/vs/0 options. The NY9100DW/AA (TP1X_DA-KS-RANGE-0102X) reports no Fuel_* token at all, so it only gets the raw cooktop_monitoring diagnostic.

The issue's data shows its mask matches the bit map already verified on the gas NX60T8311SS: with each burner lit alone, cooktopMonitoring read 1, 2, 4, 8 and 16 for front-left, back-left, center, back-right and front-right.

Fixes #767

The change

_fuel_is_gas() in registry/capabilities/range.py:

• If a Fuel_* token is present, behavior is unchanged: gas only when it is Fuel_Gas.
• If no Fuel_* token is present, the board counts as gas only when its DeviceType_ value starts with NY.

Evidence

New test file: tests/test_range_ny9100dw_capabilities.py, a minimal synthetic resource set built from the values posted in the issue.

The 6 failures before the fix were the five single-burner cases and the all-off case: cooktop_monitoring stayed raw and active_burners did not exist. The 2 that passed before the fix are guards that must not change (NY with Fuel_Electric, and NE8300D).

ruff format --check, ruff check and ty check pass on custom_components and tests (ruff 0.16.1, ty 0.0.65).

What the local test run does and does not cover

These results are from Windows on Python 3.13, not CI's Python 3.14. Home Assistant's pytest plugin cannot start on Windows (it imports fcntl), so the suite ran with -p no:homeassistant and PYTHONUTF8=1. lru-dict was 1.4.1 instead of Home Assistant's pinned 1.3.0, because 1.3.0 has no Windows wheel for Python 3.13.

The 8 extra passes are the new tests, and the set of erroring tests is identical on both trees. All 1192 errors are missing Home Assistant fixtures (hass, enable_custom_integrations, recorder_mock), so those tests did not run locally. They include the config flow and coordinator tests. CI needs to confirm them.

Boards intentionally not touched

• NX without a Fuel_* token: stays raw. There is no evidence for this case, and test_board_without_fuel_token_gets_raw_value_only keeps passing.
• NE (electric) boards: stay raw. On an NE6516A-class board the field is a 0/1 flag rather than a bitmask (Gas range: cooktopMonitoring is a bitmask of lit burners (NX60T8311SS) #450).
• BurnerOnAlter_On is not used as a signal: the electric NE8300D fixture carries it too. A test covers this.
• NY boards that report Fuel_Electric: stay raw. The model prefix only fills in for a missing token and never overrides a reported one. A test covers this.

What only the reporter can verify on the real device

• The active_burners sensor and the five cooktop_burner_N binary sensors appear after updating, and each follows the matching physical burner.
• Combinations behave correctly. The issue tested each burner alone, so multi-burner values on this board are untested.
• What happens to the existing raw cooktop_monitoring entity. Decoded boards no longer get it, so it may be left behind in the entity registry.

Assumptions

• That other NY models also have this bit map. It is confirmed on one unit only.
• That the NY prefix indicates a gas cooktop. This comes from the model-number note in the issue and has not been checked against any other NY board.
• That DeviceType_ follows the retail model prefix. It does not always match the retail model: the NX60T8311SS reports NX9302T-.
• That NY boards have five burners. The mask cannot report the burner count, so a four-burner NY board would show an unused Burner 5, the same limitation as the existing NX rule.