improve handling of incorrect values in fyta integration

[dontinelli]

Proposed change

The FYTA server takes some time to process the data received from Beam sensors newly added to the system. While those new sensors already show up in the API, the reported values are not (yet) correct. With this PR additional tests are included to catch such incorrect values and set the entity to unavailable as long as no correct values are reported.

In fact, the PR covers the handling of possible wrong status values (a status value between 1 and 5 is expected).

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 FYTA Error: Task exception was never retrieved - PLANT_STATUS[value], #114804
• This PR is related to issue:
• Link to documentation 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. ~~
  - [ ] Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

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

[joostlek]

Wouldn't it make more sense to just replace the value_fn in the places where the value is not one of the expected ones?
Current:

        value_fn=lambda value: PLANT_STATUS[value],

        value_fn=lambda value: PLANT_STATUS.get(value),

If value is then not in PLANT_STATUS it will return None which will render as unknown

[home-assistant]

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.

[joostlek]

Oh and can you bump the dependency in a separate PR?

[dontinelli]

Wouldn't it make more sense to just replace the value_fn in the places where the value is not one of the expected ones? Current:

        value_fn=lambda value: PLANT_STATUS[value],

        value_fn=lambda value: PLANT_STATUS.get(value),

If value is then not in PLANT_STATUS it will return None which will render as unknown

I personally thought that it makes more sense to show the sensor as "unavailable", as - at least during the setup phase - there is not (yet) a correct value available. I could also live with the state being unknown. Is there a difference how it would be handled in the statistics?

[dontinelli]

Oh and can you bump the dependency in a separate PR?

Sure. I thought as it is related to the same issue (and part of the issue is solved with the bump), it would make more sense in one PR...

[joostlek]

Nope! But in HA, unavailable is usually treated as "we could not reach the device" and unknown as "we received something, but we still don't know", so I think correct is more appropriate here.

[joostlek]

It has some benefits from making it a separate PR, you can see all the changes needed to work with the new lib in one place, they are usually reviewed way quicker, and now in this case, we might have feedback on the other code, causing the whole CI to run again (and this will probably just be 1 feedback cycle, but if this happens 4 times, it kinda clogs up the CI).

[dontinelli]

It has some benefits from making it a separate PR, you can see all the changes needed to work with the new lib in one place, they are usually reviewed way quicker, and now in this case, we might have feedback on the other code, causing the whole CI to run again (and this will probably just be 1 feedback cycle, but if this happens 4 times, it kinda clogs up the CI).

done: #115143