Add integration_type device to incomfort

[joostlek]

Proposed change

Add integration type device to incomfort

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 #
• This PR is related to issue:
• Link to documentation pull request:
• Link to developer documentation pull request:
• Link to frontend pull request:

Checklist

• I understand the code I am submitting and can explain how it works.
• 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.
• Any generated code has been carefully reviewed for correctness and compliance with project standards.

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]

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

Code owner commands

Code owners of incomfort 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 incomfort 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.

[Copilot]

Pull request overview

This PR attempts to change the integration_type for the incomfort integration from "hub" to "device" in the manifest and regenerated files. However, this change is incorrect based on the integration's architecture. The InComfort integration connects to an Intergas InComfort/Intouch Lan2RF gateway that discovers and manages multiple heaters (boilers), and each heater can have multiple room thermostats. This multi-device hub architecture with a central gateway coordinating subordinate devices is the defining characteristic of integration_type "hub", not "device".

• The gateway acts as a hub discovering multiple heaters via client.heaters()
• Multiple rooms/thermostats are created for each heater
• Child devices use via_device to link back to the gateway device

Reviewed changes

Copilot reviewed 1 out of 2 changed files in this pull request and generated 1 comment.

File	Description
homeassistant/components/incomfort/manifest.json	Incorrectly changes integration_type from "hub" to "device" and reformats dhcp configuration
homeassistant/generated/integrations.json	Reflects the incorrect manifest change in the generated integration metadata

[Copilot]

The integration_type should remain "hub", not be changed to "device".

The InComfort integration connects to an Intergas InComfort/Intouch Lan2RF gateway that acts as a hub:

• The gateway discovers and manages multiple heaters/boilers (see coordinator.py line 48: heaters = await client.heaters())
• Each heater can have multiple rooms/thermostats (see climate.py lines 38-40 creating entities for each room)
• The code creates a gateway device and links child devices using via_device (see entity.py lines 31-35 and climate.py lines 74-78)

This multi-device hub architecture is the defining characteristic of integration_type "hub". The integration should remain classified as "hub" since it manages multiple subordinate devices through a central gateway.

Suggested change

	"integration_type": "device",
	"integration_type": "hub",

[zweckj]

I believe it's a hub

[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.

[jbouwh]

The gateway itself is added as a device, while there is an Mac and IP address added there is no relevant model informatie available. The gateway will add a climate and water heater entity. I would opt to choose hub for this integration.

[epenet]

The gateway itself is added as a device, while there is an Mac and IP address added there is no relevant model informatie available. The gateway will add a climate and water heater entity. I would opt to choose hub for this integration.

But if it adds only a single climate/water heater entity then it is a gateway to a single device, isn't it?

[jbouwh]

The gateway itself is added as a device, while there is an Mac and IP address added there is no relevant model informatie available. The gateway will add a climate and water heater entity. I would opt to choose hub for this integration.

But if it adds only a single climate/water heater entity then it is a gateway to a single device, isn't it?

Ìt could add multiple heaters when I look into itand multiple climates (rooms) connected to it. The climats are optional. In most cases it is one heater and one climate. The gateway provides the API to control the setpoint of the climate. The rest of the info (including the water heater) is readonly.