No, that doc is out of date.
1 Like
Hm… when entering exactly above lines then line “safe_mode: true” is underlined with red, error is that safe mode has moved from ota to it’s own component…
Yes the docs are incorrect and need updating. See the post directly above yours by Troon.
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
3 Likes
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
2 Likes
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:
2 Likes
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
1 Like
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…
1 Like
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”!!!
1 Like
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!
2 Likes
There are plenty of other defaults in esphome so it’s not entirely a silly idea to default the platform.
4 Likes