Add support for raw sensor data to take different data types #145070

FredrikM97 · 2025-05-16T18:26:02Z

Proposed change

I have a sensor that provides a list of objects representing data from my pet feeder. However, the current implementation only supports ElectricityTypeData as the allowed TypeData for raw input. If no subkey is specified, the data is skipped and the sensor state becomes unknown. Additionally, ElectricityTypeData is not capable of decoding the pet feeder's data format. Therefore, a more flexible and extensible implementation is necessary to support custom data types like the pet feeder.

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

This PR fixes or closes issue: fixes Tuya sensor not display RAW values #144745
This PR is related to issue:
Link to documentation pull request:
Link to developer documentation pull request:
Link to frontend pull request:

Checklist

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.

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

Documentation added/updated for www.home-assistant.io

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:

I have reviewed two other open pull requests in this repository.

home-assistant · 2025-05-16T18:26:09Z

Hey there @tuya, @zlinoliver, mind taking a look at this pull request as it has been labeled with an integration (tuya) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of tuya can trigger bot actions by commenting:

@home-assistant close Closes the pull request.
@home-assistant rename Awesome new title Renames the pull request.
@home-assistant reopen Reopen the pull request.
@home-assistant unassign tuya Removes the current integration label and assignees on the pull request, add the integration domain after the command.
@home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.
@home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.

davidrapan

Hi @FredrikM97, and fix change type selection 😋

homeassistant/components/tuya/sensor.py

FredrikM97 · 2025-05-17T11:40:12Z

Hi @FredrikM97, and fix change type selection 😋

@davidrapan What do you mean?

FredrikM97 · 2025-07-01T14:47:39Z

Updated to be better backwards compatible (default to ElectricityTypeData) and also fixed the type for the native_value.

epenet · 2025-07-09T07:06:01Z

I would suggest as a preliminary PR to add a fixture files with your pet feeder details.
Then this PR will be showing how "new" information gets automatically added to the tests.

download the json diagnostics
extract the data content from the diagnostics
remove the homeassistant sub-section from the data
save as tests/components/tuya/fixtures/{category}_{description}.json
add the file to DEVICE_MOCKS in tests/components/tuya/__init__.py
run pytest tests/components/tuya --snapshot-update to update the snapshot files

