Intergas intergration failing after core upgrade to 2024.2.x

[USRFSledge]

The problem

Intergas intergration was working fine for an extended period of time, till I ran the upgrade of core-2024.1.x to 2024.2.0 (and later 2024.2.1).

Best guess is the Python version upgrade that came with core-2024.2 broke the intergration. Boot log states that the intergration is not responding for over 300 seconds, which disables the intergration in order to continue the boot.

What version of Home Assistant Core has the issue?

core-2024.2.x

What was the last working version of Home Assistant Core?

core-2024.1.x

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Intergas InComfort/Intouch Lan2RF gateway

Link to integration documentation on our website

https://www.home-assistant.io/integrations/incomfort/

Diagnostics information

No response

Example YAML snippet

# Intergas Gateway
incomfort:
  host: 192.168.0.xxx
  username: admin
  password: xxxxxxxxx

Anything in the logs that might be useful for us?

Logger: homeassistant.setup
Source: setup.py:335
First occurred: 15:16:47 (1 occurrences)
Last logged: 15:16:47

Setup of 'incomfort' is taking longer than 300 seconds. Startup will proceed without waiting any longer

Additional information

Webinterfae of the gateway is available. Credentials are confirmed working. Both gateway as home assistant hot and cold booted multiple times. Native gateway android app is working as intended.

[home-assistant[bot]]

