Skip to content

Add support for YS7914#159586

Merged
joostlek merged 4 commits into
home-assistant:devfrom
YoSmart-Inc:ys7914
Dec 29, 2025
Merged

Add support for YS7914#159586
joostlek merged 4 commits into
home-assistant:devfrom
YoSmart-Inc:ys7914

Conversation

@matrixd2
Copy link
Copy Markdown
Contributor

@matrixd2 matrixd2 commented Dec 22, 2025

Proposed change

Add support for YS7914

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New integration (thank you!)
  • New feature (which adds functionality to an existing integration)
  • Deprecation (breaking change to happen in the future)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Additional information

Checklist

  • I understand the code I am submitting and can explain how it works.
  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • I have followed the perfect PR recommendations
  • The code has been formatted using Ruff (ruff format homeassistant tests)
  • Tests have been added to verify that the new code works.
  • Any generated code has been carefully reviewed for correctness and compliance with project standards.

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

If the code communicates with devices, web services, or third-party tools:

  • The manifest file has all fields filled out correctly.
    Updated and included derived files by running: python3 -m script.hassfest.
  • New or updated dependencies have been added to requirements_all.txt.
    Updated by running python3 -m script.gen_requirements_all.
  • For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

Copy link
Copy Markdown
Member

@joostlek joostlek left a comment

Choose a reason for hiding this comment

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

Can we please bump the dependency in a separate PR?

@home-assistant
Copy link
Copy Markdown
Contributor

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

@home-assistant home-assistant Bot marked this pull request as draft December 22, 2025 10:40
@matrixd2 matrixd2 marked this pull request as ready for review December 23, 2025 01:02
@home-assistant home-assistant Bot requested a review from joostlek December 23, 2025 01:02
@@ -41,15 +41,16 @@ class YoLinkBinarySensorEntityDescription(BinarySensorEntityDescription):
"""YoLink BinarySensorEntityDescription."""
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.

If you add kw_only=True to the dataclass decorator, you can omit the defaults

Comment on lines +62 to +90
def parse_data_leak_sensor_state(device: YoLinkDevice, data: dict) -> bool | None:
"""Parse leak sensor state."""
if device.device_type == ATTR_DEVICE_MULTI_CAPS_LEAK_SENSOR:
if (state := data.get("state")) is None or (
value := state.get("waterDetection")
) is None:
return None
return (
value == "normal"
if data.get("waterDetectionMode") == "WaterPeak"
else value == "leak"
)
return data.get("state") in ["alert", "full"]


def is_leak_sensor_state_available(device: YoLinkDevice, data: dict) -> bool:
"""Check leak sensor state availability."""
if device.device_type == ATTR_DEVICE_MULTI_CAPS_LEAK_SENSOR:
if (
(alarms := data.get("alarm")) is not None
and isinstance(alarms, list)
and "Alert.DetectorError" in alarms
):
return False
if (alarms := data.get("alarmState")) is not None and alarms.get(
"detectorError"
) is True:
return False
return True
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.

Would it make sense to maybe split out the entity description into 2? As in, now we try to reuse the same entity description, but we have to mingle all this logic into it for it to work

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

For different models of device of the same type, using the same entity description seems more reasonable. The data differences between models are distinguished within the parse_data_leak_sensor_state and is_leak_sensor_state_available functions.

@home-assistant home-assistant Bot marked this pull request as draft December 23, 2025 12:28
@matrixd2 matrixd2 marked this pull request as ready for review December 25, 2025 08:31
@home-assistant home-assistant Bot requested a review from joostlek December 25, 2025 08:31
@joostlek joostlek merged commit 97d1c18 into home-assistant:dev Dec 29, 2025
40 checks passed
@github-actions github-actions Bot locked and limited conversation to collaborators Dec 30, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants