custom-components
Make zaptec an official HA integration?
Currently the zaptec integration is distributed via the HACS framework.
Would it be interesting to have zaptec as an official HA integration? I'd like to hear from the people that are using the integration. Migrating the zaptec integration from a HACS installable integration into a official HA integration will require considerable efforts. There is no point in doing it unless there is a need and would benefit our users.
What do you think? Is using HACS for this repo a burden for making use of zaptec?
For me personally it is not really an extra burden to use Zaptec integration via HACS, but I think that if the integration becomes part of HA OS it will work even more reliably than it is now. After all, your integration does not need HACS anymore.
would be nice, but even nicer if the load balancer would also be able to balance multiple chargers at once. I see the last commit there was more then 9 months ago :(
Currently the zaptec integration is distributed via the HACS framework.
Would it be interesting to have zaptec as an official HA integration? I'd like to hear from the people that are using the integration. Migrating the zaptec integration from a HACS installable integration into a official HA integration will require considerable efforts. There is no point in doing it unless there is a need and would benefit our users.
What do you think? Is using HACS for this repo a burden for making use of zaptec?
What are the addiotional efforts?
What are the addiotional efforts?
- The Zaptec api itself must be separated out to a separate package on pypi
- The coding standard must be updated to fulfil the Home Assistant quality scale
- A series of PRs adding the Zaptec integration into ha-core. Here there is a convention to adding only one feature or file at a time, in order to make the changes small enough to be reviewable. So there will be many PRs and it will be waiting on collaborators able to approve.
More info here: https://developers.home-assistant.io/docs/creating_component_code_review
@sveinse Considering the huge amount of work that needs to be put into making the zaptec integration part of HA, I now also wonder if it is worth it. Will the adjustment and/or expansion of the integration remain as flexible as it is now, or will it become a sluggish process if it has to be approved by many collaborators first. Decisions, decisions, decisions.
I would think that making it an official integration would make it accessible to more users, both from a discoverability standpoint, but also with trust or status, or whatever you want to call it. It seems to require quite some work, but wouldn't that sort of standardization also make it easier for others to contribute down the road?
I think there are two prerequisites for moving this integration into official HA: 1) Resources that have the capacity to do the work and 2) Sufficient drive and and enthusiasm from the community using it. I'm not convinced we have either.
@c0mplex1 Will the adjustment and/or expansion of the integration remain as flexible as it is now, or will it become a sluggish process if it has to be approved by many collaborators first. Decisions, decisions, decisions.
It will definitely be much more red tape to have changes implemented, so that's a big plus for keeping it as it is now. The flip side of that coin is that it is basically only me (@sveinse) and @Hellowlol that are on this project, so the development of Zaptec is going as fast as we are able to donate time to this.
I think the conclusion is not to go for HA integration for now. We need a more active community to be able to drive such an effort. Closing this issue.
@steinmn
I'd like to re-raise this question with you after contributing a lot to zaptec: How keen are we to (support) migrate zaptec and make it into an official HA core integration? After being approached by Zaptec with respect to the fair use policy, I've also been contacted by ppl. from the HA foundation which is suggesting that there are upsides to having it a part official HA. E.g. the version conflicts will also go away.
But I'm not in a position where I'm able to run this all by myself, so I need someone to coop the migration if we are to do that.
What do you think?
While I'm not in a position to commit to any kind of timeline, I do think of a core integration as a logical goal to be working towards. Thinking of starting PRs to core seems extremely premature at the moment, but to keep HA quality standards and principles as the basis for design choices and prioritization as I think (hope?) we have been doing lately is a direction I like, and one I would like to continue to contribute to.
What kind of contact have you had with the HA foundation? Would it make sense to ask them for some high level pointers on what topics we should address that aren't already covered by the issue list? And/or some tips to kickstart the test-setup we know is probably our biggest deficiency at the moment.
Starting a PR for core integration right now was definitely not on my mind. If we do plan to do so, there are a lot of things we have to do to get there first. Those things happen to be aligned with the journey that we're on, so its not like its a completely different direction for us. It just sets the long term aspirations.
One such thing that comes with migration to core is that the API interface parts must be siphoned off to a separate and official package on pypi. I have been toying with the idea to start that work. We could use this even without deciding to migrate to core. It has some pros and some cons.
As for the contact from HA foundation: This was about how to discuss how to deal with the policy from Zaptec vs the policy from HA, with things like that poll intervals and the special coordinators. I got some guidance on how to set this up in a HA-compliant-like manner. I believe the biggest upside of being included into core, is the access to all the people that knows HA very well.
I have, and I'm sure you have too, spent a lot of time figuring out how things are wired together in HA. Since our community is small, I've wished many times for having access to more eyes to our PRs. Especially from the HA world, which is so complex and ever evolving. I've dreamt about it existing some kind of HA-service for reviews. I think that's what you get from being in core.
...or perhaps this is a pipe dream. Being in core is not as collaborative as I think it is. That is still puts the same weight on the maintainers as an independent integration.
Yeah, I think we are on the same page when it comes to what makes sense going forward. We have lots of code quality/restructuring issues planned already, once those are all squared away it might be a good time to revisit the core-or-not-discussion.
One such thing that comes with migration to core is that the API interface parts must be siphoned off to a separate and official package on pypi. I have been toying with the idea to start that work. We could use this even without deciding to migrate to core. It has some pros and some cons.
Other than having to keep track of two different repos, I really don't have a good grasp on what the pros and cons of splitting out a pypi-package is. Maybe it would be good to create a separate issue on this, if nothing else just to have an overview of what it would entail? For the time being, I think #257 is a good addition regardless of whether we go for the pypi-approach or not.
Yes, #257 is a stepping stone for that - regardless if we chose to do it or not.