Beyond the odd zha warnings… no matter how many times I authenticate and restart HA, I keep getting the notification to authenticate my google calendars. And my recorder, logbook, etc. seems to be borked… my MariaDB seems borked. (i3NUC, Ubuntu 18.04, Hassio in docker. Maria installed as Hassio addon on same machine.)
I even wiped and restored yesterday’s snapshot (0.94.4) and while I don’t have to authenticate my calendars, the MariaDB and dependencies all still fail. Any ideas?
Restored 0.94.4, unistalled MariaDB (for the moment), pulled the MariaDB stuff from config.yaml, rebooted and recorder, etc all came back. Will stick with the default for now and will sort MariaDB out later.
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…
