Add iNELS integration

[epdevlab]

Breaking change

Proposed change

Adds a core integration to communicate with iNELS devices.

Type of change

• [ ] Dependency upgrade
• [ ] Bugfix (non-breaking change which fixes an issue)
• [x] 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: https://github.com/home-assistant/home-assistant.io/pull/34659

Checklist

• [x] The code change is tested and works locally.
• [x] Local tests pass. Your PR cannot be merged unless tests pass
• [x] There is no commented out code in this PR.
• [x] I have followed the development checklist
• [x] I have followed the perfect PR recommendations
• [x] The code has been formatted using Ruff (ruff format homeassistant tests)
• [x] Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• [x] Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• [x] The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• [x] 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[bot]]

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks :+1:

Learn more about our pull request process.

[joostlek]

A lot of comments that were questions were unanswered, please do so

[epdevlab]

A lot of comments that were questions were unanswered, please do so

@joostlek Thank you for your feedback. I've gone through all the comments and believe I've addressed each one. Where changes were requested, I've either made the change or explained why a different approach was taken. Could you please point out which specific questions remain unanswered?

[joostlek]

https://github.com/home-assistant/core/pull/125595#discussion_r1754629304 https://github.com/home-assistant/core/pull/125595#discussion_r1754635230 https://github.com/home-assistant/core/pull/125595#discussion_r1754635901 https://github.com/home-assistant/core/pull/125595#discussion_r1754638122 https://github.com/home-assistant/core/pull/125595/files#r1754987932

[epdevlab]

#125595 (comment)

I apologize for the misunderstanding. When I saw my comments marked as Pending, I incorrectly assumed it meant they were pending to be addressed by the PR reviewer, rather than pending to be submitted. This led to my confusion about unanswered questions. I've now submitted all my pending comments.

[epdevlab]

Hi maintainers,

I notice this PR has been marked as "smash" @frenck . While I understand this indicates potential closing, I haven't received any feedback or review comments since submitting this PR two months ago.

When I explained why I made certain design choices, the discussion suddenly stopped and I did not receive any feedback from @joostlek

Before closing, I would greatly appreciate the opportunity to receive specific feedback on what needs to be improved. I'm ready to make any required changes.

Thank you for your time!

[frenck]

@epdevlab I think you misunderstood what the label means. It means this PR should/can be picked up soon. It is a quick pick list.

[epdevlab]

@joostlek I notice this PR was removed from milestone 2025.4.0b. Is there anything I can clarify or additional information I can provide to help with the review process?

[epdevlab]

Mind reaching out on Discord? I kinda want to get this over the line, but there's still a lot of work to go through but because of the big intervals between reviews and fixing and getting back to it, I lose track of the context (not saying who's to blame, because I am also slow sometimes). So I'd rather just have a good chat and see when we can get this through

Thanks for the offer! Let's chat on Discord to work through the remaining issues. Feel free to contact me via Discord at [lanecz].

[emontnemery]

@epdevlab please do not force push to PRs where review is ongoing, instead, merge dev to your topic branch.

[emontnemery]

@epdevlab As requested 4 days ago please DO NOT FORCE PUSH to PRs where review is ongoing!

[emontnemery]

There are unresolved review comments, I'm setting the PR to draft. Please address or reply to all unresolved review comments, then mark the PR "ready for review".

[emontnemery]

@epdevlab Why did you again force-push to the PR?

[epdevlab]

@epdevlab Why did you again force-push to the PR?

I sincerely apologize for repeatedly force-pushing to this PR despite your clear instructions. I completely overlooked your previous comments about this. I will not force-push again while this PR is under review.

[emontnemery]

@epdevlab I discussed this PR with the core team, and we really would like this integration to make use of the built in MQTT client. We generally allow integration to have their own MQTT client only when the service being integrated has its own MQTT server not managed by the user.

It's not clear to me why this would force a complete rewrite of your library, have you looked into how other integrations such as drop_connect, pglab and tasmota solve this?

For example, tasmota just passes in functions to the library which it calls to publish, subscribe and unsubscribe. I think you can do the same even if your library is not async safe, you just need to use the thread safe API exposed by the MQTT integration instead of the async safe API used by tasmota.

You're welcome to message me on Discord if you want to discuss this 👍

[epdevlab]

It's not clear to me why this would force a complete rewrite of your library

@emontnemery I think it's an oversimplification that my MQTT client can be simply "substituted" with HA's MQTT client callbacks.

There are significant interface incompatibilities:

1. Different parameters My code uses batch operations and subscribes to multiple topics at once: my_client.subscribe(["topic1", "topic2", "topic3"], qos) vs ha_client.subscribe(hass, "topic1", callback, qos)

2. Different return types The fundamental interface change is that my subscribe returns: {"topic1": "value1", "topic2": "value2", "topic3": "value3"} vs partial(self._async_remove, subscription) The key difference is that my client also returns the current device state values, which is not a subtle architectural change. This is tightly coupled because the device schema is only known at the status level - I cannot identify/create devices without that information. HA's subscribe returns a Callable (unsubscribe function).

3. Internal logic The complexity increases because my wrapper around the paho client heavily depends on low-level MQTT features that are not available in your interface. For example, error codes and Message ID tracking.

have you looked into how other integrations such as drop_connect, pglab and tasmota solve this?

Of course. They all have their own MQTT wrapper classes that use HA's MQTT client callbacks. The fundamental difference is that my wrapper performs synchronous discovery in a single step, constrained by thread conditions and timing during the initialization phase (async_setup_entry). Tasmota and pglab have a different discovery lifecycle.

You just need to use the thread safe API exposed by the MQTT integration

The issue isn't thread safety - it's interface compatibility. My InelsMqtt library would need substantial refactoring to work with HA's MQTT client, not just a simple substitution.

I'm not trying to fight you here. I just feel that since I've had my MQTT client in HACS for over 3 years, I have received substantial feedback, and no one ever mentioned having any issues with explicitly setting up MQTT. I understand the requirement, but it does seem quite restrictive, especially for the benefits it provides, and it's being introduced after I've been working on this PR for over 12 months.

We can discuss it on Discord - I agree.

[epdevlab]

Latest commits include:

• Refactor to use Home Assistant MQTT integration client
• Refactor tests

[emontnemery]

Please set the PR "ready for review" when the comments have been addressed 👍

[emontnemery]

After you added the py.typed marker, mypy found a couple of issues. For the message callback, I'd suggest to cast or ignore, since we know we always get str.