2022.2: Let's start streamlining!

as a beta tester, and a dev installer, please let me warn you on OS updates shown when in the beta channel…

Ofc you understand the difference between the actual OS and HA Core. Yet, they both are displayed. Be warned to always check the issues on the OS updates, because they are way more critical when issues have been found than the Core updates. Core, one can simply downgrade. OS issues can truly brake the instance, and might need some more work repairing…

‘Open release notes’ takes you to the repo, and check issues there!
https://github.com/home-assistant/operating-system/issues is the direct link.

Though I blindly install the nightly Core dev’s on my production system (only 1nce had an issue in the last half year or so) Ive learned to not do so with OS, and use a dedicated machine for that…

2 Likes

iirc, it will have the timestamp as state, and should even be restored in next release (currently in dev)

When you say “restored”, do you mean on ha restart? Mine does that on 2022.2.2.

Yes, and ok, didn’t realize it was already live, (so many Pr’s to follow…)
All the better!

@nickrout this was what I was referring to: https://github.com/home-assistant/core/pull/65696
mentions also for button

May depend on the integration of course.

Seems to be a known issue.
Can’t rename devices after Core update 2022.2.2 - Home Assistant OS - Home Assistant Community (home-assistant.io)
and
Lost the ability to edit device names - option is greyed out - Configuration - Home Assistant Community (home-assistant.io)

I’ve just installed rpi_gpio from HACS ( https://github.com/thecode/ha-rpi_gpio ) and it’s transparent, all working as same before… Let’s see after they removed it in Home Assistant Core 2022.6.

1 Like

Yes, I have already installed via HACS. I’m trying to find an answer if the integration is still working in the kernel and the same via HACS, which integration is now running, which has priority?

Quick, tell me the current state of my garage door.

You don’t know what it is so you say the truth, the door’s state is unknown. That’s how all binary_sensors (in other integrations) work except Template Binary Sensors which, until now, would fake it and claim the door is closed.

Telling the truth about the available information isn’t a negative and that’s why the behavior of Template Sensors is now aligned with others.

1 Like

For the blind person yes. But not for the button. It’s either on or off. Or not available. Unknown state I still don’t get…

4 Likes

I don’t agree.

1 Like

It’s been explained multiple times in this thread

And what about an idle state, for example

There’s nothing to agree with… that’s why it’s there. I’m stating the reason. Agree or disagree, this is the reason.

Don’t fight the system. Guys it’s ok. I can’t remember anyone asking or having an issue with not having a unknown state. I now have to figure out why my binary sensors return unknown state when in fact they are not…

1 Like

Every other domain has it… it was just added to binary_sensor. Like it or not, this has been in home assistant for 8+ years.

Is ok. Doesn’t mean I like it since it gives problems I don’t understand.

1 Like

But we don’t care about what knowledge the button has.
The button is not running HA, is it?

The button knows, HA doesn’t, so HA tells you it doesn’t know by setting the state of the HA button representing the button to unknown.

Is it really that hard to understand?
You know your age, I don’t.
You know if your kitchen lights are ON or OFF, I don’t.
You know if you currently press the button of your kitchen lights, I don’t and neither HA.

The new button entity works fine in lovelace but Google Home responds to “press the blue button” with "Sorry I don’t understand:

 template:
  - button:
    - name: "The Blue Button"
      press:
        - service: nodered.trigger
          entity_id: switch.weatherforecast

Well, they may have to be renamed ‘trinary’ sensors eventually, as they now have three states, and not two anymore… :wink:

5 Likes