My HAT doesn’t have an integrated fan…
It’s not the official HAT, but one I bought on Ali…
I think the official HAT is 802.3af (PoE) only. But if you look around you can find that are 802.3at (PoE+) HATs as well and I never had any problem with the one I bought…
In never have any cooling problems, ass my RPi ‘box’ is open to sides for natural airflow. No fan is needed. Somehow all fans seem to make noise after a while…
I had to respond to you. I hope you are not getting too frustrated with this current back and forth! You are always so helpful to the community and I hope you don’t lose your enthusiasm.
This argument that is on going is already fixed. People using gpio, can’t understand how to install HACS makes no sense?
I am not understanding what people are hoping to gain by continuing it? There are always changes that will be made that will effect someone. That is the complications of software. I have had several integrations over the last couple of years that were depreciated. I understand this happens. I wasn’t happy at the time, But I figured out what I needed to do and moved on.
First, I’m OK with the solutions which have been presented, and I have been aware of this issue since it first hit this forum however many months ago. While I still don’t agree with the decision, the workaround we have today is trivial to implement, so challenging that decision is not productive for me.
But, your question is a good one, in relation to the thoughtful post by @Jared_Heath. What exactly could have been done better?
Hindsight is 20-20, and I’m not suggesting anyone did anything “wrong.” Just that, with what we know now, things could have been done differently.
With that long preamble (I’m trying to avoid the pitchforks), Here’s one humble suggestion:
What if, after the decision was made to remove GPIO support from the core, a message went out, first in the Dev forum and then here and wherever else might be appropriate, that the Dev Team is looking for someone to take over an “orphaned” component so it wouldn’t be abandoned?
As it turned out, that’s exactly what happened, but only after a lot of unpleasantness. I’m simply suggesting there may have been a way to avoid a lot of that rancor.
I’m guessing you didn’t read thecodes response? A message went out and no one picked it up, so he did.
I guess I should have actually gone there last night, but I was laying in bed and didn’t consider it.
I think the earlier response by CaptTom might be an approach that would keep the pitchforks in the garages. After all, isn’t that what we all want? None of the users want to feel like they are being screwed. None of the devs wants to be yelled at. None of the moderators want to deal with the board tension.
I don’t think its an issue of removing GPIO. I think its an issue of removing it in the way it was removed. This is probably true of everything being removed…it comes at the very end of the release notes and at times comes across as an after-thought to the user community. I think this is where the communication can improve. If you just add a little finesse to the way these types of things are communicated, then the community has a chance to come together in a healthy non-adversarial (from everyone’s angle) way.
And it does seem it all came together in the end. The bumps in the road to the finish line are really where the focus should be. How do the user/mod/dev communities smooth out this bumps when big changes are in play?
I don’t have the answers. I do know that the community would improve if everyone involved in the process tried to smooth these bumps.
Hi, I‘m also unhappy that GPIO support will end soon. I can understand the developer point of view, since maintenance seems to need a lot of time.
To my mind the Raspberry Pi platform offers a lot of functionality by the GPIO ports. So if the direct GPIO support will be dropped there is a need for an alternative. Maybe APIs like SPI, 1-wire & others can be replaced by server software that listenes on a specific network port. This abstraction layer might be easier to support.
E.g. for 1-wire the owserver/ofws package could solve the problem. But I did not find a documentation hoe to install owserver on the Pi (How to install owserver? 1-wire and Home Assistant OS).
I hope there will be a solution that allows to user the GPIO ports in future that is easier to maintain.
To be honest, no, I did not see a message indicating that a developer was needed to step forward and avoid having this integration abandoned. At least not before the decision was made to deprecate it and, ultimately, abandon it. If that took place then I’m afraid I missed it.
From what I saw, it was after the decision had already been made that the discussions about it began here. And it was after that when the official notice appeared in the Release Notes. That brought a lot more people into the discussion. Even then, that discussion went on for a while (with much negative energy being expended) before someone stepped in and took it on. (With my unqualified gratitude!)
Here’s the exact text from the Release Notes:
As of this release, all integrations interfacing with GPIO directly, have been deprecated.
There are multiple reasons for this, which includes a general low usage of these integrations. For most Home Assistant installations, GPIO isn’t easily usable and more often the integrations are unmaintained.
There was a note near the end which said:
We welcome custom integrations (existing or new ones) to provide alternatives.
This doesn’t come across as “we want to keep supporting this but need someone to take it over.”
My point was that this last step, announcing that someone was needed to take over support so it wouldn’t have to be abandoned, could have been the first step, before the decision was made, and before anyone (justifiably or not) got upset over it.
I’m only posting here to try to lower the temperature a bit and move the discussion toward ways to avoid this sort of thing in the future. I’m sure we can all agree that keeping this forum civil would be a good thing.
Looking at the device in question, gpio is not needed for it to operate. gpio can be used to flash some leds.
It was no mystery to any dev that it was being removed. You can see his response here:
While it wasn’t a formal “we are looking for people”, people definitely knew it was being removed prior to the decision and no one else stepped up. Even after this kerfuffle, no one has stepped up to pick up the other GPIO integrations. This outrage timeline would be no different.
Just look at ZWave 1.4. It’s been stagnant for ~4 years and deprecated for over a year now. People still haven’t switched and they still believe that this was the developers decision, even though it was the communities decision to move to zwave js. There is no advantage to announcing early, people will still be upset.
Would it be possible for the devs to push an integration specific message (think update notification) to all HA instances using the particular integration? Obviously the message would only go to those that have analytics turned on and have reported using the integration in question.
My thought is that the push message in a case like this deprecation could link to the HA website with specific information about time-frame, steps needed to rectify and so on, or could even be sent out prior to the fact as a warning message.
If this is possible it could eliminate some of the “I had no idea” comments and associated backlash.
The people screaming about this probably have analytics off and/or would be outraged that HA is ‘spying’ on them…
Well nice idea, but I imagine the tinfoil hat wearers would be resistant to that. I think probably justifiably. Isn’t analytics supposed to be anonymous?
@DavidFW1960 beat me to it.
Yeah, I get that, but if you want the info, turn on analytics. The same people probably browse the web all day long without a VPN, so…
I believe so, but the devs wouldn’t need to know who is running the integration as such, just that 895 people are, so send them a message - in the same way they know which HA instances to send an update message too. Perhaps it’s no doable due to the privacy aspect.
I’ve never had a problem participating in analytics. It indirectly helps make HA better I think and I don’t get the obsession over privacy for this.
I don’t believe update notifications are pushed to users. HA checks a url and works out if it needs to update.
Perhaps though an infrastructure where HA checks for messages about the integrations it is running.
ahh, yeah, you’re probably right.
Perhaps integrations could check for updates in the same way as HA updates and add-on store items do?
Speaking of which, this deprecation should be there surely?
Regarding some comments on my previous post, I did get two custom components working in my system soon after I read the release notes to prepare for the removal of the integrations. For the GPIO I saw that a developer made one available before I worked on mine (thanks so much to @thecode for the quick solution for the community!!), it required some tweaks, and for the DHT sensor it was pretty much straightforward, just need to include a version number.
My fear, I insist, are the libraries needed for them to work. For example, RPi.GPIO for both GPIO and DHT integrations, and adafruit-circuitpython-dht and libgpiod for DHT. This last one required a pretty recent change in the dockerfile before it was functional. Right now the custom components work just fine, but if someone decides to clean up libraries that are from deprecated integrations, we’ll definitely lose the possibility to use them. Hopefully the developers will keep them in for the users that still rely on GPIOs for their home automation solutions (in my case all types of sensors and switches), Raspberry Pi fans, HATs, etc.