2022.2: Let's start streamlining!

yaml configuration should remain… imagine having many devices, i could update the configuration in a second using yaml. thanks

3 Likes

Configuration of what?

Goodbye!!!

4 Likes

Netatmo working fine here after upgrade from 12.10 so it’s you rather than the system.

Maybe try looking in / posting your logs, etc and you’ll likely get help / insight on here…not sure a rant is going to help you 🤷🏻

1 Like

I’d the same error when checking but took the plunge to upgrade…had a backup so what’s the worst that could happen :thinking:

Thankfully all went fine so seems nothing to worry about :+1:t2:

@janinho think this might help you too as you’ve posted same error msg to thread

4 Likes

Me too. Clearly something to do with the dropping of support for Python 3.8 but the release notes say:

"Python 3.8 support dropped

Python 3.8 support has previously been deprecated and now has been removed. Home Assistant now requires Python 3.9 to run.

If you are using Home Assistant OS, Home Assistant Container, or Home Assistant Supervised installation method, you don’t have to do anything. In those cases, we handle this all for you. Your system has been using Python 3.9 for quite some time already."

Doesn’t look like it is all handled?

See my msg directly above yours :+1:t2:

1 Like

the new Zone state feature was pulled, because in the beta discussion arose on several features and lack thereof. Paulus stated it will be done, and back, but only when properly thought through and implemented. see I zone, you zone, we zoning by balloob · Pull Request #65344 · home-assistant/core · GitHub

As Frenck siad it:

We had quite the discussion yesterday, and there are multiple solutions possible, but all would imply either many last minute changes OR a possible breaking change again next release
thus we reverted the zone state for now, as neither case is a wishful situation
This gives the opportunity to look at the possible solutions better, test it in dev, tweak, give it a new beta test and release it next month

in general…

2 Likes

And same about the current installed HA version - it is unavailable very often.
Does anyone see the same?

:rofl: That ship sailed two years ago.

Another great update, thanks a lot!

It seems the update would be easier for most people if they just read the breaking changes and/or the updated documentation for integrations.

I also created a simple blueprint to help LG webOS users migrate to the new turn on format.

2 Likes

Guys, i updated, all OK, but see below, it doesnt tell me the platform thats converted?
So no idea what i need to remove now?

2022-02-03 12:36:24 WARNING (MainThread) [homeassistant.components.version] Configuration of the Version platform in YAML is deprecated and will be removed in Home Assistant 2022.4; Your existing configuration has been imported into the UI automatically and can be safely removed from your configuration.yaml file
2022-02-03 12:36:24 WARNING (MainThread) [homeassistant.components.version] Configuration of the Version platform in YAML is deprecated and will be removed in Home Assistant 2022.4; Your existing configuration has been imported into the UI automatically and can be safely removed from your configuration.yaml file

edit; found it , its “version”

The new “Check updates” feature is added:

изображение

I am running HA in Docker.
If this feature is for HAOS only - why do I see it here?

If it was specified for HAOS only - I will create an issue then.
But it was not.
OK, probably the feature is NOW available only for HAOS and may be ported to other installation types later.

Actually, I am interested in “why version is unavailable?” only…
Other things seem to work smooth.

its by design, i asked in beta and was told its a fyi

that’s not really a huge surprise isn’t it? :wink:

1 Like

yeah, saw it too late :slight_smile:

@perjury1 I’m running Home Assistant OS, and know it’s been on Python 3.9 for some time, so not finding this path is a bit of a concern. I’m wondering if it’s the check that’s flawed?

I am not able to install 2022.2.0

22-02-03 13:23:29 ERROR (SyncWorker_3) [supervisor.docker.interface] Can’t install ghcr.io/home-assistant/qemux86-64-homeassistant:2022.2.0: 404 Client Error for http+docker://localhost/v1.41/images/ghcr.io/home-assistant/qemux86-64-homeassistant:2022.2.0/json: Not Found (“no such image: ghcr.io/home-assistant/qemux86-64-homeassistant:2022.2.0: No such image: ghcr.io/home-assistant/qemux86-64-homeassistant:2022.2.0”)

Is someone else getting this error ?

personally, I really wish we had an option to allow new device_trackers to be enabled upon discovery. since https://github.com/home-assistant/core/pull/63328 newly discovered device_trackers are disabled,

and have no attributes in the entity_registry_updated event_type resulting in:

using:

  - alias: New device registered config
    id: New device registered config
    mode: queued
    trigger:
      platform: event
      event_type: entity_registry_updated
      event_data:
        action: create
    condition: >
      {{trigger.event.data.entity_id.startswith('device_tracker')}}
    action:
      - variables:
          data: >
            {{trigger.event.data}}
          entity: >
            {{trigger.event.data.entity_id}}
          name: >
            {{state_attr(entity,'friendly_name')}}
          host: >
            {{state_attr(entity,'host_name')}}
          ip: >
            {{state_attr(entity,'ip')}}
          mac: >
            {{state_attr(entity,'mac')}}
          source: >
            {{state_attr(entity,'source_type')}}
          id: >
            {{device_id(entity)}}
          config: >
            - entity: {{entity}},

            - name: {{name}},

            - host: {{host}},

            - ip: {{ip}},

            - mac: {{mac}},

            - source_type: {{source_type}}

            - id: {{id}}
          time: >
            {{now().timestamp()|timestamp_custom('%X')}}
          title: >
            {{time}} - New device registered: {{name}}
          message_body: >
           New device config: {{config}}

(devices that are enabled upon discovery according to the new device_tracker logic do show all/most of these fields populated.)

after enabling the tracker we can see all attributes are in fact there:

either bring back the enabled option, or, if possible, also provide details on disabled device_trakcers…

1 Like