If something like this was created (with a custom component that exposes a custom service call which will edit a config entry), it would still require the user to know the exact key that they need to edit in order to make the change - at this point, a user that knows this will already know how to manually edit the file.
For example, the username for the ring integration is an email. The ring integration uses the username config key. For an end user of the custom component that you suggested, if they changed their email, would need to know that the email is stored in the username key and not in a key titled email. They would only know this by looking at the config_entries file at which point they are knowledgeable enough to make the change manually.
For what you’re asking, the most straight forward way around this is to have integrations add the option of changing the username/email, password/API key via the configure option in the UI. Another way would be for Home Assistant to build out handling application credentials in a visual manner such as the way some integrations handle OAuth credentials (although editing current client IDs/secrets isn’t an option in the credentials menu).
However, all of this can be avoided by having integrations implement a reauth step for integrations that rely on credentials. If an integration is setup to handle a reauthorization, the integration should already ask the user to enter a new valid username/password in the event that credentials were changed/are no longer valid.
In @Olivier1974’s case, the smartthings integration doesn’t look to have a reauth step (no async def async_step_reauth function in config_flow.py). If this were added/a ConfigEntryAuthFailed exception raised when credentials are deemed invalid, a reauth would allow them to enter the new credentials via the UI without having to delete the integration and readding it.
We can all agree that hacking with any tool should never be needed.
But while we wait for that…
… a custom component could do the editing more atomic.
When you manually edit and leave Home Assistant running because you access the UI for an editor through the HA front end, then there is a risk that HA writes to the file while you have the file open in an editor and when you save, those changes are reverted. That could potentially create severe problems. So best is to do it with HA itself stopped.
A good tool would either write to the file through HA or at least do the change by merging any changing that happen concurrently to the new file. This is important
But it can load the file, display the relevant content you search for data you can edit and when you commit the data, you reload the file, change the data, and save the merged result leaving open a time window of a fraction of a second, versus, maybe minutes when you manually edit using a text editor. I do not know the inner engine of HA but there may also be a way to force HA to flush data in ram to the file before. Or the component could hold the altered data in a temp file, restart HA and merge. The two dangers of hacking are human goof up (so backup) and overwriting data when saving. As long as you edit files related to devices, the risk is relatively low as long as you do not try to add or remove anything in parallel. You do not want to start a permit join in your zigbee network while you have the file open in an editor unless you like to punish yourself
Makes sense. The config entries file, for example, is not going to be changed by Home Assistant while you’re editing the file manually (unless while editing the file you are adding a new integration), so the risk there is pretty much non-existent (aside from a user messing up formatting). If the desired outcome is to truly have Home Assistant stopped while the files are being edited, then you don’t have to rely on knowing python to build out a solution. You can create a standalone program or a script (with a user interface within a terminal window) that allows for searching for an integration by name and parsing the json file to find the related config entry where a user can then choose to edit specific fields. Seems like a lot more work than is worth when in reality, the only time credentials would need to be changed can already be handled with a reauth flow, but integrations that use credentials need to implement it.
Put simply, Home Assistant stores settings which are set on first setup (config) separately from settings which are changed after the first setup (options). This leaves the extra effort of “changing” settings up to the integration developer. Judging by the response on that second link, no one is really looking into improving this. I would bet if the two configuration flows were able to read/write from the same place, this would be pretty straightforward for developers to offer the functionality we’re looking for.
I can’t test it at the moment, but looking at the code for the Generic Camera plugin, it looks like changing the settings after first configuration will leave two entries in the config files. Maybe someone else can confirm this.
You didn’t have to re-add the device, you could have just re-configured it by going to add integration and add it again with the existing integration in place. This works for most integrations. It will replace the current integration but keep all your settings.
Let’s say I used the wrong relative path.
while readding,
I still have to configure everything else.
where a configure button with all options I use while adding would help me out.
I have been around ha since, I think, 2016. I have never seen that statement in the docs and it doesn’t seem that intuitive. I suggest it be made a lot clearer. But I am unsure where to add it to the docs. Any suggestions?
In that case it would be great if this is handled by HA core and not per integration.
This would make integration maintenance also easier.
But I now know what you mean.
Just tried with the integrations I use. The first one I tried adds a new sensor in addition to the old. No, many integrations do not alter existing item by re-adding. It just adds more instances.
It depends on the integration and what it uses for unique identification of each device & entity. And yes, many integrations have a solid backing behind this. It just so happens that you found one that didn’t.
An example where this wouldn’t work is if you decided to integrate a integration using a hostname, but the second time you use the IP address. That would most likely create a new integration with additional entities.
It does, it’s just not natural. You can delete the integration too and re-add it and your settings should remain the same for your entities. It’s not a great system, nor is it intuitive. But you can change it in a number of ways.
I would love a button to redo the configuration, that’s why I voted for this FR. I’m just explaining how to get to the goal right now. It seems that this upsets people for some reason.
I think we just understand “many” differently. The fact is. Many integrations have a good way to reconfigure a device. And many do not. Too many. Those that have it does it well or good enough. I gave an example of a good one as one of my first postings in this thread. And thank you to all the many devs that has provided a reconfig per device.
