[Idea]: Integrate better in existing HA concepts and provide more flexibility

[Yncensus]

What problem are you trying to solve?

Hello,

I really like your integration. The dashboard card looks nice and I don't have to setup any logic to calculate mold risk myself.

Nevertheless, the setup process feels quite clunky to me. I have no experience writing HA integrations myself, so I do not know if there are any obstacles or if there is simply no other way.

What would you like HI to improve?

• Home Assistant has Areas, why implement hardcoded rooms instead of relying on them?
• Your integration has the expectation of a house with an upstairs and downstairs level. If I have a basement level I want to monitor, there is no option. If I have an appartement with only one level, it nevertheless calculates and displays a "House AVG", "Upstairs AVG", "Downstairs AVG". (The dashboard card is easy to fix, the logic behind it is not.)
• Each sensor has a state class, which could provide "temperature" and "humidity". Why do I need to set the sensor class manually in the setup process?
• I do not know if this is possible, but maybe a combination of area, sensor class and labels could be used to dynamically get the required sensors? maybe select the areas you want managed in the setup process and assign them a level?

What kind of idea is this?

Setup/configuration improvement

What area is affected?

Setup or options flow

What rooms, devices, integrations, or dashboards are affected?

No response

What should HI avoid doing?

N/A

Why would this help?

Simplify and streamline setup process.
Optional: react dynamically to changes in available sensors

Have you seen a similar issue or proposal?

No similar issue found.

Optional screenshots, examples, diagnostics, or workaround

[github-actions]

Thanks for opening your first Humidity Intelligence issue. It is good to have you here.

Humidity Intelligence is built around deterministic behaviour, environmental stability, explainable decisions, and transparent runtime truth. Useful reports help keep that standard strong.

When it fits the issue, please include:

• Home Assistant version
• Humidity Intelligence version
• diagnostics bundle or relevant diagnostic output
• screenshots, especially of the generated dashboard or reason panel
• reason panel text for the selected lane, gate, alert, or degraded state

If this is an enhancement idea, community discussion and the proposal process are the right place to shape it. Clear problems, real examples, and constructive tradeoffs help maintainers assess the idea, but discussion does not mean every idea will be accepted for implementation.

Thanks for helping make Humidity Intelligence easier to support, explain, and improve.

[senyo888]

Thanks for taking the time to write this up so clearly. This is useful feedback, especially around making Humidity Intelligence feel more natural inside an existing Home Assistant setup.

I’ve started a Bella proposal review for this so it can be looked at properly as Community Ideas & Proposals intake. That review will consider whether this should become one formal proposal or be split into smaller follow-up items around setup flow, Home Assistant-native concepts, and flexibility.

Our main consideration is to protect HI’s deterministic control model, while still looking for ways to make setup and configuration feel less clunky for real deployments.

Appreciate the thoughtful suggestion. It is now in the right review path.

[senyo888]

Quick Bella review update:

This is useful feedback and I’m keeping it in the Community Ideas & Proposals path as it is not a runtime bug or release blocker.

A few parts of the setup friction are already being improved in the v2.0.7 line: essentials-first setup, advanced tuning sections, and display-only Level 1 / Level 2 labels. That said, the broader ideas here are still valid proposal material, especially:

• using Home Assistant Areas/Labels more naturally
• reducing manual sensor-type selection where Home Assistant metadata is reliable
• supporting homes that do not fit the current two-level model
• avoiding unsafe runtime auto-discovery that could change HI decisions unexpectedly

Because these affect telemetry mapping, zone resolution, diagnostics, generated UI truth, and deterministic control behavior, I’ll keep this open for proposal review rather than infer implementation approval from the idea alone.

If this moves forward, I expect it to be split into smaller proposal items instead of one large change.

Bella

[senyo888]

@Yncensus Once again, thanks for raising this so clearly.

I’ve now taken the Home Assistant Areas/Labels part of your idea through a more detailed proposal review.

After running it through multiple house agent profile perspectives, I have conclusions that this direction does fit Humidity Intelligence, but only with a clear boundary.

I agree that HI should feel more natural inside an existing Home Assistant setup, especially where users have already spent time organising devices with Areas and Labels. The safest direction is to treat Areas and Labels as setup and diagnostics assistance: helping suggest rooms, group candidate sensors, filter possible outputs, and make configuration less repetitive.

What I do not want to do is make Areas or Labels silently control runtime behaviour. HI’s core model still needs to stay explicit and deterministic. Saved telemetry, room, level, zone, output, AQ, humidifier, and alert mappings remain the source of truth. A change to a Home Assistant Area or Label cannot unexpectedly change which lane runs or which output is controlled.

So I have begun putting together a proposal, which is likely to take this shape:

• use Areas and Labels as read-only discovery/setup assistance
• allow users to accept suggestions into explicit HI configuration
• keep runtime lane selection unchanged
• keep generated UI tied to backend HI truth only
• add diagnostics warnings where HA metadata and saved HI mappings appear inconsistent
• split wider topology flexibility, such as basement, single-level, or more-than-two-level homes, into a separate proposal

This idea is strong enough to become a bounded implementation-ready proposal, and I’ll keep you informed of its progress.

I’m going to keep this open in the proposal-review path and use it as the public reference for the Areas/Labels discovery-assist direction.

@senyo888