2022.2: Let's start streamlining!

Blog
879

Is there anyone who can confirm if the broadlink switches are now only configurable thru the UI?

there have been reports that YAML configured broadlink switches are gone after the update to the latest versions but in the documentation it still refers to YAML config for switches:

SETTING UP CUSTOM IR/RF SWITCHES

The first step is to configure the device normally via the configuration flow. Then add these lines to your configuration.yaml:

# Example configuration.yaml entry
switch:
  - platform: broadlink
    mac: MAC_ADDRESS
    switches:
      - name: Philips TV
        command_on: JgAcAB0dHB44HhweGx4cHR06HB0cHhwdHB8bHhwADQUAAAAAAAAAAAAAAAA=
        command_off: JgAaABweOR4bHhwdHB4dHRw6HhsdHR0dOTocAA0FAAAAAAAAAAAAAAAAAAA=

The above example creates switch.philips_tv, which sends IR/RF codes using the universal remote with the MAC address provided.

is the documentation still valid for this or do we now have to configure broadlink switches thru the UI?

If it’s the latter then where is the documentation for doing that?

880

My YAML Broadlink switches are still working with 2022.2.5

1 Like
881

thank you for confirming.

I’m not sure what the other reports were referring to that weren’t working then. :man_shrugging:

882

Thanks, but a restart did not help. I actually did

ha os update

via cli. This immediately looked for and did the OS update to 7.4 (latest)

883

Just figured out how to get my devices back. This was described nowhere in any manual or blog post as far as I can find. And was not even remotely obvious this was the way to make it work. I’m not used to HA being so badly described or making things non-intuitive.

For people who like to know how to get Unifi Network devices back: Go to the integration>configure>second page>enable switch per device (which is totally illogical)>save
I don’t want the switches, so I had to go to every device and disable the switch per device. Then after a while the device_trackers appear again. Not the way I would have designed this, but hey, who am I.

1 Like
884

Someone who can open an issue on Github im case this was an unexpected bug? You ask, I answer.

885

There’s a link at the bottom of every documentation page to offer suggestions for improvements.

886

And @olddawgpowers Probably related to this https://github.com/Cinntax/pyenvisalink/issues/20#issuecomment-1034489625

887

That option must be related to that specific integration only, and not related to this update. I use ASUS-WRT, and that option is not available, so it wouldn’t have been relevant to include in the update docs

888

@DrCoolHands I get the same message after the upgrade but only when I restarted HA. Although it doesn’t fix the problem you can disable Misc alerts by logging into Eyezon - Manage Contacts (select your contact) - Assign Devices - Modify - uncheck Misc - Set Alerts. It looks like it will be resolved as a fix has been submitted.

889

so…now instead of having device_trackers that we have to go into the integration to disable we now have to explicitly enable the switches to get the device trackers that we want and then go into the integration and disable the switches that we don’t want but had to enable to get the device trackers that we do want?

And now every time there is a new device tracker we want to show up in the integration we now have to reconfigure the integration to enable the switch (that we don’t want) for that device to get the device tracker (that we do want) and then disable the switch entity (that we never did want) still resulting in having extra entities associated with the integration even tho we might not want to ever use them?

I was told elsewhere that the Unifi integration was supposed to automatically still create device tracker entities but just not associate them with a device. I guess that info was not correct?

If all that is true then it makes no sense…

why can’t we just select to enable only the device trackers we want to enable directly instead of using the switch as the middle-man?

(haven’t updated yet so all of this is hearsay from other posts. I’ll be glad to be incorrect…)

4 Likes
890

I can’t speak to what others are experiencing… but for me this is exactly how it works. The only devices I have shown under Unifi are known devices from other integrations (i.e. Tasmota or Roku, etc). But all the other entities are listed in the entities section. New device_trackers are automatically created when something new pops on my network. The only difference (a very welcome difference for me) is that they are not enabled by default. no re-configuration needed, just go to the entity and enable it.

Again, can’t speak for others, since I imagine that their networks are set up different than mine (i.e. I don’t have any POE devices).

1 Like
891

OK, then that makes more sense to me. And happy to know I’m wrong! :stuck_out_tongue_winking_eye:

I wonder why the others are experiencing the things they did then? Not knowing where to look to find the entities?

892

@dasbooter @DrCoolHands Just installed 2022 2.6 and it resolved my Envisalink problem.

893

Anyone has a problem with Spotify “The access token expired” error after updating to 2022.2.6

I am getting the error below a lot in my logs:

2022-02-12 08:59:09 ERROR (SyncWorker_6) [spotipy.client] HTTP Error for GET to https://api.spotify.com/v1/me/player/devices with Params: {} returned 401 due to The access token expired
2022-02-12 08:59:09 ERROR (MainThread) [homeassistant.components.spotify] Error fetching Sp4wn Devices data:
2022-02-12 09:04:09 ERROR (SyncWorker_1) [spotipy.client] HTTP Error for GET to https://api.spotify.com/v1/me/player/devices with Params: {} returned 401 due to The access token expired
2022-02-12 09:09:09 ERROR (SyncWorker_7) [spotipy.client] HTTP Error for GET to https://api.spotify.com/v1/me/player/devices with Params: {} returned 401 due to The access token expired
2022-02-12 09:14:09 ERROR (SyncWorker_6) [spotipy.client] HTTP Error for GET to https://api.spotify.com/v1/me/player/devices with Params: {} returned 401 due to The access token expired
2022-02-12 09:19:09 ERROR (SyncWorker_6) [spotipy.client] HTTP Error for GET to https://api.spotify.com/v1/me/player/devices with Params: {} returned 401 due to The access token expired
2022-02-12 09:24:09 ERROR (SyncWorker_6) [spotipy.client] HTTP Error for GET to https://api.spotify.com/v1/me/player/devices with Params: {} returned 401 due to The access token expired

I have checked the client_id and client_secret with Spotify developer app for HA and everything looks good.

894

Yes, I see the same errors…

895

yeah, seeing those spotify issues too , there were some changes in 2022.2.6 about spotify, maybe it was intended :slight_smile:

896

i think this one is causing it?

897

I hear ya! Although I agree with what HA is doing with these (old) binary sensors it does upset the somewhat OCD members by causing “unknown” to appear in the dashboards.

So, if I restart my HAS I make sure next time I pass a “unknown” sensor I trigger it. It then resets to clear. OK for door and motion sensors. Not so good for flood and smoke sensors. So for them I’m taking the “if you can’t fix it, sweep it under the carpet” approach and using the nice new HAC frontend component @piitaya https://github.com/piitaya/lovelace-mushroom and using their type: custom:mushroom-light-card with hidden state and changing the default clicks but retaining the colour change on state change. OCD cured. :laughing:

898

No I’m not. I hate HA GitHub because I can never find the place to put my issue at. To me it looks like one big pile of issues in core category and I just don’t understand that. HA Discord is nicely categorized, but GitHub I can’t figure out. But maybe that’s because I’m not a GitHub guy. Also I don’t understand the HA GitHub bot which is closing issues which aren’t solved.

2 Likes