Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable multiple sensors for 411i Max #65

Open
musicjeremy opened this issue Jan 12, 2024 · 3 comments
Open

Enable multiple sensors for 411i Max #65

musicjeremy opened this issue Jan 12, 2024 · 3 comments
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed

Comments

@musicjeremy
Copy link

A number of items are not showing up on my 411i Max models. I would be happy to provide info/data dumps to help you make these features work.

Snag_dff98d1

@dahlb dahlb added enhancement New feature or request help wanted Extra attention is needed good first issue Good for newcomers labels Jan 13, 2024
@nickwest
Copy link

I also have a 411i Max and see similar results as @musicjeremy. However, I'm fairly sure the 411i Max only has a PM 2.5 sensor in it. In the Blueair app I also only see PM 2.5 readings. I believe this is functioning as expected.

I think the only integration improvement would be to hide/disable those sensors if the model is 411i Max. If it helps, the device SKU of the 411i Max is 110057.

Great integration, works well!

@jonathanrobichaud4
Copy link
Contributor

@nickwest is correct. There's only PM2.5 for the 411i Max. The only reason these sensors are showing up is because they are available on the models the integration was originally written for. I just went into the the entities and disabled them which works well enough. Model handling could be implemented to make sure these entities only show up on supported models but as it is right now it doesn't break anything plus it would be hard to test.

@dahlb
Copy link
Owner

dahlb commented Mar 21, 2024

those entities were intentionally marked unavailable because the device doesn't support them. That is the only way I know to handle which devices support which entities dynamically. I think duck typing is much more resilient then maintaining a comprehensive list of which models support which entities.

we could try to affect the disabled status but the methods are under a warning

    # DO NOT OVERWRITE
    # These properties and methods are either managed by Home Assistant or they
    # are used to perform a very specific function. Overwriting these may
    # produce undesirable effects in the entity's operation.

so I've only make the availability dynamic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants