0.103: Happy Holidays, Service calls, StarLine, GeoNet NZ and Proxmox

woody4165 · December 20, 2019, 7:58am

So, since the service calls in my example does not start with media_player.yamaha_ but, for example, it starts with media_player.turn_on and only the entity_id is media_player.yamaha_receiver_salotto I shouldn’t do anything, right?

nickrout · December 20, 2019, 7:59am

I believe that is correct. The test is whether it works as is. Does it?

woody4165 · December 20, 2019, 8:01am

I’ve not test it yet, since I’m going to upgrade and normally I try to prepare all the stuff to avoid any issue.

I will test it and check.

Thanks

tom_l · December 20, 2019, 8:04am

Yeah nick is correct. The easiest way to check is to use your preferred editor’s search function to search your automations and scripts for:

media_player.yamaha_

If it returns no results you’re good to go.

woody4165 · December 20, 2019, 8:12am

I get this

/config/scripts.yaml:
	121:           entity_id: media_player.yamaha_receiver_salotto
	125:           entity_id: media_player.yamaha_receiver_salotto
	130:           entity_id: media_player.yamaha_receiver_salotto
	158:         entity_id: "media_player.yamaha_receiver_salotto"

and I have no automations with media_player.yamaha_*

So since they are “only” entity_id: media_player.yamaha_receiver_salotto I shouldn’t anything as far as I understood…

tom_l · December 20, 2019, 8:13am

Yeah sorry the search should have been:

service: media_player.yamaha_

b4dpxl · December 20, 2019, 9:11am

To be fair to the HA project and team, that wasn’t actually directed at this project. More of a general attitude I see from DevOps/CI processes, including a number of heavily commercial ones that really should be using change controls to not affect their customers (on a Friday afternoon).

Burningstone · December 20, 2019, 10:26am

No one forces you to update, there are a lot of processes, reviews etc., however with such a huge peoject and so many commits there will always be errors. Anyway home assistant is still in beta stage and it should be seen as this.

mikeg1130 · December 20, 2019, 2:37pm

Hey jacobgarder, just to confirm, you were getting the netdisco error before upgrading, but were able to update without any issue? An no issue with the component that was throwing the error?

I am getting the error about 2/3rds of the time for wemo and roku when I run the check configuration add-on, so just want to make sure before I pull the trigger.

jacobgarder · December 20, 2019, 3:39pm

@mikeg1130, correct. I got tthe error :
Package xiaomi setup failed. Component xiaomi_aqara No module named 'netdisco' when I ran the “Check Home Assistant configuration” addon. But I did not see any errors after upgrade.
My environment is Hassio as a docker-instance, running on Ubuntu 18.04.3.

mikeg1130 · December 20, 2019, 3:59pm

Thanks! That’s what I was hoping. Thanks for the confirmation. I’m going to go ahead and update.

Albertowue · December 20, 2019, 4:25pm

I also get 2 alerts when I run “Check Home Assistant configuration”:

Component error: octoprint - No module named “netdisco”
Component error: yeelight - No module named “netdisco”

My current version is at 0.101.3

I have read that other users have this type of error but by updating everything works, is it possible?

bratnetwork · December 20, 2019, 4:34pm

Any known issues with MyQ? I know its a common occurrence that MyQ stops working, but usually, after an update, it works again. My MyQ has been down for a few days, but after update 103.2 it still is not working.

Albertowue · December 21, 2019, 10:41am

Even testing version 0.103.3 I get the same alerts with “Check Home Assistant configuration”, but as reported by other users by updating everything worked correctly

TazUk · December 21, 2019, 2:36pm

Upgrade from 102.3 to 103.3 this afternoon on a venv installation (Python 3.7.5 in Ubuntu Server 18.04).

My konnected component failed setup on starting HA which I traced to a missing netdisco module.
First time I used the check_config script - very useful

A quick python3.7 -m pip install netdisco in the venv resolved it and I’ve raised the issue on github for root cause to be handled down the line.
Just thought I’d post here for the convenience of others.

iRobert · December 21, 2019, 6:58pm

For me as well, Tuya lights not working anymore.

Codec303 · December 23, 2019, 1:26am

Does your log mention anything?

TryingHA · December 23, 2019, 4:13pm

Anyone else lose the binary sensor function of the August lock after the 103.4 upgrade? I have tried removing and re-adding the lock but no luck so far. It worked up until now.
Edit: It fixed itself this morning after like the 5th reboot since the patch.

wamfox · December 24, 2019, 12:55pm

Same issue here, no control over the device from love lace but my automatons with the Tuya bulb still seem to be working. Very strange…

Steven_Rollason · December 24, 2019, 1:40pm

This may not be anything to do with 103 (I still had issues when I rolled back).
Look at this issue. It seems like something changed in the Tuya API for RGB bulbs.
That issue has a link to is a patched version of the light.py from the tuyaha package, which appears to allow it to work. The only limitation being that HA cannot tell what colour a bulb is set to.
As a workaround, there is also a patched version of light.py from the Tuya component linked to from that same issue, which saves the current colour when changing colour through HA.