Dallas Component replaced by "one_wire"

Those documents also show that device_class is set to “” in the second example using Signal % as a UOM.

1 Like

Which one should be used, device_class: "" or device_class: "percentage"?

I answered my own question. I tried “percentage” and got this:
Unknown value 'percentage', valid options are ...
with a list of 51 options. Percentage wasn’t on the list.

It’s probably percent then. I’m going off memory here.

Edit: apparently percent doesn’t exist. Only specific percentage based device classss. So leave it None or “”

1 Like

THANK YOU for posting some useful example code.

Also for everyone who is saying “should have read changelogs” along with “don’t update if its working”…that’s EXACTLY how I ended up where I am today. Everything was working, didn’t update until I wanted to change something. Suddenly nothing works. No idea why, and changelogs are not cumulative so I have no idea what was in the who knows how many intermediate revisions. Those answers are USELESS AND CONTRADICTORY!

Please stop shouting.

I’m not shouting, I’m trying to draw emphasis to the contradictory answers that plague these sort of issues.

Over, and over, and over again I run into this…“don’t update unless you need to change something” followed by “well obviously when you updated read the changelog”.

Except there’s nothing in the changelog for the update that is ACTUALLY being installed, its like 5 dozen changelogs ago in a footnote and as best I can tell there’s no way to tell what I need to go back to once its no longer working because you can’t even boot it up and check the past firmware after you’ve compiled new firmware that doesn’t work as expected.

1 Like

Yes you were.

I agree, the need to keep up with changes is difficult.

Those two things are not contradictory.

Always read the release notes and update if there are breaking changes that affect you so that they don’t accumulate. If nothing affects your config then you don’t have to update.

1 Like

It is though.

“don’t update if it’s working” well then you aren’t getting any changes.

And then when you read the changelog when you do need to modify something it doesn’t accurately reflect all the deltas you missed.

You can’t have it both ways. Especially when there’s no way to really identify what version a text config is tied to.

No one said not to read all the release notes, whether you update or not. Otherwise how would you know if you need to update?

It is very simple:

  1. Always read the release notes. It takes less than 5 minutes a month.
  2. If your config is affect by a breaking change then update to prevent accumulation of breaking changes.
  3. If no changes affect you then you are free to choose to update or not.

If the argument is “its working so don’t update it” then what’s the point in bothering to read something you won’t attempt to change?

That was literally OP’s issue in this thread, wanting to update something that was working and then had others saying not to if it was working. I’ve also run into this before - its not at all new in this forum.

I get where you are coming from, I’m telling you that is flawed advice. Do not assume you can “never update”.

You may have to update eventually. Breaking changes that affect the HA integration (rather than ESPHome internal components) are very rare but they can happen.

Following the approach I outlined above is a much better way of dealing with this.

I very rarely update ESPHome devices. I think the last update I did on any of them before now was over 9 months ago. I just recently updated everything to the latest version.

What I do is validate the code before installing the updated firmware on the device. That will (should…?) give you an error if there is a problem. Then you know to look at the thing that the error points you to.

At least that’s what has historically worked for me and that’s what worked for me this time as well. It caught the OTA change and the one-wire config changes.

I checked the updated docs for those, fixed it and then it updated fine.

That and keep your eyes open in the forums as well since those kinds of things usually get some air time here as well. As this one did.

1 Like

I just installed the ESPHome legacy add-on (version 2024.5.5) and the old devices can still be edited if needed as they are. If I need to update them I move them to the new code.

1 Like

i got the same problem, i have two dallas sensor to GPIO4 , before update i was able to find the address to both sensor, now i can find the address only for one sensor, does anyone have an ideea why?

this is my code:

esphome:
name: boiler
platform: esp8266
board: esp01_1m

wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password

logger:
level: DEBUG # Setează nivelul de logare pe DEBUG pentru a vedea toate informațiile

api:
encryption:
key: “wxt6WQI3nxdHyoCzOtOmSOedLIYC+D15zfpWVjymZv8=”

ota:

  • platform: esphome
    password: “9a33732ad90536eb05ed3042139952c5”

one_wire:

  • platform: gpio
    pin: GPIO4 # Pinul unde ai conectat senzorii DS18B20

Define Dallas sensors

sensor:

  • platform: dallas_temp
    address: 0x4a3c01f096d9f128
    name: “Temperatura Boiler”

external_components:

captive_portal:

You only have one 1-wire sensor defined:

Also please format you post correctly for the forum in future. Use the </> button in the toolbar or do this: https://community.home-assistant.io/t/how-to-help-us-help-you-or-how-to-ask-a-good-question/114371#oneone-format-it-properly-16

Thank you. This code snippet is exactly what’s needed in the release notes. Or, as you mentioned, if the change is easy and programmable (as this is), an automation or upgrade script could change all files during the upgrade.

It could, but it would have to ask first.

That is in the release notes.

ok … sorry