Every two weeks, the community forum gets an upgrade thread and the chance to learn more about its members. It’s like a psych test for astronaut training. When faced with adversity, there are the ‘steely-eyed missle men and women’ who collaboratively ‘work the problem’ … and those who throw up their arms in frustration. Same old, same old.
And now for a Walter Mitty moment:
Imagine you’re bound for Mars. Mission Control just uploaded the latest software to control the environmental system. It’s not working to plan. Shall we fix it together? Or will you float off to your bunk and hate-text Mission Control?
Next time your spouse asks what you’re doing with Home Assistant, you can respond: “Getting us to Mars!”
Oh and a big thanks to the development team at Mission Control! A few rough patches here and there but they’ll get smoothed out soon enough. Nothing that we can’t resolve together.
Invalid config for [automation]: not a valid value for dictionary value @ data['action'][1]['entity_id']. Got None. (See /config/configuration.yaml, line 257). Please check the docs at https://home-assistant.io/components/automation/
The line it refers to in my config is this:
group: !include group.yaml
I appreciate all the dev’s do but it is very apparent that “never delay the launch” is the priority versus “failure is not an option!” which leads to the noise you describe.
I suspect if those wanting and able to “work the issues” would actually test the betas so the issues get identified (and solved) before release it would help significantly.
Breaking changes to core automation concepts like time is something that requires careful consideration and user communication. Reading through the PR, the entire conversation centers around how much easier the change will be for developers, without a single reply mentioning the user experience.
I understand that components, on initial submission, might not have been completely thought out and on occasion require a breaking change. But basic automation triggers are deeply embedded into people’s environments and projects. Changing them without notifying the users ahead of time, or providing a transition period, speaks volumes to the development process - the decision is made by developers for their own reasons (however valid), but with no input from the user community.
Meanwhile, everyone who had automations set to trigger on set intervals will find that Home Assistant no longer functions, and everyone who published projects which included such functionality now needs to publish two versions or force everyone to upgrade Hass.
I come back to 0.85.1 after 10 minutes.
I hope the issues on the configuration files will be resolved, or that a guide about what you have to change in config files will sort out.
As already said, the log gave no useful indications, at least to my eyes.
I agree but my version was given the Hollywood treatment to add some suspense-filled drama to the narrative.
Not that there was any shortage of drama during the Apollo program!
Apollo 11: Error 1201, 1202. Computer overload warning due to malfunctioning radar-based ground-ranging system … all while descending to the lunar surface for the very first manned landing.
And of course who can forget Apollo 12’s classic “Try SCE to AUX.” Lightning strike during the Saturn V’s initial ascent negatively impacted electrical systems. The linked article does a great job of recounting this white-knuckle moment … and demonstrates the qualities needed in the personnel responsible for trouble-shooting mission and time-critical problems.
… and here we are, flustered by stuff that just makes our lives more comfy.
Ha ha but you must have a tolerant wife! In our household automation was a tough sell and “failure is not an option…” is very real.
The only difference is the repercussion; in my case the NUC just gets shutoff and hidden somewhere until I convince the family “No, lights won’t turn on in all rooms in the middle of the night again I promise…” and get the NUC given back to me
EDIT: Nevermind! I’m a genius and forgot that I had multiple triggers that were using time instead of time_pattern and needed to be updated. All good now.
I updated my trigger for time_pattern, however the configuration validation is still flagging this as an error. The automation component seems to load properly now that I’ve updated the code, but it seems like something with the config validation needs to be updated as well? Anyone else seeing this?
I started automating our home back in 2006. I learned soon enough that you need a ‘production system’, to run the house, and a separate ‘test system’ for experimentation. You only need to experience your ‘pride and joy’ fall flat on its face in front of others (spouse, family, guests, etc), typically during a demo (of course), to learn you need to isolate production from test.
I won’t bore people about ‘the old days’ but it’s so much easier nowadays (inexpensive single-board computers, old netbooks, virtual machines, docker, etc) to have one or more test-beds where you can cleanly ‘squash bugs’ without affecting the production system.
– soapbox on –
Open-sourced software that gets upgraded every two weeks is a double-edged sword. You get free improvements and new functionality … along with breaking changes and bugs. Given this combination of carrot and stick, even if you’ve diligently read and adapted for all breaking changes, you’re still taking a gamble installing the latest release on your production system. To maintain your psychological health, and familial relations, use a separate test system.
– soapbox off –
Has anyone successful got GPS Logger working through Cloud Webhooks? I finally got it working OK as a component webhook (to my local domain), but if I enable the webhook under the cloud section and replace my URL with the nabu casa URL, GPS Logger gives me (can’t copy paste it so reproducing it): Unexpected response code Response {protocol=h2, code=500, message=, url=https://hooks.nabu.casa/xxxxxxxxxxx}
Home Assistant throws this error:
Error handling message
Traceback (most recent call last):
File “/usr/src/app/homeassistant/components/cloud/iot.py”, line 237, in _handle_connection
hass, self.cloud, msg[‘handler’], msg[‘payload’])
File “/usr/src/app/homeassistant/components/cloud/iot.py”, line 293, in async_handle_message
return (yield from handler(hass, cloud, payload))
File “/usr/src/app/homeassistant/components/cloud/iot.py”, line 366, in async_handle_webhook
body = body.decode(‘utf-8’)
AttributeError: ‘StringPayload’ object has no attribute ‘decode’
I set the HTTP body and headers correctly and it is set to POST not GET. Again, it works fine connecting locally, but as soon as I change to the Nabu Case URL, I get these errors.
Yes, having a play system for testing is great. The problem is with zwave and such it’s hard to have that multi-homed so the testing is actually real world enough. I likely will setup a small test system just for my home office and move those switches and sensors over to get a reasonable test environment.
