[webdjoe]

Description

This PR rewrites air fryer support around a single VeSyncFryer interface and adds five new Cosori models. It is the integration branch for the air fryer work. Each part was reviewed and squash-merged here as its own PR:

PR	Change
#517	Add the Dual Blaze (CAF-P583S)
#575	Report preheat on the TurboBlaze, and send readyStart false (from #560)
#578	Skip devices that fail to initialize, and log unexpected update errors
#579	Add the chamber interface, presets and temperature limits from the device map, and unit handling
#580	Make the fryers resilient to failed or unreadable responses, and keep local state consistent
#581	Add the CAF-DC111S-AEU Turbo Tower Pro (replaces #536, from arypien's captures)
#582	Keep the API code and message for unknown error codes (merged to dev, then cherry-picked here)

Supported fryers

Model	Class	Chambers	Preheat	Pause / resume
CS137-AF, CS158-AF	VeSyncAirFryer158	1	✔	✔
CAF-DC601S TurboBlaze (new)	VeSyncTurboBlazeFryer	1	✔
CAF-P583S Dual Blaze, KUS and KEU (new)	VeSyncDualBlazeFryer	1
CAF-TF101S Dual Air Fryer (new)	VeSyncDualAirFryer	1, 2, whole, both
CAF-TF102S (new)	VeSyncDualAirFryer	1, 2, whole, both
CAF-DC111S-AEU Turbo Tower Pro (new)	VeSyncDualAirFryer	1 (upper), 2 (lower), both

Common interface

These are on VeSyncFryer (base_devices/fryer_base.py):

• Cook controls. Every fryer has:

  • set_mode(cook_time, cook_temp, *, temp_unit, preheat_time, cook_mode, chamber);
  • set_mode_from_recipe(recipe, chamber);
  • end(chamber) and update().

  stop(), resume() and cook_from_preheat() are implemented only on the CS137/CS158. On the other fryers they log a message and return False without sending a request.

• Chambers. AirFryerChamber has CHAMBER_1, CHAMBER_2, WHOLE and BOTH. The device also has:

  • supported_chambers and is_dual_chamber;
  • get_chamber_state();
  • sync_chambers and work_chamber.

  BOTH is sent as the app's Sync mode. Each chamber has its own FryerState.

• Cook modes and presets come from the device map. Each model's map entry defines its cook modes (AirFryerModeConfig) and per-mode temperature limits and steps (AirFryerTempLimits). The fryer exposes them through get_cook_mode(), get_mode_recipe() and temp_limits(). A temperature is rounded to the mode's step, then checked against the mode's range.

• Temperature units. The device map gives each model its starting unit and step, and the unit the API reports takes over once the fryer updates. Times are in seconds. Temperatures are in the fryer's unit, unless you pass temp_unit.

• State. FryerState tracks:

  • the cook status, as the AirFryerCookStatus enum;
  • the preheat, cook and total remaining times, which count down locally between updates and carry across stop, resume and preheat;
  • the set time and temperature, and the cook mode.

Error handling

• A command the fryer refuses returns False, leaves the state as it was, and records the reason in last_response.
• A failed or unreadable update also leaves the state unchanged. That covers no response, an error code, a null result, an unknown status, or an out-of-range step index.
• Air fryer error codes are added to ErrorCodes, including the DC111S Sync refusals 11914000, 11915000 and 11926000.
• An unknown error code is looked up the way the VeSync app does it: the code is truncated to the thousand, and if that doesn't match, it falls back to UNKNOWN. Either way the API code and message are kept for last_response and the logs.

Other changes

• DeviceContainer skips a device whose class raises VeSyncError while it is created, with a warning. One bad device no longer stops discovery of the rest.
• update_all_devices() logs errors other than VeSyncError with their traceback, instead of dropping them.
• VeSync.save_credentials(None) now saves to the configured token file, or to .vesync_auth in the working directory if none is set. It used to save nothing. Its docstring still says "If None, no action is taken".
• Ruff is pinned to 0.15.21 in pyproject.toml, requirements-dev.txt and the pre-commit config, and ERA001 (commented-out code) is now enforced.
• Docs:
  • docs/devices/kitchen.md is rewritten;
  • the README and docs/supported_devices.md list the new models;
  • the AGENTS.md and test guides describe the air fryer tests.

Breaking changes for CS137/CS158 users (released in 3.4.2)

3.4.2	This PR
cook(set_temp, set_time) (minutes)	set_mode(cook_time, cook_temp) (seconds)
set_preheat(target_temp, cook_time)	set_mode(cook_time, cook_temp, preheat_time=...)
pause()	stop()
check_status()	update()
state.is_resumable	state.can_resume
state.remaining_time	state.total_time_remaining
state.is_heating	state.is_preheating
state.cook_status as a string	AirFryerCookStatus

toggle_switch() is deprecated and sends no request, because air fryers have no on/off command.

Type of change

• Bug fix (fix:)
• New feature or device support (feat:)
• Documentation (docs:)
• Refactor / test / chore (no functional change)