Hey there @zxdavb, mind taking a look at this issue as it has been labeled with an integration (incomfort) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `incomfort` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign incomfort` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

incomfort documentation incomfort source _{^{(message by IssueLinks)}}

[markvdlaan]

Same issue here

[NH-Networks]

Have no issues..

I dont need username and password for it to work

[USRFSledge]

I dont need username and password for it to work

Could that be because you have an older gateway? As per integration page;

Older gateways do not require user authentication

[USRFSledge]

I'm wondering if this Python timeout change has something to do with it (https://github.com/home-assistant/core/commit/7a89e58873fbe4c69c234f7741ac87d85c76fc11)

[NH-Networks]

I dont need username and password for it to work

Could that be because you have an older gateway? As per integration page;

Older gateways do not require user authentication

Yes perhaps, but then it probably has something to do with authentication and new python because the addon is working with older no authentication gateways

[zxdavb]

I'm wondering if this Python timeout change has something to do with it (7a89e58)

No, it doesn't - TimeoutError is essentially a different name for the same thing, asyncio.TimeoutError.

[zxdavb]

I am sorry, I am the CODEOWNER, but I no longer own this hardware, and am not really able to bugfix this.

[USRFSledge]

I am sorry, I am the CODEOWNER, but I no longer own this hardware, and am not really able to bugfix this.

I do appreciate that you replied. Unfortunately for us. Hopefully there is someone else around to take over the maintenance. Not for me, as I'm just a script kiddy.

[USRFSledge]

For what it is worth, I can do a GET request without any problems on admin:xxxxxx@192.168.0.x/protect/data.json?heater=0

{"nodenr": 6, "ch_temp_lsb": 28, "ch_temp_msb": 20, "tap_temp_lsb": 131, "tap_temp_msb": 9, "ch_pressure_lsb": 125, "ch_pressure_msb": 0, "room_temp_1_lsb": 200, "room_temp_1_msb": 7, "room_temp_set_1_lsb": 8, "room_temp_set_1_msb": 7, "room_temp_2_lsb": 255, "room_temp_2_msb": 127, "room_temp_set_2_lsb": 255, "room_temp_set_2_msb": 127, "displ_code": 126, "IO": 0, "serial_year": 0, "serial_month": 0, "serial_line": 0, "serial_sn1": 0, "serial_sn2": 0, "serial_sn3": 0 , "room_set_ovr_1_msb": 7, "room_set_ovr_1_lsb": 8, "room_set_ovr_2_msb": 0, "room_set_ovr_2_lsb": 0, "rf_message_rssi": 36, "rfstatus_cntr": 0}

[NH-Networks]

I will take a look at it today.. else it could take a while this will be fixed.. i guess

Code is pretty minimal, and think python 3.12 broke it

[USRFSledge]

Not trying to rush you @NH-Networks, but bloody curious if you have had any luck yet on the code...

[NH-Networks]

Mhh was hoping someone from the original dev team would pick this up.. i have a older gateway.. no auth and working perfectly.. so i need some logs to see what is happening on your side

[USRFSledge]

The only relevant logging I could find were in the openings post. Tried to enable SSH to the HA OS, but for whatever reason it is not allowing it. Tried several times 'by the book', command ha os import seems happy, though without any further feedback, but I can't authorise op port 22222.

[pbvdven]

Mhh was hoping someone from the original dev team would pick this up.. i have a older gateway.. no auth and working perfectly.. so i need some logs to see what is happening on your side

I also have an old red intergas gateway no issues controlling the device but i do have the issue since this latest HA update that the second light “WAN” goes off once or twice a day and the device is not reachable the “LAN” and “RF” light are still on but i need to reboot the gateway to be able to control it again.

[Predjee]

For me this was solved by pulling the power out so all 5 numbers are white. Then while the numbers are white pull out again so all except number 1 are white.

[USRFSledge]

In an attempt to do some debugging, I fired up a fresh Hass OS virtualbox image. I copied over my intergas config yaml, rebooted and the damn thing is working fine.

Even when I upload a backup of my live environment, the intergas integration is still working fine. I'm totally lost. Did my OS not got updated correctly/fully at some point and am I stuck with outdated files on my OS?

Tried again to gain SSH access to the OS, but without any luck, I stay stuck within the docker / hypervisor.

[SenTzu01]

I have been able to work around this until a fixture can be applied: Workaround is to set timeout in the incomfortclient library to a sufficiently high value. Downside is this needs to be reapplied after every Home Assistant Core update.

docker exec command to achieve this is:

docker exec -it homeassistant sh "/bin/sed -i 's/CLIENT_TIMEOUT = 20/CLIENT_TIMEOUT = 300/g' /usr/local/lib/python3.12/site-packages/incomfortclient/__init__.py" Alternatively one could create a shell command which can be triggered per the usual ways:

shell_command:
  fix_incomfort: /bin/sed -i 's/CLIENT_TIMEOUT = 20/CLIENT_TIMEOUT = 300/g' /usr/local/lib/python3.12/site-packages/incomfortclient/__init__.py

afterwards restart homeassistant....disco !!

[USRFSledge]

Awesome @SenTzu01 Do you happen to know any way of applying this workaround without having access to the OS? Guess there is no way of doing the trick from within the docker terminal, right?

[SenTzu01]

@USRFSledge if you have access to the host terminal you could execute docker exec -it homeassistant /bin/bash, then from within the container execute sed -i 's/CLIENT_TIMEOUT = 20/CLIENT_TIMEOUT = 300/g' /usr/local/lib/python3.12/site-packages/incomfortclient/__init__.py.

If you dont have access to the host terminal, define the shell command as per my first post, adn then create an automation (see below for reference):

alias: Fix Incomfort
description: ""
trigger: []
condition: []
action:
  - service: shell_command.fix_incomfort
    metadata: {}
    data: {}
mode: single

Once setup, just trigger the automation manually and reboot HA Core. Hope this helps!

[USRFSledge]

Boy oh boy @SenTzu01 you're a life saver! I had to disable "protection mode" from my terminal plugin first to accept the docker command. After that it was as smooth as you said. Just increasing the script time-out value was all it took. I could hug you now.

(Interesting twist though, as the HASS log nagged about the script exceeding 300 seconds. Looks like there is a small communication error between the intergration and the OS on that matter.)

[SenTzu01]

@USRFSledge Glad to help a fellow Dutchie! Agree there is something more to it as the log states it taking more than 300 seconds. Considering my bootup didnt take that long I went bughunting. Took me a while considering I have been using HA only for a week....

[NH-Networks]

For what it is worth, I can do a GET request without any problems on admin:xxxxxx@192.168.0.x/protect/data.json?heater=0

{"nodenr": 6, "ch_temp_lsb": 28, "ch_temp_msb": 20, "tap_temp_lsb": 131, "tap_temp_msb": 9, "ch_pressure_lsb": 125, "ch_pressure_msb": 0, "room_temp_1_lsb": 200, "room_temp_1_msb": 7, "room_temp_set_1_lsb": 8, "room_temp_set_1_msb": 7, "room_temp_2_lsb": 255, "room_temp_2_msb": 127, "room_temp_set_2_lsb": 255, "room_temp_set_2_msb": 127, "displ_code": 126, "IO": 0, "serial_year": 0, "serial_month": 0, "serial_line": 0, "serial_sn1": 0, "serial_sn2": 0, "serial_sn3": 0 , "room_set_ovr_1_msb": 7, "room_set_ovr_1_lsb": 8, "room_set_ovr_2_msb": 0, "room_set_ovr_2_lsb": 0, "rf_message_rssi": 36, "rfstatus_cntr": 0}

Just to validate.. this response is instant..? With curl or wget?

[USRFSledge]

Instant, with curl indeed from any random machine in my network @NH-Networks

[SenTzu01]

Havent looked into the code any further, but from the previous Home Automation I used (Pimatic) I recall that updates to the incomfort bridge are not processed immediately. As python calls the API asynchronously, the timeouts could occur.

[NH-Networks]

Havent looked into the code any further, but from the previous Home Automation I used (Pimatic) I recall that updates to the incomfort bridge are not processed immediately. As python calls the API asynchronously, the timeouts could occur.

It just processes the json.. only values get updated... Never seen a timeout... Glad your fix is working.. but there is some other issue

[USRFSledge]

@USRFSledge Glad to help a fellow Dutchie! [...] Took me a while considering I have been using HA only for a week....

A fellow dutchie, that increases the chance of hugging massively. What a shame you don't use HA as the intergration is up for adoption AFAIK (how on earth did you end up within this ticket in the first place?)

EDIT: Hang on ... you are using HA now, but only for week and for sure planning on using it a bit longer. Looking for adopting an intergration?

[SenTzu01]

Had the same issue with my incomfort gateway, so rule #1: Use your internet Fu.... I recently switched to HA, Used to develop for Pimatic. I still need to gain mad Python skillz, might adopt the integration once I am set. Current code owners could PM me or something.

[USRFSledge]

I am sorry, I am the CODEOWNER, but I no longer own this hardware, and am not really able to bugfix this.

Hi @zxdavb, mister @SenTzu01 appears a little shy so far, but he might be a candidate to take over your integration ;)

I [...] might adopt the integration once I am set. Current code owners could PM me or something.

[USRFSledge]

If it helps, the incomfort debug log shows the integration is taking its time indeed (on my Pi 3b at least). Not sure how it was before, but for the record, it only became an issue as from HA core-2024.2.x

2024-02-28 23:06:06.959 DEBUG (MainThread) [incomfortclient] Gateway(hostname=192.168.0.x) instantiated.
2024-02-28 23:06:06.960 DEBUG (MainThread) [incomfortclient] _get(url=heaterlist.json, auth=REDACTED)
2024-02-28 23:06:33.284 WARNING (MainThread) [homeassistant.setup] Setup of schedule is taking over 10 seconds.
2024-02-28 23:06:33.284 WARNING (MainThread) [homeassistant.setup] Setup of incomfort is taking over 10 seconds.
2024-02-28 23:06:33.285 WARNING (MainThread) [homeassistant.setup] Setup of counter is taking over 10 seconds.
2024-02-28 23:06:33.285 WARNING (MainThread) [homeassistant.setup] Setup of input_button is taking over 10 seconds.
2024-02-28 23:06:33.288 WARNING (MainThread) [homeassistant.setup] Setup of input_boolean is taking over 10 seconds.
2024-02-28 23:06:33.288 WARNING (MainThread) [homeassistant.setup] Setup of input_select is taking over 10 seconds.
2024-02-28 23:06:33.289 WARNING (MainThread) [homeassistant.setup] Setup of zone is taking over 10 seconds.
2024-02-28 23:06:33.289 WARNING (MainThread) [homeassistant.setup] Setup of tag is taking over 10 seconds.
2024-02-28 23:06:33.337 WARNING (MainThread) [homeassistant.setup] Setup of rest is taking over 10 seconds.
2024-02-28 23:06:33.338 WARNING (MainThread) [homeassistant.setup] Setup of input_text is taking over 10 seconds.
2024-02-28 23:06:33.339 WARNING (MainThread) [homeassistant.setup] Setup of media_source is taking over 10 seconds.
2024-02-28 23:06:33.339 WARNING (MainThread) [homeassistant.setup] Setup of logbook is taking over 10 seconds.
2024-02-28 23:06:37.134 DEBUG (MainThread) [incomfortclient] _get(url=heaterlist.json): response = {'heaterlist': ['2211f20858', None, None, None, None, None, None, None]}
2024-02-28 23:06:37.135 DEBUG (MainThread) [incomfortclient] Heater(serial_no=2211f20858) instantiated.
2024-02-28 23:06:37.135 DEBUG (MainThread) [incomfortclient] Gateway(192.168.178.4).heaters() = ['2211f20858', None, None, None, None, None, None, None]
2024-02-28 23:06:37.135 DEBUG (MainThread) [incomfortclient] _get(url=data.json?heater=0, auth=REDACTED)
2024-02-28 23:06:42.041 DEBUG (MainThread) [incomfortclient] _get(url=data.json?heater=0): response = {'nodenr': 6, 'ch_temp_lsb': 49, 'ch_temp_msb': 13, 'tap_temp_lsb': 34, 'tap_temp_msb': 9, 'ch_pressure_lsb': 134, 'ch_pressure_msb': 0, 'room_temp_1_lsb': 58, 'room_temp_1_msb': 7, 'room_temp_set_1_lsb': 58, 'room_temp_set_1_msb': 7, 'room_temp_2_lsb': 255, 'room_temp_2_msb': 127, 'room_temp_set_2_lsb': 255, 'room_temp_set_2_msb': 127, 'displ_code': 0, 'IO': 10, 'serial_year': 22, 'serial_month': 11, 'serial_line': 15, 'serial_sn1': 2, 'serial_sn2': 8, 'serial_sn3': 58, 'room_set_ovr_1_msb': 7, 'room_set_ovr_1_lsb': 58, 'room_set_ovr_2_msb': 0, 'room_set_ovr_2_lsb': 0, 'rf_message_rssi': 35, 'rfstatus_cntr': 0}
2024-02-28 23:06:42.042 DEBUG (MainThread) [incomfortclient] Heater(2211f20858).status() = {'display_code': 0, 'display_text': 'opentherm', 'fault_code': None, 'is_burning': True, 'is_failed': False, 'is_pumping': True, 'is_tapping': False, 'heater_temp': 33.77, 'tap_temp': 23.38, 'pressure': 1.34, 'serial_no': '2211f20858', 'nodenr': 6, 'rf_message_rssi': 35, 'rfstatus_cntr': 0}
2024-02-28 23:06:44.810 DEBUG (MainThread) [incomfortclient] Room(room_no=1) instantiated.
2024-02-28 23:06:44.827 DEBUG (MainThread) [incomfortclient] Room(1).status() = {'room_temp': 18.5, 'setpoint': 18.5, 'override': 18.5}

[zxdavb]

Hi @zxdavb, mister @SenTzu01 appears a little shy so far, but he might be a candidate to take over your integration ;)

Anyone (not just the CODEOWNER) can submit a PR.

Submitting several high-quality PRs and/or getting usefully involved with issues will be sufficient to qualify you for CODEOWNER status.

Becoming the CODEOWNER is just another PR.

[SenTzu01]

@zxdavb I am not ready to take this responsibility yet, as per my previous post. Just wanted to share my 2 cents to help others. If this is indeed to be fixed from the calling code in HA as per your comments on the PR, I suggest this will be discussed with the owners of the calling code. For now I consider myself merely to be a helpful end-user of HA.

[v1nc3nt89]

I have been able to work around this until a fixture can be applied: Workaround is to set timeout in the incomfortclient library to a sufficiently high value. Downside is this needs to be reapplied after every Home Assistant Core update.

docker exec command to achieve this is:

docker exec -it homeassistant sh "/bin/sed -i 's/CLIENT_TIMEOUT = 20/CLIENT_TIMEOUT = 300/g' /usr/local/lib/python3.12/site-packages/incomfortclient/__init__.py" Alternatively one could create a shell command which can be triggered per the usual ways:

shell_command:
  fix_incomfort: /bin/sed -i 's/CLIENT_TIMEOUT = 20/CLIENT_TIMEOUT = 300/g' /usr/local/lib/python3.12/site-packages/incomfortclient/__init__.py

afterwards restart homeassistant....disco !!

Hi @SenTzu01! Thank you for your work! I've added the shell_command, rebooted HA, ran the automation, rebooted again but unfortunately my Incomfort is still not working. I'm using an old Intergas gateway, so without authentication. Everything is looking fine when I straight go to its IP address.

Before running the fix_incomfort command the timeout error as in the opening post was shown in the HA logs. Now it shows:

Logger: homeassistant.setup
Source: setup.py:390
First occurred: 22 March 2024 at 23:56:53 (1 occurrences)
Last logged: 22 March 2024 at 23:56:53

Error during setup of component incomfort
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/setup.py", line 390, in _async_setup_component
    result = await task
             ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/incomfort/__init__.py", line 56, in async_setup
    heaters = incomfort_data["heaters"] = list(await client.heaters())
                                               ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/incomfortclient/__init__.py", line 193, in heaters
    heaters = dict(await self._get("heaterlist.json"))[HEATERLIST]
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/incomfortclient/__init__.py", line 148, in _get
    response = await resp.json(content_type=None)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/aiohttp_client.py", line 71, in json
    return await super().json(*args, loads=loads, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/aiohttp/client_reqrep.py", line 1182, in json
    return loads(stripped.decode(encoding))
                 ^^^^^^^^^^^^^^^^^^^^^^^^^
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc8 in position 22: invalid continuation byte

Do you have a clue what the issue could be? Or someone else?

[USRFSledge]

[...] Downside is this needs to be reapplied after every Home Assistant Core update. [...]

As was exactly the case for core-2024.2.x and core-2024.3.x, but as from core-2024.4.x everything works out of the box again. Did I got lucky three times in a row (v4.0, 4.1 and 4.2) or is this the general experience?

[v1nc3nt89]

[...] Downside is this needs to be reapplied after every Home Assistant Core update. [...]

As was exactly the case for core-2024.2.x and core-2024.3.x, but as from core-2024.4.x everything works out of the box again. Did I got lucky three times in a row (v4.0, 4.1 and 4.2) or is this the general experience?

Same here, works fine again with core-2024.4.x without applying the temporary fix.

[jbouwh]

Hi, I am the new codeowner for the incomfort integration. The integration is working for me, just curious who has these issues. So is this solved with HA core-2024.4.x ?

[USRFSledge]

Glad to see @jbouwh, as I hope to use the hardware for a little longer. For me the issue disappeared as from core-2024.4.x. And by the silence in this thread, I suppose for the majority is with me.

[jbouwh]

Then I suggest to close this issue for now, thank you for your feedback @USRFSledge.

[jbouwh]

Glad to see @jbouwh, as I hope to use the hardware for a little longer. For me the issue disappeared as from core-2024.4.x. And by the silence in this thread, I suppose for the majority is with me.

BTW, I bought a new boiler and gateway last week, so I may assume support is to be continued for now.

[USRFSledge]

Cheers @jbouwh