Sadly, I’ve noticed in the communications the trend to focus more and more on the needs of the masses. It was, I suppose, inevitable, to make it easier for the uninitiated user to jump right in, doing everything from the UI, removing more and more from YAML config with every release. They say they won’t, but they do. I welcome some of this (because I cursed YAML when I started HA) but, for example, because the UI removes comments from YAML it edits, I can’t use it. I rely heavily on comments in the code to keep things straight, plus, as a programmer, I’m comfortable that way. Who codes without comments?
1 Like
… but you sure do have a lot to say about it. Who are you? No picture. No name. Are you a dev? On what in HA? I’m just curious from whom are we getting “advice.”
Why do you even care? Clearly you’re not going to step-up and maintain it.
I’ve been a HA user for 2 years, and this is news to me. Thanks for that tidbit. Although, granted, that custom integration is still a dead end, ultimately, right? And just because it’s been added to HACS, does that mean it will be maintained, or is this just a short term solution to installing it?
The maintence of the custom integration is now the resposibility of the person who forked and added to HACS, just like anyone they can just walk away and it will not be maintained. But any of the code in HA core will not be dependant on it or tested against.
Being a custom integration does not mean in any sense its dead end, there are many custom integrations that have been going for years.
Some devs use custom integration as a stepping stone to being added into the core or are happy for it to stay as one.
1 Like
Can i ask in this thread, what is the reluctance to running the integrations that are marked as being deprecated as custom integrations as opposed to being in HA core.
Is it that it harder to install? HACS can simplify if its in their or you can do manually and you can carry on using them as long as you wish.
Is it that it wont be maintained, because at the moment those are not anyway and if they break you are buggered as most require specific hardware to develop or diagnose against
I’m surprised you learned about it here from me because it’s been mentioned, at the very least, in the two threads that discussed the deprecation prior to the introduction of the Release Notes and in the discussion attached to the Release Notes announcement.
The difference between an official and a custom integration is:
- An official one successfully passes the development team’s vetting process and becomes incorporated into official releases of Home Assistant.
- A custom one doesn’t do any of that. It’s not vetted by anyone and isn’t included in the official release.
What the two have in common is the integration’s author maintains it and typically accepts improvements from others. If the author abandons it, unless someone else takes over, it remains static and might continue to work … unless something in its environment changes and renders it non-functional.
You can copy all of an official integration’s code into the custom_components directory, restart Home Assistant and now it will use the copy of the integration instead of the original version. You are free to modify this instance of the code to suit your needs.
I did this shortly after I started using Home Assistant, back in October 2018, when the MQTT HVAC integration didn’t meet my needs and I modified it (had to learn more than just a little bit of python to do that). Eventually, the official MQTT HVAC integration got the features I wanted so I stopped using my customized version of it.
2 Likes
You can copy all of an official integration’s code into the
custom_componentsdirectory, restart Home Assistant and now it will use the copy of the integration instead of the original version. You are free to modify this instance of the code to suit your needs.
Thanks for the clarity. A large part of success is simply knowing what is possible. This opens a world of possibilities.
Now if I could only sort out the difference between integrations, add-ons, custom-components, platforms, domains… life would be good (and before you provide a link to the architecture diagram… didn’t help 
). Cheers.
Yes I do have a lot to say, and the difference between what I say and you GPIO people is that what I say makes sense and is not the same thing over and over and over again.
None of you have made any progress what so ever in over a month, it’s still in the whining and crying state.
My kids are more reasonable!
Even when the custom component is here there is still the same crying.
You have the exact same thing, you have got the three step guide to install it, but still there is the same crying.
I don’t get it. Are you people not ever going to move on?
I was caring a few weeks ago. I felt felt sorry for you all, and wanted to help find a alternative route.
Now after all this whining and some people’s hostile comments asking for picture and name I don’t feel anything about this topic anymore.
No I will not step up and help you.
It’s clearly not possible to help a group of people that is reluctant to all changes.
Even when the change is nothing, not sure if that counts as a change then.
6 Likes
HA wants to compete with Google Home or Apple so GPIO has been removed because it’s too geeky.
No, it was deprecated because there is nobody to maintain it as part of core and will only be removed in 2022.6.
1 Like
In the day and age of excessive power costs in £ & $ it seems strange to be suggesting adding more power draw (no matter how small) for no gain. I already use ESPHOME and yes I could add an ESP to operate the fan for my Pi rack. Seems overly complex and a waste of power.
1 Like
Then shut down Home Assistant also.
It uses power also.
Can’t shutdown anymore…my button was connected to rpi gpio 
2 Likes
Yes you can… there’s a shutdown host button in the supervisor.
It uses power for a useful purpose, additional devices for something that could be done on the Pi is a waste of resources.
1 Like
There’s already a way to install rpi_gpio in HACS. Ha-rpi gpio - Home Assistant Raspberry Pi GPIO Integration | PythonRepo
Can someone tell me if any of the viable GPIO replacement options (HACS and mqtt-io) support input on the Raspberry Pi 4b with a 64-bit kernel? The inputs have never worked for me with 64-bit kernels, which as forced me to use a 32-bit kernel even on my 8GB RPi 4b (which is a waste). Are there other options I should be considering?
ESP isn’t an option for me, unfortunately, as I have a custom board built around the RPi connector and I need a UPS to guarantee that the GPIO works so don’t want to put any more load on the UPS.
Hi Porch,
any hints, how I can put MQTT IO on the same PI as my HA?
I’m already using Zigbee2MQTT, which is available as an Add-On in HA and hence was easy to install.
Thx
Matthias
Hi, in my case it does not works …
My configuration:
Operation system: Home Assistant OS 7.6
stable
supervisor: 2022.04.0
core: 2022.4.6
Python: 3.9.9
Raspberry Pi4
I coppyed whol directories “mcp23017”, “bme280” and “dht”, from relese 2022.3.8, and put to \config\custom_components, with that result:
-Platform error switch.mcp23017 - Integration ‘mcp23017’ not found.
-Platform error sensor.dht - Integration ‘dht’ not found.
-Integration error: bme280 - Integration ‘bme280’ not found.
What I did wrong? please help, at the moment I have to switch back to march version of the core …
You have to restart Home Assistant after you add a custom integration before you can use it in your config.
You’ll also need to add a version to the integration’s manifest.json if you have just copied it from the core.