Erratic connection to TaHoma bridge

Configuration
1

Hi,
I am having problems with my Somfy awnings become Unavailable more and more frequently.

I am repeatedly seeing this error in my logs:

Logger: pyoverkiz.client
Source: components/overkiz/coordinator.py:94
First occurred: 13:45:23 (2010 occurrences)
Last logged: 22:28:09

Giving up _post(…) after 3 tries (aiohttp.client_exceptions.ClientConnectorDNSError: Cannot connect to host gateway-2041-8602-5006.local:8443 ssl:<ssl.SSLContext object at 0x7f540af1d0> [MDNS lookup failed, DNS server returned answer with no data])
Giving up _post(…) after 3 tries (aiohttp.client_exceptions.ClientConnectorDNSError: Cannot connect to host gateway-2041-8602-5006.local:8443 ssl:<ssl.SSLContext object at 0x7f540af1d0> [MDNS lookup failed, Timeout while contacting DNS servers])

Please can someone advise what the problem might be?

The TaHoma app and HomeKit are working fine so I don’t know what’s wrong.

TIA

2

Is your hub connected via WiFi or ethernet?

That error looks like an mDNS/name-resolution issue rather than the TaHoma bridge itself being offline.

A few additional questions/checks:

  • Are Home Assistant and the TaHoma bridge on the same subnet or VLAN?
  • Is Home Assistant running as HAOS, Docker, or in a VM?
  • Is there an IoT/guest network, wireless client isolation, or firewall rule that may be blocking multicast/mDNS traffic?
  • Does the TaHoma have a reserved/static IP address?

As a test, find the TaHoma’s IP address in your router and try configuring the Overkiz local integration using the IP address instead of:

gateway-2041-8602-5006.local

When using the IP address, disable “Verify SSL.” If that fixes it, I would reserve that IP in the router so it does not change.

3

Thanks for the quick reply.
I’m running HAOS on a Raspberry Pi4. The hub is connected via a WiFi connection to a UniFi Dream router on the default network, the pi and the hub are on the same LAN.
Since you think this is a network issue I’ll try your suggestions. I do have an IoT specific WiFi network but I set the hub up before I made the IoT net.
I’ll have to figure out how to move the WiFi without losing all the configuration.
Thanks for the tips, I’ll give it a try.

One other question, how do I change from url to IP? Do I need to reinstall the Overkiz integration or is there an easier way?

4

You shouldn’t need to move the TaHoma onto your IoT WiFi yet. Since the Pi and TaHoma are already on the same default LAN, I would first test using a fixed IP address. Moving it to another network could introduce VLAN, firewall, or mDNS complications.

In UniFi, locate the TaHoma under your clients and create a DHCP reservation/fixed IP for it.

Unfortunately, I don’t believe Overkiz currently offers a normal option to edit the host after it has been configured, so you will probably need to remove and add the integration again:

  1. Go to Settings → Devices & services → Overkiz.
  2. Make a note of your existing entity names and any automations that use them.
  3. Remove the Overkiz integration.
  4. Add Overkiz again and choose Somfy TaHoma and Local API.
  5. For the host, enter the reserved IP followed by port 8443, for example:

192.168.1.50:8443

Do not include https://.

  1. Enter your existing local API token, or generate another one from TaHoma Developer Mode if necessary.
  2. Disable Verify SSL when using the IP address.

That bypasses the .local/mDNS lookup that is failing in your log. I would try this before changing the TaHoma’s WiFi network.

5

Thanks for your help. I’ve fixed the IP and reinstalled the integration with the IP address instead of the url.
Didn’t actually need to fix anything after the reinstall as it all seemed to come back as it was.

My Pi4 is actually wired, only the TaHoma is on WiFi.
I’ll run like this for a while and see if the stability improves. If not I’ll try switching to my IoT network which has Multicast filtering Off and is forcing WiFi4 mode.
(Not entirely sure what these terms mean, but various sources seem to suggest this is better for compatibility)

Thanks again for pointing me in this direction!

6

Checked this morning and it’s rock solid. Thanks for the really helpful advice!

7

Developer of the Overkiz integration here. If you do figure out why this happens, let me know… Unfortunately we haven’t been able to pinpoint the exact issue here, as it seems related to the network stack, but it happens to many users.

We have documented the advice to switch to the IP address in the overkiz documentation. In the future, this will be easier as we will be adding the ‘reconfigure flow’ to Home Assistant.

8

@imick I took a look through the current Home Assistant and pyoverkiz code. I think there may be a way to avoid the intermittent mDNS failure without requiring users to disable SSL verification.

During Zeroconf discovery, Home Assistant already receives the gateway’s ip_address, hostname and port. However, the Overkiz config flow currently stores only the .local hostname. Every new aiohttp connection therefore has to resolve gateway-xxxx.local again. When both Home Assistant’s mDNS and regular DNS resolver temporarily fail, pyoverkiz retries the same hostname three times and eventually marks the coordinator update as failed.

Would it make sense to retain two values?

  • The discovered IP as the TCP connection address.
  • The gateway-xxxx.local hostname for TLS SNI and certificate hostname verification.

Current aiohttp supports a per-request server_hostname parameter, so pyoverkiz could connect to:

https://192.168.x.x:8443/…

while passing:

server_hostname=“gateway-xxxx.local”

That should preserve proper certificate validation while completely avoiding repeated mDNS lookups.

A possible implementation would be:

  1. Add an optional server_hostname argument to OverkizClient.
  2. Pass it through _get, _post, _put and _delete.
  3. Have the HA Zeroconf flow store the discovered IP separately from CONF_HOST.
  4. On later Zeroconf discoveries, update the connection IP using _abort_if_unique_id_configured(…, reload_on_update=True).

Manual hostname configurations could continue using the current behavior, and IP configurations with SSL disabled would remain backward compatible.

This would not identify why mDNS occasionally fails in individual network stacks, but it would remove the need to resolve the gateway repeatedly after Home Assistant has already discovered its address.