Home Assistant addon 1.5.0 crashes soon after startup

[Jon798]

Hi,

System was running as expected with addon 1.4.3.  Upgraded to v1.5.0 and now the addon crashes soon after startup. Debug log here:

Code:

[08:08:08] WARNING: TLS encryption option disabled.
[08:08:08] INFO: Starting Comfort to MQTT...
2025-08-03 08:08:08 DEBUG    Starting new HTTP connection (1): supervisor:80
2025-08-03 08:08:08 DEBUG    http://supervisor:80 "GET /addons/self/info HTTP/1.1" 200 10392
2025-08-03 08:08:08 INFO    Importing the add-on configuration options
2025-08-03 08:08:08 INFO    Completed importing addon configuration options
2025-08-03 08:08:08 DEBUG    The following variable values were passed through via Home Assistant
2025-08-03 08:08:08 DEBUG    MQTT_USER = ComfortAddon
2025-08-03 08:08:08 DEBUG    MQTT_PASSWORD = ******
2025-08-03 08:08:08 DEBUG    MQTT_SERVER = 172.30.33.0
2025-08-03 08:08:08 DEBUG    MQTT_PROTOCOL = TCP/1883 (Unsecure)
2025-08-03 08:08:08 DEBUG    COMFORT_ADDRESS = 192.168.4.205
2025-08-03 08:08:08 DEBUG    COMFORT_PORT = 1001
2025-08-03 08:08:08 DEBUG    COMFORT_LOGIN_ID = ******
2025-08-03 08:08:08 DEBUG    COMFORT_CCLX_FILE = comfigurator.cclx
2025-08-03 08:08:08 DEBUG    COMFORT_BATTERY_STATUS_ID = 0
2025-08-03 08:08:08 DEBUG    MQTT_CA_CERT = ca.crt
2025-08-03 08:08:08 DEBUG    MQTT_CLIENT_CERT = client.crt
2025-08-03 08:08:08 DEBUG    MQTT_CLIENT_KEY = client.key
2025-08-03 08:08:08 DEBUG    MQTT_LOG_LEVEL = DEBUG
2025-08-03 08:08:08 DEBUG    COMFORT_TIME= True
2025-08-03 08:08:08 WARNING  MQTT Transport Layer Security disabled.
2025-08-03 08:08:08 INFO    Comfigurator (CCLX) File detected, 248467 Bytes
2025-08-03 08:08:08 INFO    Connecting to Comfort (192.168.4.205) on port 1001
2025-08-03 08:08:09 INFO    MQTT Broker Connection Success
2025-08-03 08:08:09 DEBUG    Subscribed to 8 Zone Outputs
2025-08-03 08:08:09 DEBUG    Subscribed to 16 Zone Inputs
2025-08-03 08:08:09 DEBUG    Not Subscribed to any RIO Inputs
2025-08-03 08:08:09 DEBUG    Not Subscribed to any RIO Outputs
2025-08-03 08:08:09 DEBUG    Subscribed to 254 Flags
2025-08-03 08:08:09 DEBUG    Subscribed to 32 Sensors
2025-08-03 08:08:09 DEBUG    Subscribed to 255 Counters
2025-08-03 08:08:09 DEBUG    Not Subscribed to any Responses
2025-08-03 08:08:09 DEBUG    Synchronizing Comfort Data...
2025-08-03 08:08:09 DEBUG    Synchronization Done.
2025-08-03 08:08:19 ERROR    Comfort connection error during recv: [Errno 104] Connection reset by peer
2025-08-03 08:08:19 ERROR    Comfort Socket Error [Errno 104] Connection reset by peer
2025-08-03 08:08:19 ERROR    Lost connection to Comfort, reconnecting...
2025-08-03 08:08:29 INFO    Connecting to Comfort (192.168.4.205) on port 1001
2025-08-03 08:08:29 DEBUG    LU04
2025-08-03 08:08:29 INFO    Comfort Login Ok - User 4
2025-08-03 08:08:30 INFO    Setting Comfort Date/Time
2025-08-03 08:08:33 DEBUG    OK
2025-08-03 08:08:33 DEBUG    b?00000000000000000000000000
2025-08-03 08:08:33 DEBUG    Zones Bypassed: 0
2025-08-03 08:08:33 DEBUG    V?FE080D22400100
2025-08-03 08:08:35 INFO    Comfort II ULTRA detected (Supported Firmware 8.013)
2025-08-03 08:08:35 DEBUG    EL11F1FFFFFFFF
2025-08-03 08:08:35 DEBUG    1 Installed SEM(s) detected
2025-08-03 08:08:35 DEBUG    Hardware Model CM9000-ULT
2025-08-03 08:08:36 DEBUG    DL7FF9040001010082
2025-08-03 08:08:36 DEBUG    SN0101010000
2025-08-03 08:08:36 INFO    Refresh Key: 01010000
2025-08-03 08:08:36 INFO    Serial Number: Invalid
2025-08-03 08:08:37 DEBUG    M?0004
2025-08-03 08:08:37 INFO    Security Off
2025-08-03 08:08:37 DEBUG    Z?0005
2025-08-03 08:08:37 DEBUG    Max. Reported Zones/Inputs: 16
2025-08-03 08:08:37 DEBUG    Y?0000
2025-08-03 08:08:37 DEBUG    Max. Reported Outputs: 16
2025-08-03 08:08:37 DEBUG    f?00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2025-08-03 08:08:40 DEBUG    S?00
2025-08-03 08:08:40 DEBUG    a?000000000000000000
2025-08-03 08:08:40 DEBUG    r?0100100000000000000000000000000000000000000000000000000000000000000000
2025-08-03 08:08:40 DEBUG    r?0110100000000000000000000000000000000000000000000000000000000000000000
2025-08-03 08:08:40 DEBUG    r?000010FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2025-08-03 08:08:40 DEBUG    r?001010FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
2025-08-03 08:08:41 DEBUG    r?0020100000000000000000000000000000000000000000000000000000000000000000
2025-08-03 08:08:41 DEBUG    r?0030100000000000000000000000000000000000000000000000000000000000000000
2025-08-03 08:08:41 DEBUG    r?0040100000000000000000000000000000000000000000000000000000000000000000
2025-08-03 08:08:41 DEBUG    r?0050100000000000000000000000000000000000000000000000000000000000000000
2025-08-03 08:08:41 DEBUG    r?0060100000000000000000000000000000000000000000000000000000000000000000
2025-08-03 08:08:41 DEBUG    r?0070100000000000000000000000000000000000000000000000000000000000000000
2025-08-03 08:08:42 DEBUG    r?0080100000000000000000000000000000000000000000000000000000000000000000
2025-08-03 08:08:42 DEBUG    r?0090100000000000000000000000000000000000000000000000000000000000000000
2025-08-03 08:08:42 DEBUG    r?00A0100000000000000000000000000000000000000000000000000000000000000000
2025-08-03 08:08:42 DEBUG    r?00B0100000000000000000000000000000000000000000000000000000000000000000
2025-08-03 08:08:42 DEBUG    r?00C0100000000000000000000000000000000000000000000000000000000000000000
2025-08-03 08:08:42 DEBUG    r?00D0100000000000000000000000000000000000000000000000000000000000000000
2025-08-03 08:08:42 DEBUG    r?00E0100000000000000000000000000000000000000000000000000000000000000000
2025-08-03 08:08:43 DEBUG    r?00F00F000000000000000000000000000000000000000000000000000000000000
2025-08-03 08:08:49 DEBUG    IP0201
2025-08-03 08:08:51 DEBUG    IP0200
2025-08-03 08:08:51 DEBUG    IP0501
2025-08-03 08:08:53 DEBUG    IP0500
2025-08-03 08:09:18 ERROR    Error sending command
Traceback (most recent call last):
  File "/comfort2/comfort2.py", line 1514, in readlines
    data = self.comfortsock.recv(recv_buffer).decode()
          ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
