Why is "update available" more important than "online"?

This has bothered me for a while now and when I saw an image of the “old” interface it reminded me again.

I understand some do update their nodes, but I don’t unless I have to.
And that leaves me with “update available” instead of “online”.
I get that there is a use of knowing that there is an update but that does not make it less important to know if a node is online.

I keep having to click on the logs to see if they are up which is inconvenient and unnecessary.

2 Likes

There have been a lot of discussion about this on the ESPHome discord channel #dasboard.

However, if the device is offline, you will see the red bar and the message OFFLINE, so if you don’t see a red bar the device is online :slight_smile:

I also update my devices only when I need to, not because there is a new version and to get rid of the annoying blue bar I use the studio code server add-on to do a “replace in files” action to change the version number in the json-files in esphome/.esphome directory. This is 2 minutes work and all the blue is gone :slight_smile:

5 Likes

Yeah updating 40+ devices every month gets annoying real quick. Also not good for the flash memory write endurance. So I only update if there is an issue or a new feature I want.

I’d like to see online get a higher display priority than update available too.

This is the closest feature request I could find:

3 Likes

Not to mention the fear of something breaking.
They live their lives perfectly fine, any new code may have a breaking change (it has happened to me) and you end up having to spend hours trying to fix something.

Now that we speak of it, the update should be separate from flashing.

Meaning if I want to correct something in the node I would get the option to update or keep the same version.
But that might be hard to keep track of.

1 Like

Yeah I usually do a couple of test device updates on easily accessible devices before hitting the update all button. There’s no guarantee that another device with a different component is going to behave the same way, just more of an overall system check for common parts like wifi.

I’m not sure it’s feasible to decouple component updates from flashing the whole device.

Worse than trying to decouple HA core integration updates.

1 Like

Thank you all. Yes, it is rather insane to update devices that:

  1. May be physically unaccessible
  2. Are working fine
  3. Don’t have known vulnerabilities
  4. Have flash memory with a limited number or write cycles

Hopefully someone has thought of an enhanced upgrade process that keeps devices in old versions as long as they don’t need updates. There are also networks that don’t allow their IoT devices to access the internet, so they can be a bit more tolerant to vulnerabilities.

Tasmota, for one, does tell users not to update their devices unless something is broken.