Heads up for Esphome 2024.6

[tom_l]

@Protoncek

Also: has “update_interval” moved from “dallas” config to “platform: dallas_temp” ?

Yes. Just changed all of mine:

sensor:
  - platform: dallas_temp
    address: 0x1a3c01e07605b228
    name: "Tank Temperature"
    update_interval: 3s
    filters:
      - sliding_window_moving_average:
          window_size: 10
          send_every: 10
          send_first_at: 1

  - platform: dallas_temp
    address:  0x58000000167d7228
    name: "HP Inlet Temperature"
    update_interval: 3s
    filters:
      - sliding_window_moving_average:
          window_size: 10
          send_every: 10
          send_first_at: 1

[Troon]

@tom_l

Ah, so that is required in addition to this?

No, that doc is out of date.

[Protoncek (Pavel)]

@tom_l

ESPHome OTA Updates — ESPHome

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…

[tom_l]

Yes the docs are incorrect and need updating. See the post directly above yours by Troon.

[Protoncek (Pavel)]

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…

[tom_l]

I’ve created a pull request to fix the docs. Update ota.rst by tomlut · Pull Request #3973 · esphome/esphome-docs · GitHub

[tom_l]

@Protoncek

What’s with dallas old option “index” ? It’s unknown feature now…?
i’ve had setup below, since i have three dallas sensors, but each on it’s own gpio, so i don’t use dallas addresses.

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

[Protoncek (Pavel)]

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…

[tom_l]

It used to say this:

[Protoncek (Pavel)]

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).

[currest2620 (Steven Curren)]

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.

[mcarty (Arturo)]

What is this new platform for?

SDL2 Display on host platform

Is it to simulate the display on another computer?

[paddy0174 (Patrick)]

@nickrout

Brought to you by your team of regulars.

[Troon]

@Aresitoo

get this message

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

[byarotsky]

Thank you. Worked for me

[mge590919 (mge)]

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…

[tom_l]

Dallas onewire temperature sensor discovery no longer working after update to 2024.6 beta

[mge590919 (mge)]

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…

[jbuszkie (Jim B)]

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”!!!

[paddy0174 (Patrick)]

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!