TimeoutError: [Errno 110] Operation timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/comfort2/comfort2.py", line 3256, in <module>
    mqttc.run()
    ~~~~~~~~~^^
  File "/comfort2/comfort2.py", line 2584, in run
    for line in self.readlines():
                ~~~~~~~~~~~~~~^^
  File "/comfort2/comfort2.py", line 1534, in readlines
    self._send_keepalive_and_check()    # Send keepalive and check socket status
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/comfort2/comfort2.py", line 1492, in _send_keepalive_and_check
    self.comfortsock.settimeout(original_timeout)
                                ^^^^^^^^^^^^^^^^
UnboundLocalError: cannot access local variable 'original_timeout' where it is not associated with a value
[07:09:19] WARNING: Halt add-on with exit code 1
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped

Not sure what to try to resolve this? Rolling back to v1.4.3 has it all working again.

Thanks in advance for any help.

Jon.

[Ingo]

You have some sort of connectivity issue to Comfort. Release 1.5.0 has been out for suite some time without any issues. It might just be that due to the connectivity issue the addon eventually crashes. Please make sure you are running the latest Eth03 firmware and have a stable wired network connection.

Ingo

[Jon798]

I tried 1.5.0 when it was first released and had the same issue so rolled back to 1.4.3 as I didn't have time to troubleshoot.

