I have the benefit of having seen (and participated in) Tasmota very near the beginning and seeing the upstart that Home Assistant was some time later and the start of esphome.
All of them have changed dramatically in the last decade or so, but the roots are still evident if you look closely.
The project’s issue tracker is the right place for questions on core initialization order, especially since your networking premise is sound. Overriding the MAC works for identical hardware if you set the locally administered bit, and hostnames are required for mDNS discovery.
Should this issue be submitted as a bug or a feature request? I submitted a feature request to allow lambdas for the mac_address: yaml key but it seems to have fallen into the bit bucket.
However, a recent bugfix to honor efuse programmed mac addresses across all network interfaces seems directly relevant. I would have commented on this to point out that such efuse programmed addresses aren’t limited to ESP devices. But since the PR that thread discussed has been merged comments are locked out.
So, LSS on this specific issue, what would be the most effective way to proceed?
Regarding the general usability issue that launched the OP, I’m going to start with some light: specific proposals (since that what prompted things initially) and work from there.
Both, and they are two separate filings.
The PR you mean is esphome/esphome#18452, “[esp32] Apply custom eFuse MAC as base MAC for all interfaces”, merged on 26 August. It is locked, so a comment there would have reached nobody. Open a new issue and link it; the backlink shows up on the PR.
If that merged behaviour does not do what it says on a board you have, that is a bug, and it goes in esphome/esphome through the bug report template. Blank issues are switched off there, so the template is the only way in.
If the point is the broader one, that eFuse-programmed addresses are not an ESP speciality, that is a feature request. Those no longer go to the esphome/feature-requests tracker. The issue template config points them at esphome · Discussions · GitHub. That is the likely fate of your mac_address lambda request: the newest issue in the old tracker is from 30 August, while the main repo takes several a day.
In case you haven’t found it yet, Discord is where most of the ESPHome Devs spend a lot more time online.
I suspect if you summarised your list and started a thread under general-support it would get read by a few key Devs and you would get some good comments. They could help advise if new change requests are worth raising.
(Edit: reading more posts, I see this has been mentioned already)
In case you didn’t find it yet, most doc pages have a link to the api docs at the bottom, which can be handy when you hit uncertainties, but does mean digging into source code.
Thanks for the advice and pointers. Based on your input support for off-MCU chip ROM based mac addresses seems to clearly be a feature request so I’ll follow that path.
The twisty little maze of passages does seem to apply somewhat to finding the right place for RFCs vs. general discussion vs. formal submissions. After being pointed at Discord a few posts back I found what seemed like the “right” place but I think it was more of a real-time conversation locus than a “Post a thread” spot. In fairness I think this is pilot error so I’ll redouble my research. Maybe I can try to cut my teeth with a documentation PR to make the path clearer:-)
Re: Research, I did begin looking through the code to see if there might be a way to do what I want without having to create a new branch. That’s definitely drinking through a firehose however:-)
This is a bottleneck to getting better documentation. I site my experience. I have recommended changes and 100% of these recommendations have been ignored. Only when I spent hours and became fully immersed in the documentation of the documentation and presented an MD, which was a copy of the original MD with my edits, did the change get effected.
I am of the opinion that the person responsible for the code is also responsible for the documentation. The number of problems with code is inversely proportional to the quality of the docs. Often times just writing the documentation will highlight areas where the code can, and should be, improved. I’m as lazy as the next person, but when I write my documentation first ( :o perish the thought!), my code is better and implemented sooner.
Opensource is not an excuse for not having adequate documentation. For opensource, to be truly open source, the documentation has to be very good.
The problem with discord discussions is that resolutions rarely get translated into the docs.
(I stand down from my soap box)
I assume that MD means Markdown (i.e. the source)?
In one sense the problem you describe is understandable since it’s a lot easier (and more reliable) to merge or tweak a PR than wordsmith a tangled doc. OTOH, figuring out how to restructure something, even with very specific input, is a lot of work. Writing well is very difficult (at least for me) because good writing makes complicated things easy to understand and that’s what I expect of myself. At one point in the Feynman Lectures he describes working for days to answer a particular question he’d been asked that he thought he understood just to conclude that if it was that hard to explain then he must not really understand it himself.
Since I made my OP I’ve seen lots of places where the docs have made serious (and sometimes successful) attempts to concisely describe complicated stuff and point out important corner cases. I think the light: platform and docs do suffer from serious technical debt because it’s probably one of the oldest parts of both HA and ESPHome. So maybe that’s a good place for me to focus for now to contribute something worthy of the maintainers attention.