Bug: JBL Link 20 blocking integration setup #8
Comments
|
This seems to be a ssl certificate error |
Oh that is super interesting. I do sadly not have any of those devices to debug this. This integration just uses the googledevices library for communication and sadly does error handling on its own: https://github.com/ludeeus/googledevices/blob/master/googledevices/helpers.py#L88 Can you code and setup a small test project directly using googledevices to debug this? That said, one device doing this should not block the whole integration, so there is definitely room for improvement here. Something along these lines might be helpful: logger:
default: info
logs:
custom_components.googlehome: debugand then post a new log with more context please. Especially whats happening right before all those calls fail would be super interesting. |
Also are you absolutely certain, that the integration is never finishing setup? But depending on the amount of setup devices in your home, it might need to try a lot of tokens until it finally fails: https://github.com/Drakulix/googlehome/blob/master/custom_components/googlehome/__init__.py#L89 This might block for some time resulting in the log message |
|
Hmm I dont really remember, I used the olde integration but i dont think i ever tried with the JBL Link 20. Here is the full log, i removed everything from googledevices since it contains some sensitive information, let me know if you need that aswell and ill try to clean it up. 192.168.20.21 is the Link 20
I think it might actually set up properly after a while, but all the entities in Home Assistant are marked as unavailable |
Confusingly this is normal and just how the old integration did work. You can confirm this, by setting any alarm/timer and checking HA again. |
|
Ahh i see, i will test in a bit when i get home. I actually made my own implementation of this using an android VM, but in that version i set the state to active/inactive and kept all the timers and alarms in attributes so i forgot how it used to work |
Also not a bad idea. So if it really is working on your end, remaining is mostly an upstream issue with the JBL Link 20 then? |
Just tested, works fine, but i would really need an option to ignore the Link 20, as it takes Home Assistant 70 seconds to start up. I could try and make a pull request if you would be open to changing the logic to active/inactive and keep timers and alarms in attributes so we have something to discuss around |
I just hijack the discover process of the cast-integration, as every google home device is also a google cast and then check, if they respond to the local api (which all of them including chromecasts do) and check their capabilities to figure out, if they have bluetooth and support alarms/timers. I am honestly quite surprised, that the JBL Link is an exception to this. I have some ideas to speed up discovery, so this is not so painful anymore. Other then that, explicitly ignoring devices could be done via IPs (assuming those can be static/reserved in your setup). However this integration does all its config via the UI and I do not know, if there is a nice way to let the user specify an IP list. But I guess a text field could be added to the OptionsFlow that may contain a list of IPs to ignore in the discovery function.
That would be really nice. Much appreciated. |
I'm trying to setup 0.3.3, but no entities are created by the component.
I get lots of these errors in my log, any idea whats causing it?
Edit: After a closer look it seems that my first-party Google Home and Google Mini is discovered correctly, but the Google home thats causing trouble is a third-party one, a JBL Link 20.
However it seems to be blocking all the other sensors from updating sadly.
The text was updated successfully, but these errors were encountered: