[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

[Dorikumi]

+1
This issue mentions a lot of things i also want to mention.
Unfortunately there is a lot of text with not so much useful information and i see no result.
Whats is a Bella proposal review?

I prefer the human like discussions in older issues :-)

[senyo888]

@Dorikumi, Thanks for the feedback. The Bella review is simply an internal check I use to make sure proposals fit Humidity Intelligence’s current direction.
Issue #66 has already led to several changes. Since v2.0.8, Home Assistant Areas and Labels can suggest room and level mappings during setup, while diagnostics can highlight missing or conflicting metadata. This has made configuration simpler and easier to adopt.
There is still more to do, which is why I have kept the proposal open for community ideas and direction. I haven’t yet addressed sensor type suggestions, or broader automatic discovery, as these would benefit from more real world examples before we settle on one flexible approach.
I do like the idea of single level, basement, split level, and multi level homes however this will need to follow once the discovery approach is settled. I don’t want to overcomplicate configuration while we are actively trying to simplify it.
The issue forms and labels help me identify bugs, proposals, and missing information as the community grows. I know the process will not suit everyone, but my intent is to use it as a supporting structure rather than a human interaction replacement. I’ll keep #66 open for any ideas on how best to implement sensor type suggestions or broader automatic entity discovery -without weakening humidity intelligence or a total redesign. My biggest concern is currently, Humidity Intelligence uses explicitly saved mappings as its source, whilst Areas and Labels only provide suggestions. If broader discovery were to be automatic, changes elsewhere in Home Assistant could indirectly affect what HI monitors and how it makes decisions. So future discovery feature needs a better solutions to preserve deterministic behaviour.

@senyo888

[Dorikumi]

I haven’t yet addressed sensor type suggestions, or broader automatic discovery, as these would benefit from more real world examples before we settle on one flexible approach.
If i select a temperature/humidity sensor, fill in the sensor type rather than asking.
If i add a temp/humidity sensor and the device has the other on etoo, propose to add it/fill it in for me to press ok.

use Areas and Labels as read-only discovery/setup assistance
allow users to accept suggestions into explicit HI configuration

There is a list of kitchen, living room, ... which i dont know from where it comes, cant find it in the language file. I wanted my non english rooms, so i used only custom.
I would prefer to see a list of my areas to choose from. Show me the matching sensors and let me choose, which i want to use, ideally several of them without selecting the area each time.
Only show appropriate sensors (t/h/number helpers/...).

[renarena]

regarding the cards - you need to use the action/service
humidity_intelligence.dump_cards or
humidity_intelligence.view_cards (cannot see a difference)
which creates the card yaml in config/humidity_intelligence/ui