(see #148401 as a sample)

FredrikM97 · 2025-07-09T09:41:24Z

I would suggest as a preliminary PR to add a fixture files with your pet feeder details. Then this PR will be showing how "new" information gets automatically added to the tests.

download the json diagnostics

extract the data content from the diagnostics

remove the homeassistant sub-section from the data

save as tests/components/tuya/fixtures/{category}_{description}.json

add the file to DEVICE_MOCKS in tests/components/tuya/__init__.py

run pytest tests/components/tuya --snapshot-update to update the snapshot files

(see #148401 as a sample)

@epenet I could split the sensor code (meal_plan) to another PR instead. The main focus in this PR is to solve the RAW base64 and not force it to be a ElectricityTypeData.

epenet · 2025-07-09T09:48:18Z

@epenet I could split the sensor code (meal_plan) to another PR instead. The main focus in this PR is to solve the RAW base64 and not force it to be a ElectricityTypeData.

For sure everything that can be done in a separate PR is best

FredrikM97 · 2025-07-09T09:51:16Z

@epenet I've now separated it so that this PR focuses solely on allowing RAW data to be types other than ElectricityTypeData.

tests/components/tuya/test_entity.py

epenet

Conflicts need resolving

home-assistant · 2025-07-16T08:40:10Z

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.

homeassistant/components/tuya/sensor.py

…eData to keep backwards compability

epenet · 2025-07-20T07:48:49Z

homeassistant/components/tuya/models.py

+    @classmethod
+    def from_raw(cls, data: str) -> Self:
+        """Return a RawTypeData object."""
+        return cls(raw=data)


Would it not make sense to decode it with base64.b64decode?

Preffered but high risk to hit the 256 limit. Maybe later if subtype is needed it make sense to decode it.

Then I fail to see the value of the current base64 string.

Please adjust the PR description to highlight how it may be useful.
A sensor "just because it's available" is not generally approved unless there is a valid scenario.

Here is an example of usage https://github.com/FredrikM97/mealplan-card

Overall it feels wrong to force raw or json types to by ElectricityTypeData

If that is the case then it sounds reasonable to use a service if possible. Still think we should change the ElectricityTypeData somehow to be more generic.

I agree - but I'm not sure if that will be approved if there is no other BaseType (that is why I suggested exposing other sensors)

What about keeping base class and separate the Mealplan to a service? Then it will be easier for future to add new typeData for raw/json.

If you have an idea how to expose a list of sensors for up to 10 schedules without overcomplicate it I'm all ears.

I don't think you need to add all schedules...
But maybe showing four sensors has value:

Total schedules: 5

Active schedules: 2

Today feed amount: 15 g

Weekly feel amount: 150 g

How do we decide what fields exist? If you check the Mealplan card there is profiles depending on device. Since base64 does not map the same for all devices. Can't come up with a good workaround for that.

homeassistant/components/tuya/models.py

tests/components/tuya/test_sensor.py

home-assistant bot added cla-signed integration: tuya new-feature Quality Scale: No score labels May 16, 2025

davidrapan reviewed May 16, 2025

View reviewed changes

homeassistant/components/tuya/sensor.py Outdated Show resolved Hide resolved

FredrikM97 mentioned this pull request Jul 9, 2025

Add entities to tuya pet feeder (cwwsq) #144835

Closed

19 tasks

epenet reviewed Jul 10, 2025

View reviewed changes

tests/components/tuya/test_entity.py Outdated Show resolved Hide resolved

epenet reviewed Jul 10, 2025

View reviewed changes

tests/components/tuya/test_entity.py Outdated Show resolved Hide resolved

epenet requested changes Jul 16, 2025

View reviewed changes

home-assistant bot marked this pull request as draft July 16, 2025 08:40

epenet reviewed Jul 16, 2025

View reviewed changes

homeassistant/components/tuya/sensor.py Outdated Show resolved Hide resolved

epenet reviewed Jul 16, 2025

View reviewed changes

homeassistant/components/tuya/sensor.py Outdated Show resolved Hide resolved

FredrikM97 added 6 commits July 17, 2025 11:25

Add support for raw sensor data to take different data types

fb12380

fix: In case of long base64 dont decode and default to ElectricityTyp…

c4ca160

…eData to keep backwards compability

fix: Correct type to be BaseTypeData

60daee7

fix: Rename mealplan to more generic and add tests and fix ruff/mypy

600fe91

fix: Remove meal_plan and separate it to another PR

0c89588

fix: Added meal_plan and tests

073a73e

FredrikM97 force-pushed the tuya_support_different_raw_sensor_data_types branch from 6626098 to 073a73e Compare July 17, 2025 16:02

FredrikM97 added 2 commits July 17, 2025 16:05

fix undo changes

23af317

Check raw_type then check subkey

629ee0c

FredrikM97 marked this pull request as ready for review July 19, 2025 19:26

home-assistant bot requested a review from epenet July 19, 2025 19:26

epenet requested changes Jul 20, 2025

View reviewed changes

home-assistant bot marked this pull request as draft July 20, 2025 07:51

Remove redundant code

c8478dc

FredrikM97 mentioned this pull request Jul 31, 2025

Make Tuya complex type handling explicit #149677

Merged

19 tasks

FredrikM97 closed this Sep 2, 2025

github-actions bot locked and limited conversation to collaborators Sep 3, 2025

Uh oh!

Add support for raw sensor data to take different data types #145070

Add support for raw sensor data to take different data types #145070

Uh oh!

Conversation

FredrikM97 commented May 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Proposed change

Type of change

Additional information

Checklist

Uh oh!

home-assistant bot commented May 16, 2025

Uh oh!

davidrapan left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

FredrikM97 commented May 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

FredrikM97 commented Jul 1, 2025

Uh oh!

epenet commented Jul 9, 2025

Uh oh!

FredrikM97 commented Jul 9, 2025

Uh oh!

epenet commented Jul 9, 2025

Uh oh!

FredrikM97 commented Jul 9, 2025

Uh oh!

Uh oh!

Uh oh!

epenet left a comment

Choose a reason for hiding this comment

Uh oh!

home-assistant bot commented Jul 16, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

FredrikM97 Jul 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epenet Jul 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

FredrikM97 commented May 16, 2025 •

edited

Loading

davidrapan left a comment •

edited

Loading

FredrikM97 commented May 17, 2025 •

edited

Loading

FredrikM97 Jul 20, 2025 •

edited

Loading

epenet Jul 21, 2025 •

edited

Loading