I am having some problems with sonarr which I have set up via YAML. The documentation for Sonarr set up no longer mentions YAML set up.
I see that it’s now possible via UI, but would prefer to keep it via YAML where possible. Has this option been removed? If so, should it be mentioned as a breaking change?
Sonarr is only via GUI now. No YAML. It would have been automatically migrated except they renamed one of the sensors and none of them are enabled by default - you need to manually enable the entities. Yes I reported this in the beta but no one cared. Yes it was/should have been a breaking change and I did point it out.
Hi.
My setup notified me on possible update from 0.111.1 to 0.111.2. After I start update, there is an error:
Error: 504 Gateway Time-out
504 Gateway Time-out
nginx/1.14.0 (Ubuntu)
and in log I can see:
ERROR (SyncWorker_0) [supervisor.docker.interface] Can’t install homeassistant/qemux86-64-homeassistant:0.111.2 → 404 Client Error: Not Found (“no such image: homeassistant/qemux86-64-homeassistant:0.111.2: No such image: homeassistant/qemux86-64-homeassistant:0.111.2”).
Previous updates went without problem.
Have anyone encountered such problem?
My setup is ubuntu 18.04 on NUC, and HA runs as virtual machine in virtualbox.
Here is Developer tools info:
System Health
arch x86_64 chassis vm dev false docker true docker_version 19.03.8 hassio true host_os HassOS 4.10 installation_type Home Assistant os_name Linux os_version 5.4.44 python_version 3.7.7 supervisor 227 timezone Europe/Warsaw version 0.111.1 virtualenv false
Best regards,
Piotr
After upgrade to 0.112.1 some issues:
2020-06-14 11:48:26 WARNING (MainThread) [homeassistant.components.climate] Setup of climate platform netatmo is taking over 10 seconds.
2020-06-14 11:48:26 WARNING (MainThread) [homeassistant.components.sensor] Setup of sensor platform netatmo is taking over 10 seconds.
Please read this release notes topic. An issue has been raised and a PR to fix it has been merged for release in 0.111.3
Not enough diskspace. If you used the downloaded vmkd, it is only 6Gb, which is too little. You will need to expand it.
@tom_l, not sure which release note are you referring to… Up to 0.111.1 everything was fine and for 0.111.2 the only DB relates change is: Fix history timezone with postgres and other dbs.
However issue mentioned is described as:
@francisp Thanks. I was thinking that could be the problem.
I can see the image is available from docker hub (pulled without problem using some other docker installation), but image is almost the size of space left on VM.
Could you direct me to some instructions on growing vbox image? I would like not to damage my Hass OS setup 
Also, are there any recommendations for disk usage maintenance, like removing/archiving old logs and so on?
Best regards,
Piotr
Hi, firstly, thanks for all the hard work.
I just thought I’d point out that for some people
"Fix command line sensors removing quotes with template ([@shenxn]- [#35559]) "
Is a breaking change, and should have been labelled as such.
If you were using \" in order to use quotes, then this change breaks it.
I had a number of command line sensors using curl that all broke as a result - no big deal, but it helps to know
Thanks - In which case I’ll add it via GUI.
The history cards were fixed in https://github.com/home-assistant/core/pull/36769 but that hasn’t been released yet. Will make it to 0.111.3, presumably.
Is there somewhere an explanation about this ?
Ha auto-discover my 2 Aqara Gateway’s but the link is about the vacuum cleaner
Is the method described to get the 32 digits Key is also for Aqara Gateway ?
Yes, don’t worry about the vacuum cleaner link. Its because the vacuum cleaner has had this method to get the token for a long time now. The integration config flow is correct and we just need to follow what it says to do.
When you see a breaking change get missed like this the most helpful thing you can do is update the blog post and mention this. Anyone can go on github and submit a quick update for this. Sometimes things slip through the cracks and we need to help identify that.
Next time that happens just submit an update to the blog post calling it out. I submitted an update to add Sonarr to the config flow but forgot about the breaking change part.
Same for me, checked the hardware list from the Supervisor/System page and it wasn’t there. Quick shutdown of VM, replugged the dongle on host to be sure and all is fine again.
Thanks for the heads up
After a hunt around GitHub I found the right place and submitted a PR
I lost my Tibber Pulse (consumption, volt etc) after upgrading to 0-111-0.
[sensor.electricity_price_xxxxx] worked OK, but
[sensor.real_time_consumption_xxxxx] was Unavailable
Downgraded to 0-110-x and both were back OK.
Upgraded to 0-111-2 again today and consumption gone again.
Anyone using Tibber Pulse without problems in 0-111-x?
Not only is Wemo discovery broken. Even if you change to Static discovery and add the devices, when the devices are toggled on lovelace to on, the wemo device would turn on but the toggle on the lovelace ui will auto toggle off instantly for a few seconds before the ui is switched to on again
Since upgrading from 0.110.x to 0.111.x (currently on 0.111.2) I now get an error setting up panel_custom.
Log Details (ERROR)
Logger: homeassistant.setup
Source: components/http/init.py:376
First occurred: 14 June 2020, 11:23:01 (1 occurrences)
Last logged: 14 June 2020, 11:23:01Error during setup of component panel_custom
Traceback (most recent call last):
File “/usr/src/homeassistant/homeassistant/setup.py”, line 190, in _async_setup_component
result = await asyncio.wait_for(task, SLOW_SETUP_MAX_WAIT)
File “/usr/local/lib/python3.7/asyncio/tasks.py”, line 442, in wait_for
return fut.result()
File “/usr/src/homeassistant/homeassistant/components/panel_custom/init.py”, line 180, in async_setup
hass.http.register_static_path(url, panel_path)
File “/usr/src/homeassistant/homeassistant/components/http/init.py”, line 376, in register_static_path
self.app.router.add_route(“GET”, url_path, serve_file)
File “/usr/local/lib/python3.7/site-packages/aiohttp/web_urldispatcher.py”, line 1036, in add_route
expect_handler=expect_handler)
File “/usr/local/lib/python3.7/site-packages/aiohttp/web_urldispatcher.py”, line 308, in add_route
“registered”.format(route=route_obj))
RuntimeError: Added route will never be executed, method GET is already registered
i don’t see any issue with wemo.
Discovery is acting weird but I have no way to show it since after switching to static discovery everything worked ( discovery wise) however the of behavior i was talking about is hard to describe so i posted an unlisted youtube video on it. https://youtu.be/Ixk68waLWy0
As you can see in the video, the wemo switch automatically turns off after i turn it on. The “desk” device does turn on btw its jsut the switch toggles itself back to off ( the light stays on). Then after a while it toggles to on again matching the true status of the light.
Side note: turning a device off doesn’t not produce the same effect. it is just for turning wemo devices on. also i found a github thread on this as well https://github.com/home-assistant/core/issues/36632