Checklist

• This PR is a single feature, fix, or edit. It is an integration branch: each part was reviewed and merged as its own PR (see the table above).
• The change follows the intended architecture (base class → device + API mixin → device map; state in DeviceState; models in models/; constants in pyvesync.const).
• No API request/response fields were invented. All come from real packet captures, and the cook modes and limits come from the VeSync app. The exceptions are flagged under hardware verification below.
• ruff check, pylint, mypy and pytest pass locally: 613 passed, 3 skipped; pylint 10/10.
• Tests are added and the API fixtures are written. The YAML fixtures under src/tests/api/vesynckitchen/ cover update() for each fryer. test_fryer_captures.py, test_fryer_chambers.py, test_fryer_units.py, test_fryer_resilience.py, test_errors.py and test_manager_resilience.py cover the rest.
• Documentation is updated.

Real-hardware verification

• Tested on the physical device.
  • CAF-P583S-KUS, firmware v1.0.15: remote start and stop, status polling, and all 11 presets (feat: add Cosori Dual Blaze (CAF-P583S) air fryer support #517).
  • CS137-AF / CS158-AF: model and firmware ____
  • CAF-DC601S: model and firmware ____
  • CAF-TF101S: model and firmware ____
• Not applicable.
• I do not own the device; a packet capture is provided / the device has been shared with a maintainer for verification.

Still pending hardware verification:

• CAF-TF102S: mapped from the VeSync app. There is no capture.
• CAF-DC111S-AEU: the status captures come from feat: add CAF-DC111S-AEU air fryer support #536. The cook and end requests have not been tested on the device.
• CAF-P583S-KEU: there is no capture. It is assumed to match the KUS, apart from using Celsius.
• CAF-TF101S: there is no capture with readyStart false. Its status after a cook starts (COOKING) is inferred from the CS158 captures.

[cdnninja]

Few thoughts. As well were is state for each chamber? Maybe I missed that.

[lackas]

Added CAF-TF102S (Cosori Dual Blaze TwinFry 10L) support on top of this branch: lackas/pyvesync@e86d102

We also built a custom HA integration component with dual-chamber sensor entities (per-zone cook status, temperature, remaining time) based on this refactor: https://github.com/lackas/ha-core/tree/vesync-air-fryer

Both have been running in production. Happy to help get this over the finish line if needed.

[webdjoe]

Hi @lackas thank you for the support! I just want to confirm that you successfully used this PR with the dual blaze? Everything is working as it should?

[lackas]

Confirmed. Running locally in HA via my custom integration component; both chambers behave as expected (status, temperature, remaining time). All good.

[fma965]

Has there been any update on this?

[webdjoe]

Apologies for the wait, releasing this today.

[Klaestrup]

Tested using Claude, and the following report is also generated by Claude. I hope it helps:

Tested this branch (commit 685d5ed) on a Cosori Dual Blaze Chef Edition, EU model
(label: CAF-P583S-KEUR), via a custom copy of the HA 2026.10.4 VeSync integration.

• The cloud reports deviceType "CAF-P583S-KEU", so the KEU entry matches as is.
• Status polling works: standby -> cooking -> cookEnd, currentTemp in °C,
  totalTimeRemaining counts down, and a cook time changed on the device during
  cooking is picked up.
• Not tested yet: remote start/stop, basket pulled out.

One issue: for an unmapped device type, _build_device_instance logs
device.to_json(indent=True), which raises TypeError with mashumaro 3.23
(as shipped with HA 2026.10). Since the argument is evaluated even with debug
logging off, any unmapped device on the account aborts the whole setup.

[charlie508010]

Hello,

I had another look at the different air fryer PRs. #550 and #557 already build on your shared base in #503. The Turbo Tower support from #536, #552 and my PR #564 is still separate from that.

I can see a lot of similarities in the commands, for example getAirfryerMultiStatus, startMultiCook and endCook. But there are also differences in the programmes, the start behaviour and the basket states.

I have now tested my CAF-DC111S-AEU directly with pyvesync, without Home Assistant. I went through all seven programmes as presets on both baskets in Celsius and Fahrenheit. I also checked stopping, the status responses, SYNC and MATCH. The results are in #564.

Would it help you if I adapted the Turbo Tower support to your base in #503 and only added the differences for my device? I would like to build on your existing work as much as possible and make it easier for you to bring the changes together.

Of course, I cannot verify the other models with my device.

[webdjoe]

@charlie508010 I've already begun to rebuild the DC111S PR's on top of this branch. I'm not sure if was you or someone else that sent me the captures to make it possible.

[charlie508010]

Hello, thanks for the update. Then I don’t need to work on the adaptation in parallel.

My direct device tests and results are in #564. I tested the CAF-DC111S-AEU without Home Assistant: all seven programmes as presets on both baskets in Celsius and Fahrenheit, as well as stopping, status responses, SYNC and MATCH.

When your updated version is ready, I’ll be happy to test it again directly on my device.