Tado API limits & HomeKit binding

AndrewFG · November 5, 2025, 2:12pm

Many thanks for the logs @ErikDB .. each of the three cases show the binding sending its first ‘M1’ request in the 6-step pairing process; and the request times out after 10 seconds with no visible response from the bridge.

There are a number of potential reasons why the bridge would not (seem to) respond..

Maybe your machine has some a/v or firewall blocking the request to 192.168.1.70:80 or the response therefrom?
Maybe the bridge is (notwithstanding your protestations) already paired? If you have an mDNS discovery app or Bonjour you can check this by looking at the sf parameter in the bridges advertisement. (sf=0 means already paired and sf=1 means ready to pair).
Maybe the bridge IS responding in some way but the binding is not seeing the response. Perhaps you could do a Wireshark capture?

Perhaps you can anyway share a screen shot of the thing properties e.g. as below..

ErikDB · November 5, 2025, 4:12pm

Nope.

Is there such an app you can recommend? I’d like to stay away from Apple products (although I see the irony).

I’ll send you the export in a private message.

ErikDB · November 5, 2025, 4:52pm

I’ve tried looking for a response via debugging in Eclipse IDE, but I don’t understand how it works. I don’t see the method which makes the HTTP call. I can’t pinpoint closer than here:

github.com/andrewfg/openhab-addons

bundles/org.openhab.binding.homekit/src/main/java/org/openhab/binding/homekit/internal/transport/IpTransport.java

392115e21


      
                  secureSession.send(request);
                  return null;
              });
              // now wait for both write and read to complete
              writeTask.get(TIMEOUT_MILLI_SECONDS, TimeUnit.MILLISECONDS);
              response = readHttpResponseFuture.get(TIMEOUT_MILLI_SECONDS, TimeUnit.MILLISECONDS);
          } else {
              OutputStream out = socket.getOutputStream();
              InputStream in = socket.getInputStream();
              // create Future to write the request (with a timeout)
              Future<@Nullable Void> writeTask = executor.submit(() -> {
                  out.write(request);
                  out.flush();
                  return null;
              });
              // wait for write to complete
              writeTask.get(TIMEOUT_MILLI_SECONDS, TimeUnit.MILLISECONDS);
              // create Future to read the response (with a timeout)
              Future<byte[][]> readTask = executor.submit(() -> readPlainResponse(in, trace));
              // wait for read to complete
              response = readTask.get(TIMEOUT_MILLI_SECONDS, TimeUnit.MILLISECONDS);

But those “futures” are (until I learn more) beyond me.

Punsher · November 5, 2025, 5:14pm

Hi,

here is the mdns emitted from my bridge:

avahi-browse -rt _hap._tcp

+ enp2s0.107 IPv6 tado Internet Bridge IB3042643968 _hap._tcp local

+ enp2s0 IPv6 tado Internet Bridge IB3042643968 _hap._tcp local

+ enp2s0 IPv4 tado Internet Bridge IB3042643968 _hap._tcp local

= enp2s0.107 IPv6 tado Internet Bridge IB3042643968 _hap._tcp local

hostname = [tadoBridgeIB3042643968.local]

address = [192.168.3.188]

port = [80]

txt = [“s#=1” “sf=1” “pv=1.0” “ci=2” “ff=1” “md=tado Internet Bridge” “id=cf:89:c8:cf:3b:14” “c#=1”]

= enp2s0 IPv6 tado Internet Bridge IB3042643968 _hap._tcp local

hostname = [tadoBridgeIB3042643968.local]

address = [192.168.3.188]

port = [80]

txt = [“s#=1” “sf=1” “pv=1.0” “ci=2” “ff=1” “md=tado Internet Bridge” “id=cf:89:c8:cf:3b:14” “c#=1”]

= enp2s0 IPv4 tado Internet Bridge IB3042643968 _hap._tcp local

hostname = [tadoBridgeIB3042643968.local]

address = [192.168.3.188]

port = [80]

txt = [“s#=1” “sf=1” “pv=1.0” “ci=2” “ff=1” “md=tado Internet Bridge” “id=cf:89:c8:cf:3b:14” “c#=1”]

So it should be ready to pair for all I know.

Is there a way for us to test the pairing with an api client such as Postman? I mean our main hurdle right now is to sent the right initial package to the bridge so that actually enters the pairing process.

ErikDB · November 5, 2025, 5:38pm

Aha, I see sf=1 as well:

Punsher · November 5, 2025, 6:28pm

Did some further investigation as far as I can tell the bridge is at fault. The bridge simply does not reply to the pairing request. Did some checking with the AI. Only thing that might still be a cause is an issue where the bridge might prefer ipv6. But that might be a red hering.

$ echo -ne ‘\x00\x01\x01\x06\x01\x01’ | \

> curl -v -4 -X POST \

> -H “Content-Type: application/pairing+tlv8” \

> -H “Accept: application/pairing+tlv8” \

> -H “Connection: close” \

> --data-binary @- \

> --http1.0 \

> http://192.168.3.188/pair-setup

Note: Unnecessary use of -X or --request, POST is already inferred.

* Trying 192.168.3.188:80…

* Connected to 192.168.3.188 (192.168.3.188) port 80 (#0)

> POST /pair-setup HTTP/1.0

> Host: 192.168.3.188

> User-Agent: curl/7.88.1

> Content-Type: application/pairing+tlv8

> Accept: application/pairing+tlv8

> Connection: close

> Content-Length: 6

>

This times out as well.

ErikDB · November 5, 2025, 6:36pm

FYI, see also this: [homekit] New HomeKit client binding by andrewfg · Pull Request #19340 · openhab/openhab-addons · GitHub