8000
Skip to content

[mitsubishi_cn105] Add vertical vane control action - #16737

Merged
bdraco merged 17 commits into
esphome:devfrom
crnjan:feature/mitsubishi_cn105_vane_control_action
Aug 11, 2026
Merged

[mitsubishi_cn105] Add vertical vane control action#16737
bdraco merged 17 commits into
esphome:devfrom
crnjan:feature/mitsubishi_cn105_vane_control_action

Conversation

@crnjan
@crnjan crnjan commented May 30, 2026
Copy link
Copy Markdown
Contributor

What does this implement/fix?

Adds mitsubishi_cn105.vane.control automation support for the Mitsubishi CN105 component.

This PR is a follow-up to #16727. It builds on the vertical vane direction model by adding a climate-style control action for vane settings.

The action is intentionally modeled after climate.control: configured fields are folded into a generated apply lambda, which populates a VaneCall object and then applies the requested changes. This keeps the action extensible as additional vane fields are added later.

To keep this PR small, the initial control surface includes only vertical.direction. The VaneCall structure is intended to grow in follow-up work, with horizontal vane direction control planned next.

Included:

  • config schema/codegen support for mitsubishi_cn105.vane.control
  • VaneCall support for applying vane control requests
  • vertical vane direction control via vertical.direction
  • test config coverage

Types of changes

  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected) — policy
  • Developer breaking change (an API change that could break external components) — policy
  • Undocumented C++ API change (removal or change of undocumented public methods that lambda users may depend on) — policy
  • Code quality improvements to existing code or addition of tests
  • Other

Related issue or feature (if applicable):

Pull request in esphome.io with documentation (if applicable):

Test Environment

  • ESP32
  • ESP32 IDF
  • ESP8266
  • RP2040/RP2350
  • BK72xx
  • RTL87xx
  • LN882x
  • nRF52840

Example entry for config.yaml:

button:
  - platform: template
    name: "Vertical Vane Swing"
    on_press:
      - mitsubishi_cn105.vane.control:
          id: hp
          vertical:
            direction: SWING

Checklist:

  • The code change is tested and works locally.
  • Tests have been added to verify that the new code works (under tests/ folder).

If user exposed functionality or configuration variables are added/changed:

@esphome
esphome Bot commented May 30, 2026
Copy link
Copy Markdown
Contributor

To use the changes from this PR as an external component, add the following to your ESPHome configuration YAML file:

external_components:
  - source: github://pr#16737
    components: [mitsubishi_cn105]
    refresh: 1h

(Added by the PR bot)

@codecov-commenter
codecov-commenter commented May 30, 2026
Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.02%. Comparing base (3540012) to head (c7a2281).

Additional details and impacted files

Impacted file tree graph

@@           Coverage Diff           @@
##              dev   #16737   +/-   ##
=======================================
  Coverage   88.02%   88.02%           
=======================================
  Files          65       65           
  Lines       14902    14902           
  Branches     2241     2241           
=======================================
  Hits        13117    13117           
  Misses       1473     1473           
  Partials      312      312           
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@github-actions
github-actions Bot 8000 commented May 30, 2026
Copy link
Copy Markdown
Contributor

Memory Impact Analysis

Components: mitsubishi_cn105
Platform: esp8266-ard

Metric Target Branch This PR Change
RAM 30,112 bytes 30,168 bytes 📈 🔸 +56 bytes (+0.19%)
Flash 280,107 bytes 280,459 bytes 📈 🔸 +352 bytes (+0.13%)
📊 Component Memory Breakdown
Component Target Flash PR Flash Change
[esphome]mitsubishi_cn105 6,110 bytes 6,369 bytes 📈 🚨 +259 bytes (+4.24%)
[esphome]core 8,017 bytes 8,082 bytes 📈 🔸 +65 bytes (+0.81%)
🔍 Symbol-Level Changes (click to expand)

Changed Symbols

