Thanks miji2, your comment got me sorted, I was unable to update from 0.109.6 and could not find any issue in the logs. After seeing your post, I went through my configuration and found I had some ONVIF code left over from my last camera. I deleted it and made another attempt at updating HA, this time it went like a dream.
1 Like
I was able to update the host system to HassOS 4.10 but when I try to update to HA 0.110.6 I get this error: ERROR (SyncWorker_1) [supervisor.docker.interface] Can’t install homeassistant/qemux86-64-homeassistant:0.110.6 -> 404 Client Error: Not Found (“no such image: homeassistant/qemux86-64-homeassistant:0.110.6: No such image: homeassistant/qemux86-64-homeassistant:0.110.6”).
Is there a way to update it manually?
Just a minor thing, but I noticed release 0.110.7 in HA Supervisor and two times ‘Release 0.110.6 - June 8’ at https://www.home-assistant.io/blog/2020/05/20/release-110/
Is the second 110.6 actually 110.7?
Search the forum for: “404 Client Error: Not Found”
1 Like
The conflict came from another direction in the end. With the new ONVIF integration I had not removed my old configuration and this stopped HA from starting at all. Once I had sorted that out everything worked as normal. It had worked without removing it in release 0.109.
I use separate files for each domain and commented out each domain in my configuration file. Then I turned them on one by one re-booting between each to find out which was crashing HA. As luck would have it, it was the very last domain I turned back on. 
#=============================================
#
# Includes
#
#=============================================
#alexa_media: !include alexa.yaml
automation: !include automations.yaml
binary_sensor: !include binary_sensors.yaml
cloud:
cover: !include covers.yaml
entity_controller: !include entity_controller.yaml
geo_location: !include earthquakes.yaml
google: !include google.yaml
group: !include groups.yaml
hacs: !include hacs.yaml
influxdb: !include influxdb.yaml
input_boolean: !include input_boolean.yaml
input_select: !include input_select.yaml
input_number: !include input_number.yaml
#input_number: !include input_slider.yaml
light: !include lights.yaml
#logger: !include loggers.yaml
media_player: !include media_players.yaml
mobile_app:
notify: !include notify.yaml
octoprint: !include octoprint.yaml
proximity: !include device_proximity.yaml
#scene: !include scenes.yaml
script: !include scripts.yaml
#script: !include test_scripts.yaml
securitas_direct: !include securitas_direct.yaml
sensor: !include sensors.yaml #octoprint_sensors.yaml
#shell_command: !include shell_commands.yaml
switch: !include switches.yaml
weather: !include weather.yaml
#weblink: !include weblinks.yaml
zone: !include zones.yaml
Of course it was. I think that’s one of the rules of troubleshooting. 
Yeah it’s different, 110.7 released today with just an iOS app fix. Corrected the blog post now, thanks for the heads up.
2 Likes
Any Plans to better the Evovac’s integration ?
must have missed it elsewhere but will this fix also fix the newly added log spam which was added in 110.6 about every second for all of my registered apps (devices) for:
2020-06-10 09:37:56 ERROR (MainThread) [homeassistant.components.mobile_app.webhook] Received invalid webhook payload: required key not provided @ data['state']. Got None
2020-06-10 09:37:56 ERROR (MainThread) [homeassistant.components.mobile_app.webhook] Refusing to re-register existing sensor last_update_trigger!
2020-06-10 09:37:56 ERROR (MainThread) [homeassistant.components.mobile_app.webhook] Refusing to re-register existing sensor geocoded_location!
2020-06-10 09:37:56 ERROR (MainThread) [homeassistant.components.mobile_app.webhook] Refusing to re-register existing sensor activity!
2020-06-10 09:37:56 ERROR (MainThread) [homeassistant.components.mobile_app.webhook] Refusing to re-register existing sensor battery_level!
2020-06-10 09:37:56 ERROR (MainThread) [homeassistant.components.mobile_app.webhook] Refusing to re-register existing sensor battery_state!
2020-06-10 09:37:56 ERROR (MainThread) [homeassistant.components.mobile_app.webhook] Refusing to re-register existing sensor pedometer_avg_active_pace!
2020-06-10 09:37:56 ERROR (MainThread) [homeassistant.components.mobile_app.webhook] Refusing to re-register existing sensor pedometer_distance!
2020-06-10 09:37:56 ERROR (MainThread) [homeassistant.components.mobile_app.webhook] Refusing to re-register existing sensor pedometer_floors_ascended!
2020-06-10 09:37:56 ERROR (MainThread) [homeassistant.components.mobile_app.webhook] Refusing to re-register existing sensor pedometer_floors_descended!
2020-06-10 09:37:56 ERROR (MainThread) [homeassistant.components.mobile_app.webhook] Refusing to re-register existing sensor pedometer_steps!
2020-06-10 09:37:56 ERROR (MainThread) [homeassistant.components.mobile_app.webhook] Refusing to re-register existing sensor connectivity_bssid!
2020-06-10 09:37:56 ERROR (MainThread) [homeassistant.components.mobile_app.webhook] Refusing to re-register existing sensor connectivity_connection_type!
2020-06-10 09:37:56 ERROR (MainThread) [homeassistant.components.mobile_app.webhook] Refusing to re-register existing sensor connectivity_ssid!
2020-06-10 09:37:56 ERROR (MainThread) [homeassistant.components.mobile_app.webhook] Refusing to re-register existing sensor connectivity_sim_1!
That one is fixed in the beta and shipping with 0.111
1 Like
ok thanks Frenck, though 0.111 has a major breaking change too… https://github.com/home-assistant/core/pull/35671
Can we already discuss 0.111 on the community? No thread yet but this might warrant an extra discussion before updating… (need to know if last_triggered is set when the automation is triggered (triggers matching kicking the automation, or is last_triggered set, when triggers match And the conditions evaluate to true and pass). As is the case now. If the former, we have to rewrite many many automations…
From personal experience it appears to not be set until the actions have been completed.
ok thanks, will have to wait and see though, as it is marked a Breaking Change, and the discussion on the PR is not as clear as is could be.
Since this is the motivation for the PR in the first place:
Set
last_triggeredattribute of automation at the moment it’s actually being triggered, not after the automation has finished.
which would be contrary to what you describe, and exactly what I fear in the question above, breaking with what is used now.
At the moment it is set when the actions finish. This is bad. If you want to limit the frequency at which an automation can run you have to offload the actions to a script so the automation completes in a timely manner.
After that PR is implemented this offloading to a script wont be necessary. This is good.
1 Like
this is not true is it? currently the last_triggered is set when an automations passes the condition block, and fires the action block. Depending on the (number of) actions (services, scripts with subscripts, delays or wait templates, what have you) the action block can take a very long time. The last_triggered is already set however.
This is not the way I’ve experienced it. Or maybe it is and the problem I have is that I need the last triggered to be available in the current condition block to limit the rate at which the automation can fire.
Either way the new method is good.
Thanks! Was using a VM (Hyper-V) and had to start from scratch increasing the VM disk size before its first boot.
Were you able to resolve this? I’m still having this issue. Looking at the logs, it looks like it can’t find my certs. I’ve tried to move them to the root config directory and still no dice. I’m rolled back for now.
Yes, I changed the following in my configuration.yaml file:
keyfile: caseta.key
certfile: caseta.crt
ca_certs: caseta-bridge.crt
To:
keyfile: /home/homeassistant/.homeassistant/caseta.key
certfile: /home/homeassistant/.homeassistant/caseta.crt
ca_certs: /home/homeassistant/.homeassistant/caseta-bridge.crt