I figured that was what it was referring to but I wasn’t entirely sure since I thought that was already included in an earlier release (v0.94.1) and that contained the actual potential breaking change since automations wouldn’t be restored in the same way they were previously.
However, it’s not entirely clear from that post, the docs or the breaking change notification what was actually (or even potentially) “breaking” in this release.
I now see that it is at least mentioned in the PR. But many people don’t read the release notes and even significantly less are going to then dig into the PR itself that the release notes are based on.
Again, I don’t see how a “breaking change” that could potentially affect the single most important aspect of any home automation system is given such a quick glossing over in the release notes.
Luckily it wasn’t actually very likely to “break” anything in the vast majority of peoples systems so that was at least a good thing.
Hopefully when the person who handled the breaking changes notifications in the last few releases returns we can go back to the very informative way in which they were presented.
Guess I jumped the gun sort of. Google Assistant is still working with my devices on HA after updating to 95.0, but now I’m unable to sync new devices. I added AdAware to my configuration, added the integration and tried synchronizing devices to allow being able to turn on/off filtering etc from Google Assistant and it’s not synchronizing. I’m getting the following errors:
Error handling message {'inputs': [{'intent': 'action.devices.SYNC'}], 'requestId': '8977511453857797977'}: {'errorCode': 'unknownError'}
Unexpected error
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/google_assistant/smart_home.py", line 55, in _process
result = await handler(hass, data, inputs[0].get('payload'))
File "/usr/src/homeassistant/homeassistant/components/google_assistant/smart_home.py", line 86, in async_devices_sync
async_get_entities(hass, data.config)
File "/usr/src/homeassistant/homeassistant/components/google_assistant/helpers.py", line 119, in sync_serialize
entity_config = self.config.entity_config.get(state.entity_id, {})
AttributeError: 'NoneType' object has no attribute 'get'
The release notes say that the new proactive state reporting “allows you to create routines inside Amazon powered by your Home Assistant entities”. I have enabled this (the Enable State Reporting option under Alexa in the cloud configuration), but when I create a routine in Alexa, the option to trigger a routine from a device still shows “We were unable to find any supported devices.”
Are there only certain types of entities which are supported for this, or is there something else I need to do to get this to work?
I feel some breaking changes are more broadly impactful than others. For example, this particular one stands a chance of affecting any user who has attempted to use last_triggered in a template. In previous versions, they may have given up because they noticed it was unreliable (sometimes it would “mysteriously” have no value) and resorted to using workarounds. In contrast, a breaking change in some obscure integration will only affect a handful of people.
The solution would be to categorize the breaking changes into two categories like Major and Minor. You’d need a broad understanding of Home Assistant to properly categorize them and I assume people with this kind of knowledge are probably engaged with more pressing tasks. Or not. I don’t know who handles the documentation of breaking changes but maybe this is an idea they can consider.
Frankly, I think the correction of the restoration feature (in 0.94.1), although not a breaking change, had wide implications for all users. Finally people could stop using initial_state like a charm to avoid having all automations turned off. But I digress …
Correct. Sometimes we tag something as a breaking change because it might impact some people. In this case, all that is happening is that when initial state is set, we restore last triggered. It is what most people expect to happen, but because it wasn’t before, we tag it as a breaking change.
That’s what was confusing in that this one was the breaking change and the other one wasn’t even tho the other had the possibility to completely change how automations got restored/initialized and how people would need to (re-)code their config.
Here too, Xiaomi-Aqara gateway is giving me invalid config in 95.1. Was working fine in 94.4. I also updated the firmware earlier today, so not sure what has caused the invalid config, home assistant update or xiaomi firmware update.
I’d tried that and it didn’t work until changed the device_class for the sensor to door and it then started working. Searching, I found this which said that, when this was supported with the manual setup in 0.85, the only device classes supported were door, garage_door, opening and window. Are these still the only supported classes in the cloud component, or are any more supported?
Has someone made the google_cloud tts component to work?
Followed all instructions and check configuration display a “Platform not found: tts.google_cloud” message.
Weird, component code seems to be ok. The associated PR on github seems good to…
From what I learnt in the forums, Sandisk cards were the most unreliable cards for HA?
Why the SanDisk links then?
Planning to upgrade Rpi2 with Samsung evo plus to Rpi4 with a good SD card.
Is there a consensus on the “best” micro SD card for hassio on Rpi?
@JS1 I’ve got the xiaomi gateway working again. Don’t know why, but these are the steps I took. First, I decided to check the key, so I checked the xiaomi app on my android device. After selecting the gateway, wait for a short while, then go to the three dots, select about and then Wireless Communication protocol. I checked the key with my configuration file, all was correct (no changes made). Then I restarted home assistant, and… up and running again.
No clue why it’s working now. May be the wireless communication protocol was triggered by checking it. I really have no idea, but it works fine now. Give it a try.
New AdGuard functionality doesn’t seem to be working for me unfortunately @frenck whenever I go to configure > integration it shows up as a discovered service but then just says “Failed to connect” when I press Configure then Submit. Are there any logs anywhere that would help me debug?
arch armv7l
dev false
docker true
hassio true
os_name Linux
python_version 3.7.3
timezone Europe/London
version 0.95.0
virtualenv false
I already had AdGuard installed from the community adding prior to upgrading to .95
whenever I go to configure > integration it shows up as a discovered service but then just says “Failed to connect” when I press Configure then Submit. Are there any logs anywhere that would help me debug?