I don’t recall having to pass a proficiency test when I created my GitHub account. Good thing too because I am not a software developer but I can, and have, participated in Issues and Pull Requests.
The primary difference from the community forum is that anything posted in an Issue, especially in a PR, has to be very on-topic because it’s part of an in-progress workflow.
The Architecture discussions allow for more leeway with the understanding being that it’s not like Feature Requests where anyone can ask for something without having the skills to implement it. The Architecture repo is where a developer goes to brainstorm with peers and get approval to proceed with implementing a proposal (then it must pass the PR vetting process).
I understand, and I agree. However letting a vocal minority spew lies to bolster their narrative is not good for any community. Just look at Facebook and how it handles its echo chambers. This is what we are trying to avoid, wrong information based on feelings, not facts.
If the 2022.6 update means one wire and gpio are deprecated how are we able get these important features working as it is so energy efficient. Using the gpio of a raspberry pi is one of the most useful features for incorporating external sensors and switches etc. no need of esp wireless devices.
Thank you for the effort to keep GPIOs active.
I take advantage of your statement and ask you if you can also integrate the “I2C” function of RPI. I use this protocol a lot and had DHT and several MCP23017s connected.
And, statistics aside, not just the only one who uses it in the community.
They’ll be removed in that release; they are deprecated as of the current release.
As for your question, the answer is already posted in several places in this community forum including in the Release Notes. All you have to do is read them. I suggest you start with this one (which has already been posted within this thread):
I have a question for you: Which one of the deprecated integrations are you currently using?
Yes basically this is the concept of decentralization. Of course no system is totally protected against elements falling out, but decentralizing can help.
Although not every microcontroller will be capable of performing the actions you like. For instance, you can start your heating system from multiple rooms with a relay with wires to your central heating furnace, but that would be quite inconvenient for most people and dependant on your heater if it will even be possible to run multiple wires to it. But it is definitely something to think about in the design.
While active maintainer is mentioned as major reason of depreciation, If I were you I would like to know what does the active maintainer mean. Is it true that every time the maintainer left the party HA looses another integration? Or we can expect shuffling integrations in and out? really?
Once it gets core it’s core and should be maintained as the core by core devs. Especially since I expect the only changes needed are related to core evolution so all components requires the same changes.
But there is also another flaw unveiled. Modularity. For some reason the same integration can be maintained being HACS module. So there must be something wrong with the concept of maintaining integrations as a part of the core.
The modularity given by HACS seems to be superior comparing to core integrations. HA management should consider moving toward this way of integration.
First thing I done on installing was to disable telemetry. Given the option it one if the first things I do on any installation of any software. So any integrations I have aren’t listed.
Would be an interesting study to see how many people do/don’t use telemetry.
And how would you do that if you don"t even share basic analytics?
As you noticed, there are 3 “levels” of analytics.
If you don’t want the world (potentially) knowing what integrations you use, just enabling “basic” would at least let know you exist, and by correlation indicate that you specifically don’t want to share more in-depth details.
Not entirely up to ludeeus is it? He has chosen a license which enables it to be shifted into core if someone wants to do that. The repercussions of shifting it against opposition from the author may result in him going home, but he can’t take the ball with him. (Note, I am not in favour of that scenario).
HACS model of pinging each and every github repos by each and every HA user is not sustainable in the long-run, anyway
Whatever replacing it in core would use a list built, e.g., every hour by a single job on a single machine, then uploaded, then downloaded by each and every user.
Gone will be the issue of “too many requests”.
They ARE doing that. A few years ago, openzwave. integrated in the core, provided Z-Wave suncionality. now zwavejs and zwavejs2mqtt, separate modules, provide this functionality/
I’m not saying core integrations should be moved to HACS. I meant that architecture of maintaining integrations all together with core is very limiting. (see other threads/ FRs about allowing independent upgrades of components)
For openzwave both were in core, i left because i got tired of “hacking” the config file from core to add support for my devices. HA wa using a Python based version of OZW that was not current. I left to a different platform & returned about a year ago using zwavejs2mqtt. There is no specific integration for that. It uses the zwavejs one but the configuration, etc. are separate from HA, unlike the old one,
