Reconfigure option

Development
1

Hello everyone,

I’ve moved away from configure to reconfigure in my custom_integration. I’m struggling to get this right.

Following a reconfigure, if HAS_FEEDBACK_MODULE is updated to True or False, it does not reflect until HA is restarted. I can’t undestand why…

I use this in the code of the integration to check the value, it’s inconsistent till I restart HA following a reconfigure.

self._has_feedback_module: bool = config_entry.data.get(CONF_HAS_FEEDBACK_MODULE, False)

Thanks for any guidance !

config_flow.py code:

Nikobus-HA/custom_components/nikobus/config_flow.py at Discovery · fdebrus/Nikobus-HA

3

Have you ensured you have followed this.

On success, reconfiguration flows are expected to update the current entry and abort; they should not create a new entry. This is usually done with the return self.async_update_reload_and_abort helper. Automated tests should verify that the reconfigure flow updates the existing config entry and does not create additional entries.

4

I do follow this but now I’ve found a problem in my dictionary

data={
    CONF_CONNECTION_STRING: user_input.get(
        CONF_CONNECTION_STRING,
        existing_entry.data.get(CONF_HAS_FEEDBACK_MODULE, ""),
    CONF_HAS_FEEDBACK_MODULE: user_input.get(
        CONF_HAS_FEEDBACK_MODULE,
        existing_entry.data.get(CONF_HAS_FEEDBACK_MODULE, False),
    ),
    CONF_REFRESH_INTERVAL: user_input.get(
        CONF_REFRESH_INTERVAL,
        existing_entry.data.get(CONF_REFRESH_INTERVAL, 120),
    ),
},

CONF_CONNECTION_STRING string was pulling status from CONF_HAS_FEEDBACK_MODULE. one shall never program with copy/paste.

The hunt is still one for the main trouble

5

I use the user configuration ‘feedback module’ yes/no to alter the behaviour of the event listener. user could say no, and I do not process the feedback module data, user say yes and I process the feedback module data

        self._has_feedback_module: bool = config_entry.data.get(
            CONF_HAS_FEEDBACK_MODULE, False
        )

then

        if any(message.startswith(refresh) for refresh in FEEDBACK_REFRESH_COMMAND):
            if self._has_feedback_module:
                _LOGGER.debug("Feedback module refresh command: %s", message)
                self._handle_feedback_refresh(message)
            else:
                _LOGGER.debug("Dropping Feedback refresh command: %s", message)
            return

        if message.startswith(FEEDBACK_MODULE_ANSWER):
            if self._has_feedback_module:
                _LOGGER.debug("Feedback module answer: %s", message)
                await self._feedback_callback(self._module_group, message)
            else:
                _LOGGER.debug("Dropping Feedback module answer: %s", message)
            return

and finally, if I look at the log. one time it drops it, the new occurence it process it. In my current config; it shall always process it, no drop

2025-02-20 08:46:08.666 DEBUG (MainThread) [custom_components.nikobus.nkblistener] Received message: $1C055B000000000000007275F4

2025-02-20 08:46:08.666 DEBUG (MainThread) [custom_components.nikobus.nkblistener] Dropping Feedback module answer: $1C055B000000000000007275F4

2025-02-20 08:46:08.666 DEBUG (MainThread) [custom_components.nikobus.nkblistener] Received message: $1C055B000000000000007275F4

2025-02-20 08:46:08.666 DEBUG (MainThread) [custom_components.nikobus.nkblistener] Feedback module answer: $1C055B000000000000007275F4

2025-02-20 08:46:08.666 DEBUG (MainThread) [custom_components.nikobus.coordinator] Processing feedback data: module_type=switch_module, module_address=5B05, group=1, module_state=000000000000

2025-02-20 08:46:08.666 DEBUG (MainThread) [custom_components.nikobus.coordinator] Handling event: nikobus_refreshed with data: {'impacted_module_address': '5B05', 'impacted_module_group': 1}
6

So I debugged by adding the self._has_feedback_module to the log, one time it’s true, one time it’s false. Should always be false in that case. deep diving…

_LOGGER.debug("%s Feedback module refresh command: %s", self._has_feedback_module, message)

2025-02-20 09:01:15.423 DEBUG (MainThread) [custom_components.nikobus.nkblistener] False Dropping Feedback refresh command: $101205918DF2EB

2025-02-20 09:01:15.782 DEBUG (MainThread) [custom_components.nikobus.nkblistener] Received message: $1C059100000000000000E858B3

2025-02-20 09:01:15.782 DEBUG (MainThread) [custom_components.nikobus.nkblistener] True Feedback module answer: $1C059100000000000000E858B3

7

the ha ha moment:

Problem solved, I’ve made a stronger async_unload_entry in my init.py to make sure to stop any running instance of listener, command queue and connection…

The value of _has_feedback_module is read from the configuration entry at initialization, so its value is fixed in that instance once created. In your logs, one message shows it as False while another shows True. This discrepancy usually indicates that different instances of the listener are processing events—each one initialized with its own config entry value. For example:

  • If a reconfiguration updates the config entry (using your updated reconfiguration flow), a new instance of the event listener may be created with CONF_HAS_FEEDBACK_MODULE set to True while an older instance (still handling some events) was created with it set to False.
  • Alternatively, if the configuration was changed at different times (or even on restart), the listener’s initialization will reflect the value stored in the config entry at that moment.

Because the attribute is set only once during initialization (see ), any change in the config entry isn’t automatically applied to a running listener until it’s reloaded. This is why you see one log entry dropping a command (when the flag was False) and later another log entry handling a command (when a new instance with True was running).

To have a consistent behavior during runtime, you’d need to ensure that only one instance is active or add a mechanism to update the flag dynamically when the configuration changes.