New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dependency for mqtt component does not work as expected #92297
Dependency for mqtt component does not work as expected #92297
Comments
Hey there @emontnemery, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) mqtt documentation |
@jbouwh asked in #92236 (comment)
i do, actually. first came the fritz integration to my mind, which takes about 140 seconds. when i looked again, there’s the xiaomi_miio_fan integration that takes a staggerin 862 seconds — although it was deactivated in the frontend. as far as i understand, none of the above mentioned intergrations use mqtt and after startup, mqtt usally is up shortly after the fritz integration is up. i never see any mention of the xiaomi_miio_fan integration in the startup notificaton („HA has not initialized completly, starting xxx“). |
Okay, any other integrations in |
It seems your xiaomi_miio_fan takes a long time to set up. Could you test what happens during setup if you temporary disable this integration? |
deactivating xiaomi_miio_fan in my configuration (instead of only deactivating it in the frontend) does not help, snips won’t start without the snips-integration check for MQTT availability. i also observed that the error („[snips] could not be set up“) is occuring before the fritz integration is even shown to be inializing. so, as you said, it’s probably some other plattforms that MQTT tries to set up, that might take time. i have one more integration that directly utilizes mqtt: owntracks
and also lots of mqtt subscriptions as triggers
however HA reports 0.14 seconds startup time for automation |
It is that xiaomi_miio takes more than 300, after that the dependencies might not work any more. To test disabling the xiaomi_miio integration you should disable all entries. The device triggers will startup normally as they are platform setup's. |
yes, that’s what i did, disable all entries of the xiaomi_miio integration, but it had no impact as snips still won’t start without the check, as i wrote above. |
Hey there @rytilahti, @syssi, @starkillerOG, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) xiaomi_miio documentation |
If have linked |
Interesting is that mqtt will wait for the platforms to be set up before it is finished. In you case |
If you disable all |
thats not what i said. when i reported the issue after you asked to disable the configured entries i did so (in yaml). after that i could (of course) not see any startup time for the integration anymore. but it also did not help in terms of initialising the snips integration — i still need the mqtt-check to be present. |
snips takes 1.66 seconds to start up. i’ll have a look in the log files and see what i can find after i set he logs to more verbose reporting (as per default setting integration startup is not logged). |
Do you have any custom integrations set up? |
i do have some custom integrations, as you see below. i’ll try to reproduce the issue on a fresh, local HA install, to which, untill now, i had no success.
i have mysensor set up as a serial connection, not as mqtt, which is theoretically also possible. with a serial connection, mysensors should actually not have to wait for mqtt? (mysensors takes 5 seconds to set up) here are some logs. i do not know whether the order in the logs is the actual order for setting up the stages. if so, there are quite some integration setups between mqtt and snips.
|
You can look for any dependencies in the manifest file. |
thanks for the clue. if i look into owntracks manifest file, i see:
if i look into snips manifest file there’s no might that be the reason snips is not initializing without the explicit check for mqtt? |
@diplix May be you can check the startup time of |
|
@jbouwh what do you think of my question/sugestion that the snips manifest file should contain
instead of
wouldn’t that explain the problem? |
I am not sure, but you could try it perhaps by changing the snips manifest. @bdraco What do you think? |
i can try that, remove the explicit check for mqtt and change the snips manifest to see if that enables snips to initialize correctly. |
yes, snips initializes with this snips manifest file
#91790 can be re-applied. |
So what you say is that when |
i guess thats what i said, or rather what i observed. however i am not a developer or coder and am not really able to explain to you how so:
|
That is correct. I have not a sharp view on what the actual differences are. De documentation does not make it clearer to me. https://developers.home-assistant.io/docs/creating_integration_manifest/ It seems there is an issue in handling the dependencies, not sure why this happens yet. |
@diplix could you share some (redacted) debug logging or your startup where |
what makes you think that there’s an issue, if i just had a quick look at the codebase. Lines 66 to 71 in ef9bcd9
and this loop, that iterates over Lines 122 to 127 in ef9bcd9
the loop that iterates over Lines 114 to 118 in ef9bcd9
why not ask someone who does have „a sharp view on what the actual differences are“ instead of speculating about a bug? another clue is this PR: #68744
and thats exactly what the snips integration needed: wait for the mqtt platform to be set up.(handled by the core, instead of the integration itself). |
Thnx, I do have contact with @bdraco on this. It seems you are right. We do not add a wait task for dependencies, only for after dependencies if you look at the code, that would indeed explain it. |
What happens is that |
#92524 was opened to ensure we wait for the MQTT client in similar cases. |
The problem
Change #92296 was needed to make sure the
snips
integration set's up.It failed because
mqtt
was not available, while that should not be possible.It is known that if an integration is set up as a platform it could be triggered by the
mqtt
platform setup.But
snips
is an integration component that should wait for themqtt
integration component as a dependency.Issue #92236 proves this does not work.
What version of Home Assistant Core has the issue?
core-dev-2023.5.b0
What was the last working version of Home Assistant Core?
core-dev-2023.4.0
What type of installation are you running?
Home Assistant OS
Integration causing the issue
mqtt
Link to integration documentation on our website
No response
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: