I’ve had situations where following an OS uprade, the version listed in supervisor is the old version. All of these types of issues (for me at least) appear to disappear and correct themselves following a restart of the Core). After a restart, the OS 7.3 upgrade finally showed, and I was able to upgrade. Just some bug somewhere, likely. Restart and see if that solves it.
Was that really necessary? Aren’t hostilities already high enough here? 
4 Likes
Thanks Francis for the idea. I use MQTT Explorer a lot previously. I solved my issue by creating a YAML file and telling HA configuration to look at the file. Worked a treat (until HA break that option).
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?
My YAML Broadlink switches are still working with 2022.2.5
1 Like
thank you for confirming.
I’m not sure what the other reports were referring to that weren’t working then. 
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)
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
Someone who can open an issue on Github im case this was an unexpected bug? You ask, I answer.
There’s a link at the bottom of every documentation page to offer suggestions for improvements.
And @olddawgpowers Probably related to this https://github.com/Cinntax/pyenvisalink/issues/20#issuecomment-1034489625
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
@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.
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
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
OK, then that makes more sense to me. And happy to know I’m wrong! 
I wonder why the others are experiencing the things they did then? Not knowing where to look to find the entities?
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.
Yes, I see the same errors…
yeah, seeing those spotify issues too , there were some changes in 2022.2.6 about spotify, maybe it was intended 