Integration Developers - please remember to allow reconfiguration of essential settings

Feature Requests
1

Recently a lot of people lost a lot of precious data after a security issue with QNAP NAS.

This made me revisit my own security level both with my Synology NAS and other 3rd party boxes

So I started a long weekend project defining better password strategy and in some cases created specific users for Home Assistant. There are integrations where you need some level of Admin access for the integration to work but in many cases you can create an “almost” admin user that has just the privviledges needed for the job.

In other words I had to redefine both user names and passwords for many of my integrations.

Even without a major cleanup, changing your passwords periodically is a good idea. It is not unreasonable to expect that you want to change the part of configuration that relates to credentials. Both usernames and passwords.

I have also recently moved one of my 3rd party boxes to another computer and that created a need to change the IP address of the server

Many of you integration developers moved your configs from YAML to UI. That is a good thing! Much more user friendly. But most of you forgot to make the settings you do at initial installation available for editing later

Most integrations do not allow to change simple things like the host name or IP, port number, user name, and password.

The only UI way to do that is to remove the entire integration and add it again. And for some integrations that can mean losing some of the renaming of entities and other things that you may have done post installation via the UI. That should be a last resort.

Some integrations are small and only create 1 device and 1 entity and they are not too much a pain. But those that create multiple entities, in some cases hundreds, this is a major pain.

There is one exception in all my integrations. MQTT. The author deserves a medal. There is a nice configuration menu at the top of the configuration saying re-configure MQTT. Super well made.

It is my hope that some of you will have this in mind next time you put time in updating your integration.

For those users that read this.

There is a way. It is risky but the only way currently.

Stop HA.
Go to the config/.storage directory and take a safety copy of core.config:entries
Edit the file and replace the settings you want to change. Search for your old IP address or password and change them. Do not goof up the quotes. Do not add extra commas. Be sober when you do this.
And then start HA again
Horrible risky hack but currently the only way if you do not want to completely remove the integrations

2 Likes
2

Are there really integrations that do not allow you to modify a password or IP once configured ? That is indeed bad design. I do agree with you, especially security relevant credentials should always be changeable at any time.

Try to manually edit the GUID hierarchy of the Windows registry and you’ll see what a horribly risk hack is :wink:
Honestly, I fail to see how this is a hack. They’re just machine generated json config files and much easier to edit and get right than this god awful yaml. I manually edit files in .storage all the time and never had an issue. The UI is extremely inefficient for things like batch renaming. Make a backup before you edit. That said, with the push to full UI settings, this should not be needed anymore, as you mentioned.

3

It’s a framework thing. Config entry implementation in hass does not expose a reconfigure option. Someone would need to implement it. Myself have worked around it by allowing my integrating to update an existing integration from the flow of setting up a new integration of it matches the unique id.

4

None the less, the MQTT integration has solved it rather elegantly.

Your workaround is … I do not want to insult anyone … just use a little humour … it is a very well kept secret

1 Like
5

Yes but that is a specially implemented frontend for MQTT, not a common framework thing.

6

Yes there are.

7

Maybe the common framework needs to adopt what @frenck has done with mqtt.

It is pretty unsatisfactory to say to people “delete the integration and reinstall it” just because they changed a password.

Not that I am complaining, just trying to support an idea that would make HA even more awesome.

1 Like
8

actually it’s being repeated countless times since I remember. And seemed everyone was ok with that. Especially if one asked for improvement in this area.

I hope approach to GUI development/user experience is going to be changed. Maybe Kenneth’s post will trigger those changes

3 Likes
9

I had forgotten about this part but there is also a mechanism (which is being used by the integration) to trigger a request for the user to reauthenticate once credentials fail to work.

10

You have my vote. That is the most important problem of moving away from .yaml to configuration.

2 Likes
11

I just wanted to add my vote for that feature here as a completely newbie user but experienced developer.
After two weeks of fiddling nearly every integration didn’t let me change the credentials afterwards. This is bad bad bad UX. Take Spotify as an example. The integration loses its credentials all the time and you always have to reinstall the integration to restart the OAuth flow again.
Or the Fritzbox integration which brings hundreds of entities. It is an absolute mess to redo all the changes after a reinstall.

Why is there such a half baked change from configuration by code to configuration by UI? Pretty messy experience right now.

1 Like
12

I just re-did my spotify. Why? Cos there was no other way.

13

You can reconfigure right now without all these steps listed. Let’s say you want to reconfigure spotify… Go to integrations, click the +, click spotify, enter your username and password and move forward. Guess what, you just reconfigured your existing configuration of spotify. You don’t need to delete the integration. You don’t need to adjust the hidden files. Just re-add the integration. The config entry system works off unique_id’s. If you add something that generates the same unique_id, it will just update that config entry.

1 Like
14

The integrations config flow needs to explicitly manage updating existing credentials. It’s not that many that actually works like that.

15

It would be nice if a config_flow could call an option_flow and return again afterwards.
This would save some amount of code duplication and enable this pretty easy while preserving steps needed to set up an integration initially.
(If I understood the flow things right - not done implementing one yet but a reconfigure step was the first thing I wanted to do :rofl:)

1 Like
16

Option flow is for extra settings but should of course fail gracefully if integration is not set up properly

17

Sure. But to change, say password I’d need an option_flow step for this. And a config_flow step to set it initially. There is a chance these not only share a vol.Schema, but also complete steps.
If config and option could share step code I think it could be easier to add an option_flow to change settings on an already installed integration (credentials, verification etc)

18

Maybe true for Spotify but not as general rule. There are integrations which doesn’t allow adding yet another instance.