This situation (ota and one_wire changes) is a less severe type of breaking change: your prior YAML will fail to compile and the devices will continue to run as before on the old firmware.
The situation you describe with your smart plugs is a different level and yes, breaking changes that will make it through compilation and update ought to be flagged.
My one_wire migration went smoothly, thanks to all the help here. The documentation left a lot to be desired, however. Without this forum it would have been a trial-and-error project.
I certainly feel the pain of anyone not full-time into HA or ESPHome development, trying to maintain even a basic system using these products. This month is probably a record for me, with dozens of hours of research and a number of long lists of my own notes, complete with links to all the problem reports, change logs and helpful posts. I finally got to do my one monthly update yesterday. Next week I start the process all over again for next month’s HA update.
That said, I’m finding ESPHome to be the easier of the two to maintain. At least here I can keep a development ESP board accessible to try any changes on. As was mentioned, the rest of the devices will continue to work while I dial in whatever updates I need. I can roll them out one at a time and test each device afterward. With HA I only have one production system.
I also like that I can run the ESPHome CLI on my laptop, so nothing I do there impacts my production HA system. I still have the add-on installed, but all it ever does is notify me when there’s an update. Everything else happens on my laptop.
Hello!
This Dallas thing is killing me…
I have 3 dallas sensors with long wires. Each works if I connect ir alone. As soon as I connect more than 1 sensor, esphome says “no sensors found”.
What am I doing wrong?
Tired an ESP8266 (Wemos D1 Mini) and an ESP32 (Lolin S2 mini).
External 4,7 kOhm Pullup (one resistor between GPIO and 3,3V on the microcontroller)
Any help is greatly appreciated.
so for ages they were making us NOT use 1-wire and force removed it a few years ago , now they force bring it back and I have a few thousand sensors I have to completely re-write …
downside to having every aquarium tank and grow room being monitored and looks like its also taken out all my solar MPPT chargers as well
one_wire’ requires a ‘platform’ key but it was not specified.
= changing sensors dallas to dallas_temp and adding
one_wire:
- platform: gpio
pin: GPIO2 #D4
ota:
- password: !secret ota_password
platform: esphome
Ok, i agree with you, if you have so many devices it’s P.I.T.A., but nonetheless… why would you want to update them all? Do they work? If you don’t plan do add any functionality just let them be. You’ll update them one at the time when either some module dies or you’ll want some extra functions on it.
mostly its annoying being flooded by things asking for updates , and when I add new modules it causes issues for older modules and I get stuck in a situation simple code will no longer compile unless I bring everything else up to date ,
after spending a day updating everything another update came through last night and now 80% of them will not update … and none of my athom-smart-plug’s want to update so back to looking for what got broken this time
edit
looks like they removed wifi % as an option in 2024.6.6
is using native unit of measurement 'Signal %' which is not a valid unit for the device class ('signal_strength') it is using; expected one of ['dB', 'dBm']; Please update your configuration if your entity is manually configured,
Right, use percentage as your device_class. You’re setting it as signal_strength. If you want to use signal_strength, you need to use valid units for it. Otherwise if it’s a percentage, use percentage. Or remove the device_class all together and keep your unit of measurement.
TLDR: Change device_class to percentage, change unit_of_measurement to %
Or just use this which does it all for you:
Those documents also show that device_class is set to “” in the second example using Signal % as a UOM.
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 “”
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.
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:
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.