I am also noticing the same thing. My Supervisor says there are no updates beyond 2022.7.0. Here is the output from CLI…
[core-ssh ~]$ ha supervisor update
Processing... Done.
Error: No supervisor update available - 2022.07.0
Have you figured anything out?
That is the latest stable version of supervisor. The current beta version is 2022.08.3.
Since update to 2022.8.x my climate entities (5 honeywell evohome thermostats) not sync to google assistant/home anymore and got remover from my Google Home dashboard after doing the HA update.
Can someone please help I reported the issue twice but seems there is no movement on it.
Logger: homeassistant.components.google_assistant.smart_home
Source: components/google_assistant/trait.py:896
Integration: Google Assistant (documentation, issues)
First occurred: 10:52:55 (20 occurrences)
Last logged: 11:03:49
Error serializing climate.home_family_verrips
Error serializing climate.living_room
Error serializing climate.bedroom_kids
Error serializing climate.bedroom
Error serializing climate.bathroom
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/components/google_assistant/smart_home.py”, line 85, in async_devices_sync_response
devices.append(entity.sync_serialize(agent_user_id, instance_uuid))
File “/usr/src/homeassistant/homeassistant/components/google_assistant/helpers.py”, line 623, in sync_serialize
device[“attributes”].update(trt.sync_attributes())
File “/usr/src/homeassistant/homeassistant/components/google_assistant/trait.py”, line 910, in sync_attributes
modes = self.climate_google_modes
File “/usr/src/homeassistant/homeassistant/components/google_assistant/trait.py”, line 896, in climate_google_modes
for preset in attrs.get(climate.ATTR_PRESET_MODES, []):
TypeError: ‘NoneType’ object is not iterable
If I set my 5 climate entities to “not expose” in manage devices in google assistant settings within Home Assistant Cloud settings then the errors dissappear
So it looks like the problem is within Nabu Casa Cloud
Might have the same, still looking into it.
Using bluetoothctl, I can tell the devices are being “seen”, but they appear as “away” in HA. Also the BLE transmitter on my Android HA-App is on and defintely seen by bluetoothctl multiple times for multiple minutes. No entries showing up in known_devices.yaml though. I’m relatively sure this was the case in 2022.8.2, since my known_devices.yaml went from 550 lines to about 42000 in a day after setting track_new_devices: true.
But, ofc, I might be completely off here.
Thanks. I was assuming that they marked the Supervisor releases on Github as a Pre-Release like they do on Core.
Found this… https://github.com/home-assistant/version/blob/a75d334903d5d5fe8015de9b93e870ba8235d7ea/stable.json
Concerning the Folder platform issue , the camera folder is a nfs file so it could be the problem as another “normal” folder is working fine ( backup )
See initial post #333 above
Yer bluetoothctl is working perfectly fine for me at the OS level, but nothing in the logs from HA to say it is even running a scan, which in 2022.7 it was running fine every 30 seconds (changed from default).
Deffo something to do with the Bluetooth upgrade they’ve done.
Are you able to add the Bluetooth integration? I get an error here as well.
So I just installed a BT stick, it got auto discovered and the integration is configured. Runs fine.
Installed Bluetooth LE Tracker - Home Assistant
like this:
# Trackers
device_tracker:
- platform: bluetooth_le_tracker
track_new_devices: true
track_battery: true
Reboot of the server done.
Nothing happens. No devices discovered, no known_devices.yaml file is created.
No related errors in logs.
HA Supervised, Debian 11, intel machine, no VM’s involved.
Where to start now?
I had the same issue… gave up… So I installed the “Bluetooth Low Energy Monitor Passive BLE monitor” instead.
Works like a charm.
Alarm.com integrations is broken in 2022.8.3.
Retrying setup: 0, message='Attempt to decode JSON with unexpected mimetype: text/html; charset=utf-8', url=URL('https://www.alarm.com/web/api/video/cameras/')
Any luck getting Sylvania Smart+ Bluetooth light bulbs connected using HomeKit Controller? I was able to get two a19 bulbs paired, but any calls for off, on, brightness, or identify seem to fail.
There is a problem resolving services on the SYLVANIA devices. Bluez (the Linux Bluetooth stack) can’t resolve quite a few of them. Bluez is not very forgiving of devices that violate the Bluetooth spec so I expect that’s what’s going on.
AFAIK it’s the only vendor that has the issue.
It’s being tracked here https://github.com/Jc2k/aiohomekit/issues/135
Unfortunately I suspect the answer we will get from the bluez devs when we have enough data to open an issue will be to tell SYLVANIA to fix their Bluetooth implementation
Is anyone experiencing another problem in the GUI with target selection in HUE scene services, Tado, squeezebox, Yeelight and others? It is not possible to select a target, there is simply no selection of an entity, a device.
Yes, I’ve been able to replicate that scenario now too. A few things that I noticed;
I had trouble adding the bluetooth integration initially after upgrade, since I preordered the ZEXMTE BT-505 and had it plugged in. Several attempts op plugging-in/out and reboots solved it for me, and until it was auto-detected.
Yes, I’ve seen that.
Thank you for confirmation. Already reported here:
Seems covers with deconz are broken in 2022.8.1-2022.8.3.
Rolling back to HA core 2022.7 everything works flawlessly, updating to 2022.8 cover position changes simply throw errors.
2022-08-08 08:02:08.011 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 930, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 713, in _handle_entity_call
await result
File "/usr/src/homeassistant/homeassistant/components/deconz/cover.py", line 88, in async_set_cover_position
await self.gateway.api.lights.covers.set_state(
File "/usr/local/lib/python3.10/site-packages/pydeconz/interfaces/lights.py", line 71, in set_state
return await self.gateway.request_with_retry(
File "/usr/local/lib/python3.10/site-packages/pydeconz/gateway.py", line 142, in request_with_retry
return await self.request(method, path, json)
File "/usr/local/lib/python3.10/site-packages/pydeconz/gateway.py", line 167, in request
response: dict[str, Any] = await self._request(
File "/usr/local/lib/python3.10/site-packages/pydeconz/gateway.py", line 194, in _request
_raise_on_error(response)
File "/usr/local/lib/python3.10/site-packages/pydeconz/gateway.py", line 225, in _raise_on_error
raise_error(data["error"])
File "/usr/local/lib/python3.10/site-packages/pydeconz/errors.py", line 73, in raise_error
raise cls(
pydeconz.errors.RequestError: 6 /lights/8/state parameter, lift, not available
I don’t know if anyone has noticed this behaviour, but with each update since 2022.8 I have had to uninstall and reinstall any addons that update. I do not think that’s normal behaviour.