Yes, i see, thanks. I guess i was writing at the same time with Troon, so i didn’t see his post. entering “safe_mode:” directly (without indent) has no errors.
However… is now necessary to enter this line or is safe mode enabled by default when nothing is stated (like it used to be)? I neved wrote this line in my yaml’s, but all are safe mode enabled…
I’ve created a pull request to fix the docs. Update ota.rst by tomlut · Pull Request #3973 · esphome/esphome-docs · GitHub
Looks like it has been removed.
Now for your set up you have to create three 1wire bus components with ids that you would reference in the dallas_temp platform.
one_wire:
- platform: gpio
pin: GPIOXX
id: bus1
- platform: gpio
pin: GPIOYY
id: bus2
- platform: gpio
pin: GPIOZZ
id: bus3
sensor:
- platform: dallas_temp
one_wire_id: bus1
name: "Temperatura sanitarne vode"
update_interval: 60s
accuracy_decimals: 0
filters:
- offset: 1.0
Yes, i did that, compiled and all is ok.
Now it’s just if i dare to send this bin to my esp and risk all 3 dalass sensors failing… 
I actually forgot why “index” was there for… but if i recall correcly (it’s been a while…) that sensors didn’t work without it…
It used to say this:
Aha, so old way it seems that it was required if used without address. Now it seems that it’s done automatically, since manual says for address “Required if there is more than one device on the bus.”
I know, it’s better to use addresses, but i’ve had my share of bad luck with dallas sensors back then when working with Atmel AVR’s, when i’ve had 10 of them on the same bus. Which worked great … until… one of them died and consequently all results went to 85 degrees. WHICH one of 10 was P.I.T.A. to find, since all were soldered, isolated with heat-shrinking tube with thermal paste inside… it was like i was doing whole 10-sensor thing all over again, only worse… from there on, i rather put each one on its own pin, if only possible (and within reasonable limits).
I guess i’ll test it in the evening, when i’ll have some time to repair if it dies…
EDIT: i was watching 2024.6 livestream: they say that safe mode is enabled by default, so no action or entry is needed UNLESS you tinker with default settings (which are: enabled and entering safe mode after boot 10 attempts).
FYI…
Just updating my esp_home devices and noticed that I don’t have an ota: section for my M5Stack configuration.
Can’t quite recall why its different now but the update seems to be installing without having updated the configuration.
What is this new platform for?
Is it to simulate the display on another computer?
That error is from your Mitsubishi heatpump config. Please post code and error logs as formatted code not screenshots.
At a guess, related to this: esphome 2024.6.0 changed the definition of HARDWARE_UART_TO_SERIAL · Issue #152 · geoffdavis/esphome-mitsubishiheatpump · GitHub
Thank you. Worked for me
I get strange behaviours with my DS18B20 temp sensors when updating my ESPHome software to 2024.6 and making the required change from dallas: to one_wire:
In my system with ESP32DEV controller it detects the DS18B20 sensor and reports the temp value, so everything seems to work just fine…:
[23:53:18][C][gpio.one_wire:016]: GPIO 1-wire bus:
[23:53:18][C][gpio.one_wire:017]: Pin: GPIO14
[23:53:18][C][gpio.one_wire:080]: Found devices:
[23:53:18][C][gpio.one_wire:082]: 0x2200000bfa0c2028 (DS18B20)
[23:54:17][D][sensor:094]: '11. Internal Temp': Sending state 29.12500 °C with 1 decimals of accuracy
In my system with ESP32S2MINI controller i get these messages:
[23:59:33][C][gpio.one_wire:016]: GPIO 1-wire bus:
[23:59:33][C][gpio.one_wire:017]: Pin: GPIO39
[23:59:33][W][gpio.one_wire:078]: Found no devices![23:42:23][W][component:170]: Component dallas_temp.sensor cleared Warning flag
[23:42:24][W][dallas.temp.sensor:074]: '11. Internal Temp' - reading scratch pad failed bus reset
[23:42:24][W][component:157]: Component dallas_temp.sensor set Warning flag: bus reset failed
[23:42:24][D][sensor:094]: '11. Internal Temp': Sending state nan °C with 1 decimals of accuracy
In my system with ESP32C3SUPER MINI i get these messages:
[23:51:33][C][gpio.one_wire:016]: GPIO 1-wire bus:
[23:51:33][C][gpio.one_wire:017]: Pin: GPIO5
[23:51:33][W][gpio.one_wire:078]: Found no devices!``
Before the upgrade to 2024.6 (and when using dallas: instead of one_wire:), everything has been working fine for a long time…
Reverting to version 2024.5.5 using
khenderick/esphome-legacy-addons ( and of course followed by editing the files back from one_wire: to dallas:, and on every temp sensor changing from dallas_temp back to dallas), made all my temp sensors come back to life again…
So we are hoping for a solution to this in version 2024.6.x…
As much as I appreciate all that the contributors do for ESPhome and such… Why would you guys put in a breaking change that will force me to have to update every single yaml file I have!! I can’t even see the logs! Why can’t it default to “platform: esphome” if it doesn’t see “platform”!!!
EDIT: I’ve been made aware, that I could have said my point in a friendlier manner, and I do agree, I should have! 
Sorry from my side, I’ll try again. 
I can understand your anger, and it’s never nice to have breaking changes! But they are sometimes necessary and in this specific case it seems to be a major architectural change.
I’m sure, the developer(s) find it as unpleasant as you, but deemed it necessary, otherwise they would’ve avoided it!
What I could offer is a little workaround:
If you have a good editor (Notepad++ should do the trick), you can find&replace over different files.
The YAML files for your ESPHome devices are stored under /config/esphome. Stop the ESPHome add-on, let the editor do it’s job and find&replace all matches, safe all files and start the ESPHome add-on again.
That should take not much longer than a few seconds.
Hope this helps!
There are plenty of other defaults in esphome so it’s not entirely a silly idea to default the platform.
I didn’t say it is a silly idea, I’m saying there obviously are reasons for this decision, in this specific case, like
In release 2024.6.0, the
otacomponent transistioned from a standalone component to a platform component. This change was made to facilitate the use of multiple update mechanisms, enabling greater flexibility.
And that’s why I personally think, it is sometimes necessary to do breaking changes. What I don’t think is necessary is the mimimi when breaking changes come along, especially if it’s nothing difficult to change. 
The weather forecast was a different story, but c’mon, it’s not a complex phrase, it’s a one liner.
Opening this forum, searching for the issue and writing four sentences likely cost more time, than doing the change on five or six devices…
It’s not a personal decision a developer makes to anger people, it’s a necessary software and coding choice, that every developer tries to avoid. So if it is done, it’s unpleasant for the developer and the user, but necessary, and not something to blame the developer(s) for.
Agreed. All I was saying was that there are plenty of other defaults assumptions in esphome, this transition may have been easier with a default, perhaps with a warning
I’m totally with you, regarding communication and information. But in this case it wouldn’t have made things better - sooner or later the line has to be changed, grace period or warning. So why not do it right now?
But I hear you, I should have been friendlier in explaining my point!