Dallas Component replaced by "one_wire"

[vaderag]

@tom_l

The decision to create the breaking changes was not taken lightly.

@nickrout

the important point is that nothing on your system broke

I don’t disagree here.
BUT, I did have to do digging and post to get help.
I wont be the last to post about this or a similar thing

I am suggesting two things to make your general users experience better (and lessen your need for forward support):

1. When someone tries to update and gets an error: it should tell you what that error is ( and it should link to the precise fix if available )

This section below can be SO much more helpful with minimal additional effort

Failed config

dallas: [source /config/esphome/water-tank-esp8266.yaml:8]
  
  The "dallas" component has been replaced by the "one_wire" component.
  https://esphome.io/components/one_wire.

2. Ideally, that fix break or move forward, should happen automatically. (there seems debate here, but if you had a check box to choose to have this automatically apply fix changes in settings or similar then that could alleviate others concerns )

Users are lazy - they don’t want to dig through release notes or even leave the browser tab they are on. These should absolutely be available, but where possible users should not need to go to them

[NathanCu (Nathan Curtis)]

@vaderag

there seems debate here, but if you had a check box to choose to have this automatically apply fix changes in settings or similar then that could alleviate others concerns )

Its not a debate it’s not possible without writing some rather complex code. It’s not a search replace item like the platform Ota entry that one could have been done automatically. This one could not.

[vaderag]

I mean, the devs here are pretty competent - I wouldn’t call changing the below complex

1. dallas → one_wire -platform: gpio
2. dallas → dallas_temp

# Old
dallas:
  - pin: GPIOXX

sensor:
  - platform: dallas
    address: 0x1234567890abcdef
    name: "My Sensor"

# New
one_wire:
  - platform: gpio
    pin: GPIOXX

sensor:
  - platform: dallas_temp
    address: 0x1234567890abcdef
    name: "My Sensor"

In either case, it could have been better handled - I think we agree

[NathanCu (Nathan Curtis)]

If someone used index it needs removed. If they have multiple Dallas sensor chips in a build, it needs to be accounted for.

Again. Its not a straightforward replacement (I’m currently working through three of them on some custom devices myself) and the standard edits can break things if the side cases are not accounted for.

But most importantly…

No you do not edit someone’s YAML. Jo matter how easy. That’s the equivalent of coming in and editing my source on my custom components. You don’t do it.

[Protoncek (Pavel)]

@vaderag

people shouldn’t NEED to read change logs

Wrong. Each any every product says “read the manual before use”… changelog IS the manual for this purpose.
So you just blindly click “update” each time it appears? Jesus christ… I’m pretty surprised you didn’t crash HA yet… (but perhaps you did…?)

@vaderag

Software should just work.

Sotware NEVER “just work”. Nothing is perfect. There are always bugs, there will always be updates, improvements… that’s how it is, not only in software, but everywhere. That’s why you NEED guides (i.e.changelog).

@vaderag

BUT, I did have to do digging and post to get help.

Wow… you had to dig…what a mess… remember: software is still free, so it’s kinda “don’t like it → don’t use it” system. A bit of gratitude to developers would be nice… programmers did the main job (many in their free time), so least you (and me) can do is read changelog before using (or updating) it. After all a couple of minutes is all it takes. Don’t say you don’t have those couple of minutes to spare, because if you don’t, then you don’t have time for HA as a whole. HA takes time, constant time, it’s not “play&plug” system.

[Troon]

@vaderag

Because there’s an update in my update list and that’s what you do

Turn off the update list if it’s causing you problems. Almost no ESPHome updates are necessary to keep existing problem-free devices working. I have no update notifications and skip many updates as a time.

When I do choose to update, I see what fails to compile then look through the relevant changelogs.

[vaderag]

@Protoncek

Sotware NEVER “just work”. Nothing is perfect. There are always bugs, there will always be updates, improvements… that’s how it is, not only in software, but everywhere. That’s why you NEED guides (i.e.changelog).

What a load of rubbish… How many times have you had to check the changelog on an app on your phone. Outside of Home Assistant, never.
How many times have you installed an Android or iOS update without reading it, or installed a security update…
Maybe 20years ago, but not today