Symbol Target Size PR Size Change
setup 918 bytes 983 bytes 📈 +65 bytes (+7.08%)
esphome::mitsubishi_cn105::MitsubishiCN105VerticalVaneDirectionSelect::control(unsigned int) 78 bytes 135 bytes 📈 +57 bytes (+73.08%)
esphome::mitsubishi_cn105::MitsubishiCN105Climate::control(esphome::climate::ClimateCall const&) 286 bytes 331 bytes 📈 +45 bytes (+15.73%)
esphome::mitsubishi_cn105::MitsubishiCN105Component::notify_status_listeners_() 94 bytes 91 bytes 📉 -3 bytes (-3.19%)
esphome::mitsubishi_cn105::MitsubishiCN105Climate::set_supported_swing_mode(esphome::climate::Cli...esphome::mitsubishi_cn105::MitsubishiCN105Climate::set_supported_swing_mode(esphome::climate::ClimateSwingMode)
34 bytes 35 bytes 📈 +1 bytes (+2.94%)
esphome::Action<esphome::mitsubishi_cn105::VaneState const&>::play_complex(esphome::mitsubishi_cn...esphome::Action<esphome::mitsubishi_cn105::VaneState const&>::play_complex(esphome::mitsubishi_cn105::VaneState const&)
71 bytes 70 bytes 📉 -1 bytes (-1.41%)
esphome::mitsubishi_cn105::MitsubishiCN105Climate::apply_values_() 217 bytes 216 bytes 📉 -1 bytes (-0.46%)

New Symbols (top 15)

Symbol Size
esphome::mitsubishi_cn105::VaneCall::perform() 73 bytes
esphome::mitsubishi_cn105::VaneControlAction<>::play() 36 bytes
vtable for esphome::mitsubishi_cn105::VaneControlAction<> 28 bytes
mitsubishi_cn105__mitsubishi_cn105_vanecontrolaction_id_2__pstorage 20 bytes
mitsubishi_cn105__mitsubishi_cn105_vanecontrolaction_id__pstorage 20 bytes
setup::{lambda(esphome::mitsubishi_cn105::VaneCall&)#4}::_FUN(esphome::mitsubishi_cn105::VaneCall&) 12 bytes
setup::{lambda(esphome::mitsubishi_cn105::VaneCall&)#3}::_FUN(esphome::mitsubishi_cn105::VaneCall&) 12 bytes

Note: This analysis measures static RAM and Flash usage only (compile-time allocation).
Dynamic memory (heap) cannot be measured automatically.
⚠️ You must test this PR on a real device to measure free heap and ensure no runtime memory issues.

This analysis runs automatically when components change. Memory usage is measured from a representative test configuration.

@crnjan
crnjan force-pushed the feature/mitsubishi_cn105_vane_control_action branch from f7eea94 to 7d24a6c Compare June 1, 2026 20:59
@crnjan
crnjan force-pushed the feature/mitsubishi_cn105_vane_control_action branch from 7d24a6c to 9c470e4 Compare June 4, 2026 12:22
@crnjan
crnjan force-pushed the feature/mitsubishi_cn105_vane_control_action branch from 9c470e4 to ef73971 Compare June 4, 2026 12:24
@paolofaz
Copy link
Copy Markdown

@crnjan I'm updating from 2026.5.1 to 2026.5.3 and my code (it is your code) is not working, what is changed?
`
external_components:

  • source: github://pr#16737
    components: [mitsubishi_cn1 8000 05]
    refresh: 1h
    climate:
  • platform: mitsubishi_cn105
    name: camera
    id: camera
    uart_id: ac_uart
    update_interval: 10s
    vane:
    on_state:
    then:
    - lambda: |-
    using VaneMode = esphome::mitsubishi_cn105::MitsubishiCN105::VaneMode;
    switch (x.vertical.direction) {
    case VaneMode::POSITION_1:
    id(custom_vertical_vane).publish_state("↑↑");
    break;
    case VaneMode::POSITION_2:
    id(custom_vertical_vane).publish_state("↑");
    break;
    case VaneMode::POSITION_3:
    id(custom_vertical_vane).publish_state("—");
    break;
    case VaneMode::POSITION_4:
    id(custom_vertical_vane).publish_state("↓");
    break;
    case VaneMode::POSITION_5:
    id(custom_vertical_vane).publish_state("↓↓");
    break;
    case VaneMode::SWING:
    id(custom_vertical_vane).publish_state("Swing");
    break;
    case VaneMode::AUTO:
    id(custom_vertical_vane).publish_state("Auto");
    break;
    case VaneMode::UNKNOWN:
    ESP_LOGW("vane", "Unknown vertical vane direction");
    break;
    }
    select:
  • platform: template
    id: custom_vertical_vane
    name: "Custom Vertical Vane"
    optimistic: true
    options:
    • "↑↑"
    • "↑"
    • "—"
    • "↓"
    • "↓↓"
    • "Swing"
    • "Auto"
      set_action:
    • climate.mitsubishi_cn105.vane.control:
      id: camera
      vertical:
      direction: !lambda |-
      using VaneMode = esphome::mitsubishi_cn105::MitsubishiCN105::VaneMode;
      if (x == "↑↑") return VaneMode::POSITION_1;
      if (x == "↑") return VaneMode::POSITION_2;
      if (x == "—") return VaneMode::POSITION_3;
      if (x == "↓") return VaneMode::POSITION_4;
      if (x == "↓↓") return VaneMode::POSITION_5;
      if (x == "Swing") return VaneMode::SWING;
      if (x == "Auto") return VaneMode::AUTO;
      ESP_LOGW("vane", "Unknown custom vertical vane option: %s", x.c_str());
      return VaneMode::AUTO;

`

@crnjan
crnjan commented Jun 10, 2026
Copy link
Copy Markdown
Contributor Author

@paolofaz It's not related to the esphome upgrade to 2026.5.3, but mitsubishi_cn105::MitsubishiCN105::VaneMode was adopted (in this PR) to a more esphome like public facing interface, so i.e.
mitsubishi_cn105::MitsubishiCN105::VaneMode::AUTO -> mitsubishi_cn105::VERTICAL_VANE_MODE_AUTO

Updated yaml:

mitsubishi_cn105:
  id: hp
  uart_id: ac_uart
  vane:
    on_state:
      then:
        - lambda: |-
            switch (x.vertical.direction) {
              case VERTICAL_VANE_MODE_POSITION_1:
                id(custom_vertical_vane).publish_state("↑↑");
                break;
              case VERTICAL_VANE_MODE_POSITION_2:
                id(custom_vertical_vane).publish_state("↑");
                break;
              case VERTICAL_VANE_MODE_POSITION_3:
                id(custom_vertical_vane).publish_state("—");
                break;
              case VERTICAL_VANE_MODE_POSITION_4:
                id(custom_vertical_vane).publish_state("↓");
                break;
              case VERTICAL_VANE_MODE_POSITION_5:
                id(custom_vertical_vane).publish_state("↓↓");
                break;
              case VERTICAL_VANE_MODE_SWING:
                id(custom_vertical_vane).publish_state("Swing");
                break;
              case VERTICAL_VANE_MODE_AUTO:
                id(custom_vertical_vane).publish_state("Auto");
                break;
              case VERTICAL_VANE_MODE_UNKNOWN:
                ESP_LOGW("vane", "Unknown vertical vane direction");
                break;
            }

climate:
  - platform: mitsubishi_cn105
    id: hp_climate
    name: Heat Pump
    mitsubishi_cn105_id: hp
    # ...

select:
  - platform: template
    id: custom_vertical_vane
    name: "Custom Vertical Vane"
    optimistic: true
    options:
      - "↑↑"
      - "↑"
      - "—"
      - "↓"
      - "↓↓"
      - "Swing"
      - "Auto"
    set_action:
      - mitsubishi_cn105.vane.control:
          id: hp
          vertical:
            direction: !lambda |-
              if (x == "↑↑")
                return VERTICAL_VANE_MODE_POSITION_1;
              if (x == "↑")
                return VERTICAL_VANE_MODE_POSITION_2;
              if (x == "—")
                return VERTICAL_VANE_MODE_POSITION_3;
              if (x == "↓")
                return VERTICAL_VANE_MODE_POSITION_4;
              if (x == "↓↓")
                return VERTICAL_VANE_MODE_POSITION_5;
              if (x == "Swing")
                return VERTICAL_VANE_MODE_SWING;
              if (x == "Auto")
                return VERTICAL_VANE_MODE_AUTO;

              ESP_LOGW(
                "vane",
                "Unknown custom vertical vane option: %s",
                x.c_str()
              );
              return VERTICAL_VANE_MODE_AUTO;

Please note until PR is merged there still might a change or two, depending on the feedback - will make sure to flag it properly if there is any future breaking change in this PR.

@esphome esphome Bot removed the needs-docs label Aug 11, 2026
@crnjan
crnjan marked this pull request as ready for review August 11, 2026 21:36
Copilot AI lite review requested due to automatic review settings August 11, 2026 21:37
Copilot AI left a comment
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds a new automation action to the mitsubishi_cn105 component that lets users control the vertical vane direction via a mitsubishi_cn105.vane.control action, following the same “fold configured fields into an apply lambda” pattern used by climate.control.

Changes:

  • Introduces VaneCall + VaneControlAction to apply vane control requests (initially vertical direction only).
  • Extends vertical vane direction enum/state handling to include/publish UNKNOWN.
  • Updates select option source-of-truth and adds unit/config test coverage for the new action.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.

Show a summary per file
File Description
tests/components/mitsubishi_cn105/mitsubishi_cn105_component_tests.cpp Adds unit tests for VaneCall/VaneControlAction and updates vane-state tests to include UNKNOWN.
tests/components/mitsubishi_cn105/common.yaml Adds YAML config coverage for mitsubishi_cn105.vane.control (literal + lambda forms).
tests/components/mitsubishi_cn105/common.h Includes the new mitsubishi_cn105/automation.h in the test harness.
esphome/components/mitsubishi_cn105/select/mitsubishi_cn105_vane_select_vertical.cpp Updates comment to reflect the new shared source-of-truth for option ordering.
esphome/components/mitsubishi_cn105/select/init.py Reuses the hub’s VERTICAL_VANE_DIRECTIONS mapping for select options.
esphome/components/mitsubishi_cn105/mitsubishi_cn105_component.h Adds VaneCall, make_vane_call(), and VERTICAL_VANE_MODE_UNKNOWN; always publishes vane state.
esphome/components/mitsubishi_cn105/mitsubishi_cn105_component.cpp Implements VaneCall::perform() to apply requested vane changes and publish.
esphome/components/mitsubishi_cn105/automation.h Adds VaneControlAction patterned after climate::ControlAction.
esphome/components/mitsubishi_cn105/init.py Adds schema/codegen for mitsubishi_cn105.vane.control with templatable vertical.direction.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@esphbot
esphbot commented Aug 11, 2026
Copy link
Copy Markdown
Contributor

@crnjan: @paolofaz It's not related to the esphome upgrade to 2026.5.3, but `mitsubishi_cn105::MitsubishiCN...

Rename explanation correct. One addition worth flagging: this PR also adds VERTICAL_VANE_MODE_UNKNOWN. Exhaustive switches need that extra case. notify_status_listeners_() no longer suppresses UNKNOWN either, so on_state now fires for it — previously it did not. Your updated snippet already handles both. Neither appears in the PR description. Add them there and in esphome.io#7162, since descriptions become release notes.

@esphbot
esphbot commented Aug 11, 2026
Copy link
Copy Markdown
Contributor

Previous review — superseded by a newer review below.

@esphbot esphbot left a comment
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tip

No blocking issues found — ready to merge.

Comment on lines +218 to +247
6D38
parent = await cg.get_variable(config[CONF_ID])
normalized_args = [
(cg.RawExpression(f"const std::remove_cvref_t<{cg.safe_exp(t)}> &"), name)
for t, name in args
]
forwarded_args = ", ".join(name for _, name in args)
body_lines: list[str] = []

for path, setter, type_ in VANE_CONTROL_FIELDS:
if (section := config.get(path[0])) is None:
continue
if (value := section.get(path[1])) is None:
continue
if isinstance(value, Lambda):
inner = await cg.process_lambda(
value,
normalized_args,
return_type=type_,
)
body_lines.append(f"call.{setter}(({inner})({forwarded_args}));")
else:
body_lines.append(f"call.{setter}({cg.safe_exp(value)});")

apply_lambda = LambdaExpression(
["\n".join(body_lines)],
[(VaneCall.operator("ref"), "call"), *normalized_args],
capture="",
return_type=cg.void,
)
return cg.new_Pvariable(action_id, template_arg, parent, apply_lambda)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might have a cleaner way to do this in light, need to check

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checked light. Same pattern, no cleaner variant. esphome/components/light/automation.py:206-253 uses identical normalized_args spelling, body_lines accumulation, captureless LambdaExpression, and cg.new_Pvariable(action_id, template_arg, paren, apply_lambda). Only two deltas: FIELDS declared function-local rather than module-level, plus an extra LightState *parent lambda parameter so effect names can resolve to an index at runtime. Neither applies here. Climate matches too (climate/__init__.py:509-548). One deviation worth noting in this PR: VANE_CONTROL_FIELDS carries a (section, field) path tuple for two-level lookup, indexed as path[0]/path[1] — unpacking those into named locals would read better than positional indices.

@esphbot
esphbot commented Aug 11, 2026
Copy link
Copy Markdown
Contributor

@paolofaz: @crnjan I'm updating from 2026.5.1 to 2026.5.3 and my code (it is your code) is not working, what is...

Important

Two separate causes, likely. First, component structure changed: hub now lives under top-level mitsubishi_cn105: with climate: as a platform pointing at it via mitsubishi_cn105_id, so an older single-block climate: config needs updating. Second, and specific to this PR head: VERTICAL_VANE_MODE_UNKNOWN gets added to VerticalVaneMode, and vane: on_state: now fires for UNKNOWN too. An exhaustive switch over those values needs an extra case, else -Wswitch breaks your build. Post your full compile error and current YAML for a precise answer.

@esphbot
esphbot commented Aug 11, 2026
Copy link
Copy Markdown
Contributor

PR Review — [mitsubishi_cn105] Add vertical vane control action

Merge-ready. Four non-blocking suggestions, none of which gate the merge.

The codegen is a faithful port of an established in-tree pattern rather than a new invention. I diffed it against both reference implementations — climate/__init__.py:509-548 and light/automation.py:206-253 — and the FIELDS table, the const std::remove_cvref_t<T> & argument normalisation, the captureless LambdaExpression folding into a function-pointer ApplyFn, and synchronous=True all line up, so the action stores one pointer and keeps its constants in flash. I traced the generated C++ end to end and it is sound: safe_exp resolves EnumValue via .enum_value before the str branch, so direction: SWING emits the enumerator and not a string literal; MockObjEnum with is_class=False yields the correct unscoped-enum spelling esphome::mitsubishi_cn105::VERTICAL_VANE_MODE_SWING; and process_lambda defaults to capture="", so the outer lambda stays captureless and the conversion to ApplyFn holds even with an inner field lambda. VaneCall is forward-declared correctly ahead of the component with perform() defined out-of-line, and taking the parent as a constructor parameter matches the repo's required-and-invariant-dependency rule. Test coverage is real: gtest for both VaneCall and VaneControlAction, plus YAML compile coverage of the literal and !lambda forms.

Three things that looked like defects and are not, so they are absent from the findings:

  • set_vane_mode(VaneMode::UNKNOWN) cannot reach the wire — LookupMap::reverse_lookup short-circuits on the sentinel and returns false, despite UNKNOWN also sitting at raw 0x06 in the map.

  • cv.enum(..., upper=True) handles the numeric "1""5" keys correctly: one_of sets string_ = string or lower or upper and cv.string coerces a YAML integer before the membership test.

  • VaneCall::perform() publishing unconditionally is the established local convention, not a wart — MitsubishiCN105Climate::control() and MitsubishiCN105VerticalVaneDirectionSelect::control() both end with the same unguarded publish_status().

  • The UNKNOWN publishing change and the new VERTICAL_VANE_MODE_UNKNOWN enumerator remain outside the stated scope and undeclared in the description. Not breaking — 2026.8.0 is unreleased — but PR descriptions become release notes.

  • VERTICAL_VANE_DIRECTIONS now backs both the action's YAML enum and the select's index-aligned option list via .capitalize(). Output is identical today; the risk is a future key silently appending a dead select option or shifting the VALUES index contract.

  • cg.add_global(mitsubishi_ns.using) sits in the action codegen rather than to_code(), so it repeats per action instance. climate and light both put it at component scope. Purely generated-code noise, and not load-bearing here since every emitted expression is already fully qualified.

  • No test pins the one branch this PR newly makes reachable: a !lambda returning VERTICAL_VANE_MODE_UNKNOWN.

Process nit: the PR template's Test Environment and "tests have been added" boxes are still unchecked even though tests were in fact added.


🟢 Suggestions

1. Undeclared behavior change: vane state now published for UNKNOWN (carried forward, still unresolved)
esphome/components/mitsubishi_cn105/mitsubishi_cn105_component.h:96-98

notify_status_listeners_() previously suppressed the vane callback when vane_mode == UNKNOWN; it now fires unconditionally, and VERTICAL_VANE_MODE_UNKNOWN is a new enumerator in the public VerticalVaneMode. Neither change appears in the PR description's four bullets, and "Breaking change" stays unchecked.

Why it matters: this is a user-visible change to the vane: on_state: trigger, not a consequence of adding the control action — nothing in VaneCall/VaneControlAction reads it. I re-verified against the tree: MitsubishiCN105::is_status_initialized() keys off room_temperature/target_temperature, never vane_mode, so a spurious UNKNOWN event at boot is reachable before the first settings packet decodes. Exhaustive switch statements over VerticalVaneMode — the pattern documented in esphome.io#7162 and the one @paolofaz is using — now need an extra case or they take -Wswitch.

I confirmed this is not breaking for released users, which is why it stays a suggestion: 2026.8.0 is unreleased, so vane: on_state: has never shipped. I also confirmed no in-tree consumer regresses — MitsubishiCN105VerticalVaneDirectionSelect::setup() and the climate platform both subscribe to add_on_status_callback, not the vane callback, and publish_vane_state() silently returns for a mode absent from VALUES.

Fix: add a bullet to the PR description covering both the enum addition and the always-publish change (PR descriptions generate release notes), or split it into its own commit so it is reviewable on its own terms.

    this->vane_state_callback_.call(VaneState{
        .vertical = {.direction = static_cast<VerticalVaneMode>(this->status().vane_mode)},
    });

Checklist

  • Generated C++ compiles from the emitted expressions (enum spelling, captureless lambda, ApplyFn signature match)
  • Config validation handles all key forms accepted by the schema (numeric and word enum keys, lambda form)
  • Invalid vane mode cannot reach the device
  • No regression for in-tree consumers of the changed callback
  • Publish-on-perform matches the component's established convention
  • Test coverage for new branches (VaneCall, VaneControlAction, literal + lambda YAML)
  • Diff matches the PR description; no undeclared scope — suggestion #1
  • Shared constants have a single, unambiguous consumer contract
  • Codegen side effects are emitted once, at the right scope
  • No backward-incompatible change to a released public interface
ℹ️ Triage summary

3 pre-existing finding(s) on unchanged code suppressed (freeze).


Automated review by Kōan (Claude) HEAD=c7a2281 6 min 51s

@esphbot esphbot left a comment
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tip

No blocking issues found — ready to merge.

@bdraco
bdraco merged commit 9556c2b into esphome:dev Aug 11, 2026
42 checks passed
@bdraco
bdraco commented Aug 11, 2026
Copy link
Copy Markdown
Member

Thanks @crnjan

@crnjan
crnjan deleted the feature/mitsubishi_cn105_vane_control_action branch August 12, 2026 07:46
@github-actions github-actions Bot locked and limited conversation to collaborators Aug 13, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet
4B48

Development

Successfully merging this pull request may close these issues.

6 participants

0