Integration recovery after Xtenders restart with parameter {1468}

[NaatuMik]

I need to restart HA to get the Studer integration working again after performing Xtenders reset using function {1468}.

Can you replicate the issue? Just do the reset and look if the integration contiues working after that.

[ankohanse]

Don't really want to reset my Xtender in a live situation (off-grid house, all electrics depend on this Xtender running...)
So tested with another Xtender param (1569: Reset all settings Aux1) and RCC param (5041: Save all files - backup), which are similar Signal type params.
From a home assistant perspective this is a valid test, HA does not care what a certain param does within the Studer environment, it only knows to send a signal to an xcom address and receive the response. So the exact same code is covered.

The XT 1569 param behavior was a bit weird in that the xcom system responsed with an error on that one. Can't explain the error, message sent to xcom is correctly formatted. Maybe my firmware does not support this param.
But error was handled correctly and Studer Integration keeps running:

2025-12-05 09:26:53.929 INFO (MainThread) [custom_components.studer_xcom.button] Set button.studer_4001_xt1_1569 to Signal (1)
2025-12-05 09:26:53.929 DEBUG (MainThread) [pystuderxcom.api_base_async] Update value StuderEntityData(family_id='xt', level=EXPERT, parent=1201, nr=1569, name='Reset all settings (AUX 1)', abbr='None', unit='', format=INT32, default='S', min='S', max='S', inc='S', options=None) on addr 101
2025-12-05 09:26:54.156 WARNING (MainThread) [custom_components.studer_xcom.coordinator] Failed to update value XT1 1569 via Xcom client: SCOM_ERROR_OBJECT_NOT_SUPPORTED

Immediately after that tested with RCC 5041, which behaves as expected:

2025-12-05 09:27:27.941 INFO (MainThread) [custom_components.studer_xcom.button] Set button.studer_4001_rcc_5041 to Signal (1)
2025-12-05 09:27:27.942 DEBUG (MainThread) [pystuderxcom.api_base_async] Update value StuderEntityData(family_id='rcc', level=BASIC, parent=5013, nr=5041, name='Save all files (system backup)', abbr='None', unit='', format=INT32, default='S', min='S', max='S', inc='S', options=None) on addr 501
2025-12-05 09:27:28.235 INFO (MainThread) [custom_components.studer_xcom.coordinator] Successfully updated RCC 5041 to value 1

So unfortunately cannot reproduce the behavior you see.
May it have to do with downstream results from resetting the Xtender? Reset of Xtender leads to temporary no power to Xcom-LAN leads to disconnect to HA -> but should lead to reconnect once power Xcom-LAN restarts.

[NaatuMik]

Thank you for your analysis. I need the reset function {1468} to modify the parameter {1462}: Multi inverters independents, which does not take effect without performing a reset. The automatic restart of Xtenders after the reset can be configured using parameter {1111}. In my opinion, the term reset might be better described as reboot, since I haven’t observed it changing any settings other than clearing the notification log.

The first time I noticed this issue was several hours after performing a reset, when the integration was still not functioning. Restarting HA resolved the problem. I then tested multiple times by performing the reset, but the integration never recovered without HA restart. In those cases, I waited approximately 5–10 minutes, which should have been sufficient for restoration.

Do you have any suggestions on how I could investigate the issue further?

[ankohanse]

Three things come to mind that would possibly give extra info:

1. A detailed debug log of when this happens. Enable debug logging for the integration as described at the bottom of the readme. Once the integration stops responding after the reset but before the restart of HA download the logs (go to Settings -> System -> Logs -> press the Download icon).

2. A download of the integration's diagnostics file a couple of minutes after the reset (but again before restart of HA). Possibly the integration will not let you do that in that situation, just try... (Settings -> Integrations -> Studer-Innotec -> press the 3 vertical dots icon -> download diagnostics)

3. Instead of a full restart of HA, could you please try a 'reload' of just the integration? Settings -> Integrations -> Studer-Innotec -> press the 3 vertical dots icon -> reload

[NaatuMik]

Thank you very much for the debugging advice. After revisiting the issue for testing, everything is now working perfectly. Honestly, I’m not sure what caused the earlier failures, but now even after multiple resets, the integration continues to work immediately.

I apologize for opening the case.

[ankohanse]

No need to apologize. Did something else change since the previous tests? Maybe an upgrade of HA Core?

Just keep an eye on it over the next weeks and don't hesitate to add a new comment if you find any new information.
I'll keep the issue open for a while...

[NaatuMik]

Now my system has started behaving strangely. Every time I modify any item selected from my XT3, Home Assistant hangs. I’m not sure if this is related to the previous issue. HA Core restarts itself, and the modification made to the XT3 selection of items is lost.
The item selection change appears to go through until the message “Options successfully saved” is displayed, but then HA Core freezes. The number of selected items for XT3 is not updated, and nothing works (not even the system logs) until HA Core completes its restart. All other Studer devices can be modified normally, it is just this XT3 causing the issue.

I have enabled debugging for the integration and attached the log, which I downloaded after the incident, once HA Core had recovered. I have a few other non-working integrations giving messages in the log, please just ignore them. I attached the integration diagnostics file too.

home-assistant_2025-12-25T13-10-09.418Z.log
config_entry-studer_xcom-01JF368J3ZDCVNX8WRM4ZG6AME.json

[ankohanse]

Thanks for the heads-up and the traces. They do indeed show HA suddenly restarting right after having added or removed infos and params and then saving the new config set.
Unfortunately it does not give me a clue about why this happens and I cannot reproduce it on my own system.

I will however release a new version of the integration soon (probably later this week), which also will contain various small fixes I made over the past couple of months. With a bit of luck that will resolve your issue.