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.
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.
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:
- Always read the release notes. It takes less than 5 minutes a month.
- If your config is affect by a breaking change then update to prevent accumulation of breaking changes.
- 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.
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.
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:
- source:
type: git
url: GitHub - ssieb/esphome: ESPHome is a system to control your ESP8266/ESP32 by simple yet powerful configuration files and control them remotely through Home Automation systems.
ref: onewire
components: [ gpio ]
refresh: 1min
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
but i cant find the address for the second sensor.
# Example configuration entry
one_wire:
- platform: gpio
pin: GPIOXX
Then take a look to the LOG
Don’t be silly, read the docs? Ridiculous!!