Tado API limits & HomeKit binding

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..

  1. Maybe your machine has some a/v or firewall blocking the request to 192.168.1.70:80 or the response therefrom?
  2. 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).
  3. 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..

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.

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:

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

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.

Aha, I see sf=1 as well:

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.

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

Here’s another approach called TadoLocal where openHAB binding integration is on the to do list:

Interesting but a lot of Features ate already covered by openhab. With the homekit binding you already have the same functionality. Also it would be more usable with a mqtt interface with auto discovery.

The following summarises the various approaches that users can take. I restrict the list to features that actually work in OpenHAB:

  1. Continue to use the OH Tado binding, connected to the Tado API server endpoint, and drastically increase your refreshInterval configuration parameter to ensure that you remain under the number of allowed requests per day.

  2. Continue to use the OH Tado binding, connected to the Tado API server endpoint, and subscribe to Auto-Assist to get 20k requests per day, and if you still exceed the 20k limit then increase your refreshInterval as above.

  3. Continue to use the OH Tado binding, and change its configuration parameter to connect to the Tado User Interface server endpoint. And if necessary also increase your refreshInterval as above. Note: it is not sure how long this work around may continue to work for.

  4. Use the (NEW) OH HomeKit binding.

1 Like

Another idea would be to remodel the OH tado binding to extend on the homekit binding. A bit like for example the awtrix binding is an extension of the mqtt binding. That way all channels that are supported would work locally and for Toggling schedule and updating the home/away status the cloud quota would be just fine.

But I can understand if its not desired to invest the effort since we have something workable already.

I think you can do that without any remodelling. You would use the Tado binding for only those channels that are not accessible via the HomeKit binding. – But you would still need to respect the reduced rate limit allowances of the Tado API .. probably only poll the Mode channel once per hour (say) or less, and only use the channel to send mode change commands once every blue moon..

Yes I agree that you can configure it that way. Would just be nice if the tado binding would come with presets for it. And only one thing per device etc. But that’s not a priority since our immediate problems can be solved with the homekit binding. It might just cause issues for new users that don’t know about the rate limit issue.

1 Like

I’ll try this out as soon as I have the time.

By the way, I noticed the geolocation feature is now also behind the paywall. :cry:

And since my girlfriend has a terrible iPhone, which is practically useless with regards to geolocation, that is a big blow to my home automation setup…

A while ago I implemented the geofencing feature for iphones by using the iCloud binding to get the coordinates of the phone. And then I used a simple rule to calculate the distance to OH. That worked just fine. Maybe worth a try. Or did I miss something and this does no longer work?

Correct: iCloud binding, authentication problem - #85 by maihacke

Ah yes that’s an issue. Alternatively you can use some network based approach like pinging or the unifi binding. Another approach im using for more precise handling is espresence to track the Bluetooth beacons of the phone

That iPhone keeps going to sleep all the time. Also, she puts it in air plane mode at night.

I suppose those would disconnect all the time as well, but it’s an interesting path. But with which devices do you poll that?

As the name suggest with an esp32. It sends the distance of a device to mqtt. With apple you can either track phones or smart watches.

How far does such an ESP32 track indoors?