Actually i already placed my mindset but just an example given ...
Some programmer decided to make varibles like mqtt_clientcomponent_id or wifi_wificomponent_id static because it might safe 200 Bytes of program memory (if even). WHO HAS ENTITLED him to FELL SUCH DECISION ?
There has to be a huge sandbox and EVERY "developer" has to have his clever changes being APPROVED or DENIED. QA ... no assurance - no quality.
Oh asking about "unversal" Modbus driver. How about devices requiring different CRC, special interdigit timeouts, Echoing behaviour. Custom implementations easily gave a way to circumway inavailiablitites of short sighted programmers or lacking, incomplete or misdesigned standard modules ... Years ago the Modbus driver was absolut %&(/%&786234 but even now it is just covering some 90% of user requirements and for the rest it means - code by yourself !
As long as there is no QA for the (really good work of the most) programmers i will definitely not change my opinion and rather code in native esp-idf using MQTT and forget about the buggy rest.
Nono - that thread is HA related - don't worry. Bugs and problems referred are duie to changes in the "HA ecosystem" changed every once in a while with good und unknown reasons. I do love HA but i am no longer willing to be subject of "improvements" that have always been backdraws actually !
I am afraid i can not agree. Backwards compatibility .... A Great idea you event a new redesigned/improved/should be like that module disregading that thousands of users did rely on the current implementation. If Microsoft had acted like that 3.11 would have been the end of the story !
Ok wifi_wificomponent_id is now declared static.A MAJOR ENHANCEMENT ! Sure YOU KNOW why ? Anyone can tell WHY ?
Yeah, but some developers manage to make this miracle fail. Not their intention of course but their lack of understanding the many implications. SO THERE HAS TO BE some AUTHORIZING but not only good will after lots of work.
If I understand correctly, what you mean is that you'd rather a larger program with a better developer experience, but way harder on people with lots of components / ESP8266, while the developers of ESPHome are very concerned with reducing flash/RAM usage. As an all-ESP32 person, I do agree with you on that point somewhat now that you've said something specific.
I do have to challenge two things: first, you said that Modbus covers 90% of users. That sounds...perfectly fine? The last 10% is always the hardest. Why can't you file an issue or contribute code to make it better? (E.g don't "do it just to do it", but if you make a component then maybe consider contributing back to help those same 10% who are in your boat?) That part's up to you though.
I'll be honest, I don't think most users of ESPHome are really wanting to debug in the face of such special implementation requirements, so I assume that the devs simply don't see a reason to implement it. However, as you have seem to have advanced knowledge and debugging abilities and you obviously know exactly what you need in your device, then ESPHome is probably not the framework for you. I get the sense it's made mainly for the top 95% of use cases, just like you said.
But to be fair, you basically started this thread by saying that it doesn't work and you can't trust it, which IS different than your actual argument about an arguably limited backend.
I did never state that a system consuming more memory is better than another
I also did not say that it was not possible to use EspHome for many applications.
But if you have more than a light to switch on or a fan to turn you might require custom coding. I have done this for many non standard devices (a stepper control for 4 unidirectional steppers on 5 wires, several modbus devices, vfds, a modbus sniffer for an energy monitor,.... ). Step by step this custom code was "dismantled" by ESPHome experts changing interfaces, classes, setting global class pointers to static, .... About every version update caused code fail to compile/link and required "bug fixing". Maybe YOU can tell how much memory was saved by declaring a class pointer static instead of global. Maybe YOU can tell if there is any QA or a programmer just improves to his/her best knowledge testing with his devices and causing headaches an hours of work for those who run more than a light or a fan
To be fair, the hours that had to be invested to keep my devices running were loss of time and i better had dropped and program in native Esp-IDF from the beginning. That 8266 devices i had will be kicked out togehter with CustomComponents/ExternalComponents and all that great enhancements.
And even controlling lights is still lacking functionality within Homeassistant or such has to be implemented very sloppy with automations.
Before you depart, see the current 2026.5 release notes where you CAN specify Native ESP-IDF Toolchain Support, making your whine a tad premature. ## Native ESP-IDF Toolchain Support
You guys can think whatever you want. Some random anonymous person on the internet opinion is literally the very last thing that concerns me.
If you want to know so bad click my name and go read the dozens of posts where I already provided all the detail you're asking for, and not a single soul was able to fix it.
Until then I remain steadfast in my conviction, based on empirical evidence, that something that worked pre-upgrade ceased to do the same post-upgrade, and no amount of ridicule or bear poking will change that.
Sure, I won't attempt to change your mind further.
However, I did take your advice and I went to your profile. Of your 31 posts, nothing jumped out particularly about ESPHome, unless I am mistaken. And then of your ~1000 replies, I scrolled past the last, what, 150? and did not see anything jump out, except the few in this thread.
And if I did either of these things:
no amount of ridicule or bear poking will change that.
then I did not mean to come across that way and I apologize.