Yes things break, but striving for a “just work” scenario is what everyone does these days

Wow… you had to dig…what a mess…

Don’t be a jerk - I’m providing very reasonable suggestions for how the developers can make this easier for everyone

So you just blindly click “update” each time it appears? Jesus christ… I’m pretty surprised you didn’t crash HA yet… (but perhaps you did…?)

Plenty of people enable auto updates or want to. It’s 2024 it’s an expectation that you should be able to safely auto update anything for security purposes without things breaking.

[tom_l]

Argue and debate by all means but please be respectful of each other.

Code of Conduct

[Protoncek (Pavel)]

@vaderag

How many times have you installed an Android or iOS update without reading it, or installed a security update…

Ammmm… never. ABSOLUTELY NEVER! But, as i see your language is not for normal people, only for “jurks”, so i’m out.

[Nabs]

I have two Dallas sensors. I updated ESP, added the one_line thing in and changed the dallas to dallas_temp, added the ota platform in… And both devices refuse to update and give some sort of error with compiling. I am stuck on what to do next as I simply don’t have the coding know how to dive into this.

So at least for me this is a whole lot of hassle and causing me a lot of ‘wtf’ moments that I can do without.

Any suggestions would be most welcome.

[Troon]

@Nabs

Any suggestions would be most welcome.

Share your code and the “some sort of error message”.

[Nabs]

Sure thing:

[Troon]

Firstly, please paste code and logs as properly-formatted text, not screenshots.

Have you actually read the error message? It tells you exactly what the problem is.

You must have had a pin number set up under your previous dallas heading — it’s the same as that.

[nickrout]

Gpioxx - you need a real number there. Just like the error tells you.

@Troon beat me to it.

[Nabs]

As I said, I didnt understand it, I hadn’t realised it had replaced a number with xx and I dont deal with code so I am unfamiliar with these things.

It has now updated, thanks for the help.

[Mavorad]

Hi all, I understand the discussion above, But: when I have two systems with 10 sensors working for more ten monts without a problem and after the update, and yes reading the guide, it is not stable any more. I get warning flags and scratch pad errors over and over now. from 10 sensors only 6 are recognized, the rest is “lost”. It is working on pin 28 at the moment. What can I do??

[Troon]

@Nabs

I dont deal with code

That’s not really an option with ESPHome.

“I don’t deal with code” is a mindset that you’ve chosen to have. ESPHome’s configuration is barely code in its simplest form, anyway: it’s a structured set of settings from which it builds a firmware. The only “code” aspect is that it is formatted in YAML.

[Troon]

@Mavorad

What can I do?

Roll back to a version that works and raise an issue on the ESPHome GitHub.

See this one first: Dallas onewire temperature sensor discovery no longer working after update to 2024.6 beta · Issue #5908 · esphome/issues · GitHub

[Mavorad]

Thanks for the reply, I will try.

[AARC]

I made an account so I could chime in here.

I entirely agree with @vaderag on this.

I was affected by a breaking change that wiped out all my Sonoff S31 smart plugs and meant I had to dig them out of some challenging locations, unplug them and all the devices connected to them, physically open them, put probes on their UART pads and re-flash them, then button them back up and re-install them. That was over twenty devices. It took WEEKS of spare time fragments. I’m affected by this one too. That’s in less than 6 months with a moderately complex system. I try to be vigilant on breaking changes but also prompt in my updates.

I’m an IT tech by trade and I’m used to it but the point is that this will never be adopted widely if you need to be an IT manager to keep your smart home secure with patches. It simply won’t.

I love hand soldering custom boards with ESP32 dev boards and custom component layouts blah blah… but there should be an “easy mode”.

I appreciate that breaking changes must happen, but it can’t be that hard to parse the YAML of existing devices and flag ones that will be affected by a breaking change and not auto-update those.

It should be easy under MANY (obviously not all) circumstances to have affected code segments be flagged and auto-find-and-replace be suggested. If it’s not possible that its self can be flagged. If it is you get a chance to review the code or accept all auto-recommendations.

It’s simply not reasonable for a project with a goal of accessibility and broad adoption to make end users have to review update logs for specific breaking changes that affect individual sensor components. That’s utter folly… a truly preposterous notion.