Tried again today.  Running on latest firmware 8.13 and I do have a stable ethernet connection.

The v1.5.0 addon runs up fine and then always crashes after startup, it's not like some intermittent connectivity crashes it sometimes, it's every startup and within 30s.

Rock solid on v1.4.3, so definitely something in the addon that's different. Debug log doesn't offer any further information that I can use, only the error "cannot access local variable 'original_timeout'..."

[Ingo]

There were changes to Keepalives to better report on network stability. I still say there is a network issue that 1.5.0 detects that may have been there since day #1. The following is not normal as Comfort is sending the disconnect. Make sure you don't have anything else connecting to the same port number or try port 1002.

2025-08-03 08:08:09 DEBUG    Synchronization Done.
2025-08-03 08:08:19 ERROR    Comfort connection error during recv: [Errno 104] Connection reset by peer
2025-08-03 08:08:19 ERROR    Comfort Socket Error [Errno 104] Connection reset by peer
2025-08-03 08:08:19 ERROR    Lost connection to Comfort, reconnecting...
2025-08-03 08:08:29 INFO    Connecting to Comfort (192.168.4.205) on port 1001
2025-08-03 08:08:29 DEBUG    LU04
2025-08-03 08:08:29 INFO    Comfort Login Ok - User 4

Edit:
Please also check your Eth03 idle setting, it might be too short.

Code:

This software requires a fully functional Comfort Ethernet or Wifi configuration with inactivity timeout set to the default value of 2 minutes. The UCM/Wifi is not recommended due to possible connectivity issues that could arise from switching between different AP's or other possible sources of RF noise. For best performance it is recommended to use either the UCM/Eth03 or the onboard Eth03 Plug-in module on the newer CM9001 Comfort Ultra models. Use a good quality CAT5e or better cable between Comfort and your network device.

[Jon798]

Tried port 1002, no difference.

