I have a custom component that is installed by putting the connection details in configuration.yaml and the code into its folder within custom_components. When I do this and restart HA, an entry for it appears in /config/integrations telling me how many devices and entities I have.
Since doing an update of the connection details (these include a token which has to be renewed annually), this integration won’t start (‘Connection refused - not authorised’ message in the log) and all my devices are greyed out in Lovelace.
I know that if I delete the integration from /config/integrations then restart HA, all the devices will come back and work. However they will have lost their areas etc. and I will have to spend quite a while fixing things (83 devices). I know this because (a) this is what happened last year, and I did this and (b) I’ve done it this time, but rather than go fixing things I’ve restored from backup and decided to try to find the cause of the problem. Otherwise I will be doing this every year!
I would rather not name the component as I would welcome some generic ‘in principle’ answers, and I know that custom components aren’t supported here. But in case it’s relevant, the integration uses MQTT, and this is where it’s failing.
My current guess is that something is cached/saved within HA, but I’m not really familiar with how everything hangs together in this area. I am happy to delve into the depths of HA if I need to though
Can anyone shed any light on this please, or suggest how I might go about diagnosing the problem?
This is mainly a user to user forum and all questions seems to be answered if possible.
Your issue seems to be with the authentication of the integration, either in HA, in the integration or in some cloud provider. You should look at the documentation for a clue into this issue.
Thanks for replying. Yes, I’ve found this forum to be very helpful in the past!
The fact that the integration works if I delete and re-add it makes me think it’s not to do with authentication, unless HA is ignoring the new token I’ve put in the config.
Also it’s a local integration, no Cloud involved, although I guess the unit itself will be checking the API token with it’s own private cloud, if you see what I mean.
If you just create a token in HA, then it have no effect.
The addon needs to know that it have to use that token.
The installation of the addon probably does this automatically.
But tell us what integration it is and we will look at the documentation.
The token is the API token (a.k.a. password) from the manufacturer of the device.
The component is installed simply by just putting the connection details (including the token) in configuration.yaml and putting the code in its custom component folder.
Actually you’ve just given me an idea. I could add some debug messages to the code to see what token/password it’s using, and check that that’s the right one … However I guess it will be, as from the code I don’t see how it could be getting it wrong.
Is there some way that HA could be trying to start an old version of the integration before the integration itself starts?? Sounds unlikely.
So could it be something cached in MQTT?? How to diagnose this?
I’ve got MQTT Explorer and that connects fine with the new credentials (from my PC).
Which is why I’m wondering if MQTT on the HA box has cached something. But I have no idea how to diagnose this/clear any cache.
I have restarted the whole HA box (I’m running in Supervised mode) but that doesn’t help. Perhaps there’s something I can put in the MQTT add-on config??
That does not use MQTT. That uses an API. Your issue is specific to that integration. The only place cached information would be is in the .storage directory in the entity and device registry.
You could backup your current install, delete and readd the integration and look at the .storage differences and apply those to your backed up install. The other options is to reintegrate without deleting it first
EDIT: To clarify, many integrations allow you to reintegrate them and they will replace your current integration and retain all entity_id’s and user set names.
With your help @petro I’ve fixed it!! Thank you so much for the ‘look in .storage’ suggestion.
I started looking through the core.* files in .storage, which I found are readble json files. When I got to core.config_entries I found that the password for nhc2 was the old one. Copied & pasted in the new one, saved the file, restarted HA and, lo and behold, everything is working again!
I am so grateful for your help, you have saved me hours (maybe days) of work and frustration.
(I am wondering if you could actually class this as a bug in HA? Surely it shouldn’t try to open connections before looking in configuration.yaml? Or is there a ‘proper’ way to avoid this behaviour?)
