I might be wrong, but ConfigFlow is supposed to create the config entry (async_create_entry) and OptionFlow is supposed to update it. So, what would be the point of reloding the entry under ConfigFlow before creating it?
Can you try your code with a fresh new addition of the integration, rather than editing the existing instance?
I agree with what you say, that’s why I didn’t understand why in the EufySecurity code, the async_reload is in the config_flow. That’s why I asked if it should be in the OptionFlow, after the user updates the values.
I tried my code (check previous post) now and it seems to be working fine. I tested it on the polling period, need to do further tests, but thanks a lot for now. 
i have it because of re-authentication flow, but you are right, it is far from clear
That leads me to think that you can use AsyncReload in both ConfigFlow and OptionsFlow.
Everything related to ConfigFlow/OptionsFlow is very far from clear, if you ask me. If it weren’t for people like you and a couple of other guys I would never managed to implement what I needed.
Thanks again.
You are right, we can call async_reload anytime, as long as it is already configured once. Would it fail, in case it was not initialized once?
I think it’s available, as long as you pass it a valid ConfigEntry. But I’m just speculating.
You could decouple it by firing an event (or figure out if one is already being fired) and have that hit a callback that then reloads. This way if the integration is not loaded or already disabled by then user, it won’t start up prematurely.
You don’t see any labels until you refresh the page, it’s a browser caching issue 
I had already tried the obvious hard-refresh, it didn’t work. Restarting HA the next morning did seem to work. Anyway, all set now.
You can set a callback to be called when options are updated, but anecdotally I believe this fires only if the options are actually updated as a result of the config flow. If nothing is changed, then it doesn’t seem to fire. It may also not be fired if you use ConfigEntry.async_update_entry to update the config entry because you store your config in data rather than in options.
# __init__.py
async def async_setup_entry(hass: HomeAssistant, entry: ConfigEntry) -> bool:
[...]
entry.async_on_unload(entry.add_update_listener(_async_update_listener))
async def _async_update_listener(hass: HomeAssistant, entry: ConfigEntry) -> None:
"""Handle options update."""
await hass.config_entries.async_reload(entry.entry_id)
Also, I don’t think it’s been mentioned previously in this thread, but you could also just store all of your config in options, and leave data empty. ConfigFlow.async_create_entry takes data and options as parameters:
async def async_step_user(
self, user_input: dict[str, Any] | None = None
) -> FlowResult:
"""Handle the initial step."""
errors: dict[str, str] = {}
description_placeholders: dict[str, str] = {}
if user_input is not None:
(data, options, errors, description_placeholders) = validate_input(
user_input
)
if not errors:
return self.async_create_entry(
title=data["title"], data=data, options=options
)
[...]
However, note that OptionsFlow.async_create_entry takes a parameter data but somewhat confusingly stores the value passed in options in the ConfigEntry. So as mentioned earlier, you need instead to use ConfigEntry.async_update_entry to update data, or store all config in options.
I just had that same issue except I was getting two of seven labels (I did a major rewrite of the integration). I searched /config with find . -exec grep "<label>" {} \; -print and found and edited all occurrences in strings.json, translations/en.json & ar.json but I also found a .translations folder (reason = ???) and also edited those but the problem persisted even though find could no longer find the label. I then cleared my browser cache and that solved my issue.