I have a UCM/ETH02 with a wired connection which had timeout set to 0 (disabled). Changed to 2 mins and still same result - addon crashes about 15 seconds after the
r?00F00F000000000000000000000000000000000000000000000000000000000000 command is sent (this is 4 bytes shorter than all the other r? commands - assume that's right?)

Checked statistics on the switch port the UCM is connected to and the only errors I am seeing are receive packets dropped as the addon crashes.

The addon crashes still happen when I don't see the Err104 connection reset by peer message in the logs.  Should it report a lost connection rather than crash?

Thanks,

Jon.

[Ingo]

Tried port 1002, no difference.

I have a UCM/ETH02 with a wired connection which had timeout set to 0 (disabled). Changed to 2 mins and still same result - addon crashes about 15 seconds after the
r?00F00F000000000000000000000000000000000000000000000000000000000000 command is sent (this is 4 bytes shorter than all the other r? commands - assume that's right?)

Checked statistics on the switch port the UCM is connected to and the only errors I am seeing are receive packets dropped as the addon crashes.

The addon crashes still happen when I don't see the Err104 connection reset by peer message in the logs.  Should it report a lost connection rather than crash?

Thanks,

Jon.

Yes, the last r? command is shorter than the others.

Packets on Layer-1 should never just be dropped unless there is a line fault or some strange congestion issue where the port cannot handle the traffic and tries to throttle traffic in the only way it knows how, by dropping packets out of the HW queue eg. buffer overruns. This is all in HW so no control on either Comfort or Home Assistant side.

With TCP the connection is reset gracefully and all happens very cleanly as you won't see the messages you see when it's a graceful connection drop.

The receive packet drops does not sound right. The Err104 is an internal python error code, the Addon tries to send commands in a send routine but at that stage the connection dropped while sending and that is why you see the crash. It does however gracefully shutdown but the actual error is displayed for reference. So to update my previous suspicion, I don't think it's Comfort itself, it might be between Switch port to HA or Switchport to Comfort. The fact that 1.5.0 picks it up is strange, there is nothing is software that makes packet drops show up on a HW port level. Try running wireshark and capture the traffic on that port with the errors, maybe it will give you another clue.

Just to be clear, you have an Eth03 and also tested with a Eth02? Both do the same?

[Jon798]

I only have an ETH02, I don't have an ETH03.

Analysing wireshark captures is a bit beyond my abilities.  I've configured the switch port (Ubiquiti UDM-Pro) to a fixed 10mbit/s full-duplex instead of auto-negotiating in case that helps, and I'll keep an eye on any other errors/drops on the port, but can't shake the feeling that the hardware worked fine with v1.4.3 so ought to work with v1.5.0. Happy to be wrong if I can pinpoint the reason.

I guess I could just stay on v1.4.3 but one of the reasons I moved from HomeSeer to Home Assistant was to be on a platform that was keeping pace with changes in other systems, which HomeSeer wasn't.

ETH02 only tolerates a single connection at any one time, while ETH03 allows 2 - might that be a factor? Does the addon potentially handle keep alives while zone activations/clearances are being signalled at the same time?

Anything else I can try other than blindly trying to upgrade to ETH03 just in case?

Thanks,

Jon.

[Ingo]

No, the Eth03's dual connectivity is totally separate, it doesn't influence the operation. Keepalives and Comfort messages do not interfere at all. The keepalives are sent every 60s (I think) if no command has been sent by HA to Comfort otherwise the connections seems idle to Comfort and it drops it.

Edit: I just found an old Eth02 in my box of spares and connected it to my system. I also get the same error and disconnects as you so it seems the Eth02 is truly not fully compatible. Because it's End of Life and End of Support I am not even going to try and find the cause as it might be in the Eth02 firmware which I can't do anything about. My suggestion is to buy a Eth03 module and your issues should be resolved.

Edit 2: Did a quick capture and it seems the Eth02 get's hung up at some point. Seems like an internal buffer issue on the Eth02. It just runs out of steam trying to keep up and then gives up. The Addon send routine fails, but keepalives still works for some reason, but Comfort commands get stuck.

[slychiu]

r?00F00F000000000000000000000000000000000000000000000000000000000000 
This may cause a reset on a non-arm UCM or CM9001. Do you have a new  ARM processor? We will be rel;easing a new firmware for CM9001 and UCM

[Jon798]

My CPU and UCM are probably about 20 years old now, so I am guessing the UCM is non-ARM and the CPU is not a 9001.

Maybe the potentially troublesome command could be optional?

Thanks,

Jon.