0.114: Dark mode, Open Z-Wave progress and more automation & scripts

I am getting this message in the logs when trying to upgrade. Anybody has any ideas?

20-08-12 17:05:57 ERROR (SyncWorker_1) [supervisor.docker.interface] Can’t install homeassistant/qemux86-64-homeassistant:0.114.0 -> 404 Client Error: Not Found (“no such image: homeassistant/qemux86-64-homeassistant:0.114.0: No such image: homeassistant/qemux86-64-homeassistant:0.114.0”).

Check your available disk space. You don’t have enough to download the update.

This happens multiple times every release. Can we get the error message changed?

6 Likes

Unless you run it native on a Intel/amd machine ( they normally have enough diskspace), I guess you are using a download VM image ‘as-is’. These only have 6 Gb allocated, much to little for upgrades.

Oh yes, sorry, wanted to reply to the parent comment. My bad.

1 Like

Spot on guys - expanded the hard drive on a VM and all is working. Thank you very much!

1 Like

For some reason after upgrade to 0.114 my maria-db Add-on was gone. After re-install and configuring it all errors went away.

Hope this helps somebody also

Good job with upgrade guys

Same issue. Renamed db and restarted. Solved but data lost. No issue for me.

It’s a docker error.
But now with the newer supervisor versions, you get a more descriptive message in addition https://github.com/home-assistant/supervisor/pull/1868/files#diff-e654c19533cb0dabbb7ffa9ca64ee24bR105

1 Like

Just so it doesn’t confuse others as it did me, my Pi 4 based system took a while to normalize. I have MariaDB off box, HACS, and a bunch of custom components. HACS and the custom components took a LONG time to finally show up on their own after the update. I was looking into it as something was wrong and noticed they just showed up.

Thanks to everyone for the hard work! Love the new performance and OZW features.

You can do it either way, so whatever is preferable for your situation. There are advantages and disadvantages to each approach :slight_smile:

I think setting it to “auto” is the simplest way for most users. Installing themes can be a daunting process for beginners (YAML, frontend.reload_themes service, etc). Now in 0.114 they can just use the color picker to make quick customizations in seconds, and let their OS handle all of the light/dark theme switching logic - something they already likely set up previously. And since it’s the default theme, they’ll never have to worry about breaking changes / updating theme variables, it always just works.

If you desire more extensive theme customizations or have older operating systems and devices that don’t support dark mode, the automation method would still be preferable in those cases of course.

1 Like

This issue is still present in this version:

This code works fine:

sunrise:
  alias: Sunrise
  mode: single
  sequence:
  - repeat:
      sequence:
      - data:
          brightness_step: 2
          entity_id: light.sonoff
        service: light.turn_on
      - delay:
          seconds: 1
      until:
      - condition: template
        value_template: '{{ repeat.index >= 124 or states.light.sonoff.state
          == ''off''}}'

And this one stops after one pass:

sunrise:
  alias: Sunrise
  mode: single
  sequence:
  - repeat:
      sequence:
      - data:
          brightness_step: 1
          entity_id: light.sonoff
        service: light.turn_on
      - delay:
          seconds: 1
      until:
      - condition: template
        value_template: '{{ repeat.index >= 124 or states.light.sonoff.state
          == ''off''}}'

THANKS A LOT guys! :partying_face: :clap:

Installation went very smooth, as usual.

You’ve read my mind: was thinking not so long ago that it would be a nice feature to be able to move cards to other dashboards

I have upgraded from 0.112.5 then 0.113.3 to 0.114 and observed an increase of my CPU utilization from ~50% (I run a lot of deep learning inferences) to 90%. A bit of a head scratcher as I was expecting something in the opposite direction…

0.114 not working with Sonoff.

same here after the update.
Running on Synology 918+ in Docker.
System was fine with 0.113.3 and before…

20-08-12 00:20:58 ERROR (MainThread) [supervisor.docker] Docker storage driver btrfs is not supported!
20-08-12 00:20:58 ERROR (MainThread) [supervisor.docker] Docker logging driver db is not supported!
20-08-12 00:20:58 CRITICAL (MainThread) [supervisor.core] System running in a unhealthy state. Please update you OS or software!

Try something like this as your shell_command:

shell_command:
  dobiss_server: nohup python3 /config/python_scripts/dobiss_server.py $1 > /dev/null 2>&1 &

That should make it run in the background. I tested this with a Python script with deliberate delays and it ran without issues.

2 Likes

Interesting.

Working in FireFox and Chrome, not in Safari, on a Mac.

same problem here. I went back to 113.3 and everything is ok. I would not want to lose my history (it is an asset for me and I use it for stats and house energy policies). any suggestions other than deleting the db?

0.114 is deleting my custom_components folder. Took me a few restore to understand it. Bad 114!

thanks, this is working ! no need anymore to load shell component as custom
thxn a lot m8!