I got it to work again. I had accidentally uploaded it as alarm_control_panel.py instead of the old concord232.py
Good to hear. FWIW, I copied the built-in ones to a local copy under custom_components/concord232 and renamed them as mentioned and it seems to work fine. It fails to connect since I don’t have concord232 set up, but it attempts to use the custom ports and stuff I put into the code. So, that should work unless there is something in your custom version that requires additional stuff or it’s something that is failing after it connects.
That’s odd. The only component I have customized is the custom_components/concord232/alarn_control_panel.py. Not the custom_components/concord232/binary_sensor.py
When I try it, the dependency error I get is related to binary_sensor.py.
That’s odd. Did you copy the right version for your version of HA? I tried with the latest version on 0.89. Also see if the REQUIREMENTS = ['concord232==0.15'] at the top of each is the same version (not sure how HA handles that if they’re different). Other than that I have no clue. Maybe increase the verbosity of the logs and see if you can spot anything or just stick with the recommended approach and leave them in the paths that HA has them in since that seems to be working.
Just tried to reimplement the new file structure and this time it worked, so I must have made an error the first time around. Sorry about the confusion!!
1 Like
Phew! At least now I don’t have to re-think everything I’ve learned I thought I knew! 
You might as well accept your summary of the options as the accepted answer so others can find it in here. With the current state of things, I think people just need to read over those options and understand the pros and cons of each to decide which way to integrate their custom components.
1 Like
Gah, this change is such a headache. Fixing a bug in one file went from no big deal to an afternoon of work.
Honestly, breaking changes should have a good reason and this one does not. Custom components should always be use at your own risk affairs, if people want partial overlay let them. Why not have a config flag that toggles behavior?
Also funny that Balloob showed up at the beginning of the thread, failed to justify the change in any meaningful way, and then pieced out. Does ANYONE like this change? Just reeks of developer pedanticness for the sake of pedanticness.
While I agree that it results in additional work for little to no benefit to the user, it wasn’t without any justification. The justification was that it’s supposed to reduce the amount of effort developers, who are volunteers working in their free time, put into debugging issues that end up being a result of partial overlays. It’s a fair goal to have and is nice in theory.
The problem, however, is twofold:
First, in my opinion, it doesn’t even fully achieve the goal. There are still going to be breaking changes at the boundaries and breakages when a user tries to update their copied files. The “derivation” method has the slight advantage that it will have a custom name and be obvious to developers that the issue is in a custom component when that happens. The “redirection” method, however, doesn’t even have that and negates virtually everything the change was trying to achieve.
Second, it was probably underestimated how much effort users and volunteers making custom components and helping in the forums have to now put in to account for these changes. I think maybe it was intended to help developers since they’re volunteers (which is great), but neglected to consider these whole other groups of people who are also volunteers using their free time to help out. As nice as these alternative methods are, unfortunately, they also add to that work because we now have to help guide users, who may be less experienced, into choosing the right approach for their specific use case.
However, I doubt it will get reverted without a big push and a lot of very strong opinions. I did make the suggestion to allow custom partial overlays but require them to use a special tag, similar to Lovelace custom cards, e.g. platform: custom:mqtt. The idea was not rejected, but someone would need to take the time to work out the design and actually implement it.