Dallas Component replaced by "one_wire"

ESPHome
1

Please, can someone give me a dummies guide on what I’m supposed to be doing here…
Was trying to update my esphome devices which have been working fine, but first I got an OTA issue (which I just added the line in config for a mentioned here)

This worked for one of my devices, but for the other I’m now getting a secondary issue of the one above

This one is crucial to the running of my home as it controls my water tank and I’m worried that something is going to go awry if I don’t fix this

But I have no idea where to start… these breaking changes are killing me

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.
1 Like
2

Read the change log

3

Why?

Then don’t update if it’s working. If you must update, read the changelog:

1 Like
4

There is also a pinned post at the top if the ESPHome topic. Heads up for Esphome 2024.6

5

That has nothing to do with Dallas… I solved the OTA on the other device

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

2 Likes
6

:roll_eyes:

Keep reading. Heads up for Esphome 2024.6 - #13 by Troon

7

Thanks.

Out if interest why can’t these breaking changes be pushed as part of the update?

It seems that if you’re using X change it to Y is defined and thefore should just happen

At the very least those instructions could be coded in the failure rather than having to dive into release notes or forums

Home Assistant keeps saying they want to attract mainstream users, but this is exactly the kind of change that users aren’t used to making, and will never be mainstream… It’s just unnecessary frustration

3 Likes
8

Home Assistant isn’t ESPHome, although they are both owned by the Open Home Foundation. I don’t think “attracting mainstream users” is a priority of ESPHome, which, by its nature, will always be a DIY / hobbyist venture.

9

Fair enough… other points still stand - why make it harder for users than it needs to be?

At the end of the day, most people aren’t using all features - 640 words to get to the 1-wire section, which doesn’t match with the error “one_wire”

So it’s not helpful to the end users.

At a minimum the terminology should match for the search. If the error linked to the relevant section of the release notes, brilliant - this code does the trick

# 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"

But given that code is going to apply to everyone who wants to run the update from the UI, it seems that replacement should just occur as part of the OTA update

I’d also argue that updates are part of the sustainability of a Smart home per the Open Home Foundation

The Open Home Foundation fights for the fundamental principles of privacy , choice , and sustainability for smart homes.

11 Likes
10

I wholly disagree that they ‘should just do it’. Ask SmartThings users how that works for them…

but I do agree that more notice should be given before they just force it. I won’t be labor the issue though.

11

I think that changing a users yaml as part of an update is the wrong thing to do.

4 Likes
12

Why? If it’s going to break, or not be able to be updated before you change the code, you either end up with something broken or out of date - the latter presumably being a security issue, and the former clearly an issue?

In either case, the other two options (linking to the correct place or adding the code to the error) are clearly better than what we have today

13

I think people not reading the change log is the real issue.

2 Likes
14

If they go into my yaml and don’t understand how or why I setup my code it will break it worse than if I do it myself.

Read the one wire changes. It’s not a 1:1 drop in. And I’m pretty positive they’d mess it up. And part of the reason I haven’t updated my own installation. I need to sit and read the change first to know what to change

No.

(I read it Nick. And it iriitated me)

15

That’s such an outside way of thinking - people shouldn’t NEED to read change logs - this is a fundamental problem with the way many people think in this community.
Software should just work. If something is breaking, then fix it seamlessly. If a user wants to know what you have done, then they can read the changelog - the way you are talking is the wrong way around

1 Like
16

That won’t EVER happen in open source software you MUST read the change logs

If you won’t. You’re probably not using the right system.

1 Like
17

That won’t EVER happen in open source software

Because people don’t want to change… Ironic given that’s what the Open Home Foundation says it wants to enact change elsewhere

If the goals are to expand to the mainstream and mainstream understanding then it should not break on you. And if it MUST then the clarity on the change should be where the user sees it, not in a changelog

If I pushed changes this way to my users, there would be no end of escalations… and you only have to look through this forum to see many disagree with this way too

18

Correct, people don’t want to change. But you also have to consider the roots of the software. You cannot come in and say no i dont like this do everything different now.

… And expect anyone to actually listen. Because frankly, they don’t have to do anything at all and it’s… ‘okay’

But I agree change should happen. Status quo should never just be accepted because thats how it’s always done. You can come in and say something like…

Hey guys I know this change seems innocuous but we have a real problem here with perceived serviceability - how about we throw a warning this release that there’s an upcoming breaking change in the next release. (and yes… Breaking Change. Ugh… I will never use whatever that other phrase is)

Some will say… well, users never read the notes anyway.

Yes you’re right… Nick.

But just because end users don’t read doesn’t mean we stop warning them. Oh four people didn’t read the sign and drove right over the cliff. So we’ll take down the sign. Uh. No.

But you also don’t reach in to thier environment and change stuff. Want to see me rip this right out of the house? Do that.

The user friendly version of this is a deprication warning that sticks until it’s done. Dev will say that’s basically what you got… Get over it.

But one experience is a nice hand hold for users and the other feels like the software is screaming at them. Open source guys… Windows and Mac users have been trained NOT to skip updates and a yellowbang with wavy underlines in your yaml says hey this is broken! (and some people get anxiety with systems doing that, but that’s an entirely different conversation)

This one is a perfect example of yes it’s no harm no foul but the experience leaves a really bad taste in the user’s mouth because of HOW it was done.id like to see a minimum wait period of a month before planned changes like this are implemented.

1 Like
19

Exactly. And these breaking changes will allow for much better support in future. Particularly for manufactured devices that support ESPHome.

The decision to create the breaking changes was not taken lightly. However the advantages far outweighed the small amount of pain they cause. Watch the ESPHome release party on YouTube. The reasoning is explained.

3 Likes
20

@vaderag the important point is that nothing on your system broke, esphome wouldn’t compile an update. However your esp device stayed the same and continued to work.

2 Likes