That one does give a different response for me:
{
"PRE_2025_FREE_FEATURES": [
{
"source": "TADO_MANAGED",
"status": "ACTIVE",
"type": "TADO_MANAGED",
"startDate": "2025-07-07T16:10:18.918Z"
}
]
}
No idea where it gets that date from, since I’ve installed my tado devices almost two years ago…
I found the old packages in my cellar and both V3 and V3+ have “Works with Apple Homekit” on them.
Then it doesn’t matter which bridge is used. Sorry for the confusion! I’ll edit my post above to avoid false information 
How to check how many requests my Tado installation is sending to API?
To see the API calls, you need to set the binding log level to TRACE and check the “Api response” logs.
For users with an Amazon Echo it might be an option to use the Echo Binding and control the heating via the Echo. But I did not test this yet on my own.
I wonder if tado also restricts these API calls which come from the tado Alexa Skill. They most likely cannot distinguish between real Alexa voice commands or commands coming from the Echo binding via the heating things.
Or one could also just fake a voice command instead of using the heating thing from the Echo binding 
You can calculate the basic daily count from your number of devices N as (24 x 60 x 60 x N / refreshInterval) (assuming that all devices have the same refreshInterval).
The number N includes all Tado controller devices and your geofencing mobile phones.
On top of the basic daily call count will be:
I created a very limited substitution for the binding: Very partial tado binding alternative.
I would like to add: Selling the Tado devices is also a good option. Due to the increased new prices, the system has now effectively cost me 10€ per year. This is bearable and my heating system is now cloud-free.
Would you mind sharing with what you replaced your tado setup?
Since I already own a FritzBox, I opted for the FRITZ!DECT 302. I also considered ZigBee thermostats, but the options didn’t seem sufficiently reliable.
The FRITZ!DECT 302 have been reliable so far. The only drawback compared to the Tado thermostats is the lack of humidity measurement. They also sometimes react a bit slower, as changes aren’t pushed from the FritzBox to the thermostats; instead, the thermostats query the FritzBox for updates every three or five minutes. But that’s manageable.
And what do you use to control your boiler (i.e. “the device on the wall” - the equivalent of Smartes Thermostat X | tado˚ Shop – tado° Shop)?
I live in an apartment building, so I don’t have access to the boiler.
But at my parents’ house, I solved this problem with a Shelly 1 Gen3 (it replaced the Netatmo control system there). The control logic is quite simple: compare the actual and target temperatures (including hysteresis), set a switch for each room that requests heating, and group all switches into a group that switches the Shelly on as soon as a room requests heating or turns the heating off when it’s no longer needed.
I saw this mentioned in the HA community: GitHub - s1adem4n/tado-api-proxy: Bypass tado's API limits. Haven’t investigated it yet, though.
Is this based on the actual tado “devices”, or the things? In other words, if I don’t create the mobiledevice things, do they count? I assume not, but wanted to double-check.
I did not check the code, but from memory I think the account thing polls all devices within the home (or homes) regardless of whether or not they have actually been instantiated as things.
In the meantime I have developed a new binding [homekit] New HomeKit client binding by andrewfg · Pull Request #19340 · openhab/openhab-addons · GitHub that allows HomeKit devices to be integrated. The Tado internet gateway supports HomeKit so it may be possible to use this new binding to integrate your Tado system. Note however that I personally have a very old Tado internet gateway that only supports HomeKit protocol v1.0 and since the new binding is based on v1.1 I was not able to test this myself. However if you have a newer Tado internet gateway that supports HomeKit protocol v1.1 you are welcome to try the new binding and eventually give me feedback.
Wow, wonderful!
Does the jar you mention in the first post of the PR work for OH5.0.2 as well?
It should do.
I investigated this a few days ago, and - with some debugging with the developer - I got it to work!
So ideally, the tado binding would provide an input field for the API URL, defaulting to https://my.tado.com/, but leaving the option for e.g. http://192.168.1.10:52069/. So I thought it would be a fun exercise to attempt to integrate into the binding.
This is where I got:
Unfortunately, I’m stuck, as I’m getting this error when running mvn clean install:
[ERROR] C:\openHAB-dev\openhab-main\git\openhab-addons\bundles\org.openhab.binding.tado\src\main\java\org\openhab\binding\tado\internal\config\TadoHomeConfig.java:[28,19] The @NonNull field tadoApiUrl may not have been initialized
I tried searching for all instances of rfcWithUser, as that field raises no complaints, and I’m essentially copying it. But I can’t find out how rfcWithUser gets initialized elsewhere…
I then tried debugging in Eclipse IDE to find out, but that also didn’t provide any answer…
I’ve got the jar installed, and no errors appeared.
openhab> bundle:list | grep -i homekit
370 │ Installed │ 80 │ 5.1.0.202510301735 │ openHAB Add-ons :: Bundles :: HomeKit Client Binding
However, the binding doesn’t show up anywhere:
&
So something is wrong, it seems.
(Maybe a dedicated topic for the Homekit binding would be better?)
I have the same issue. Might be related to this error:
your code goes here2025-10-31 09:34:27.995 [ERROR] [Events.Framework ] - FrameworkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.homekit [354]
Unresolved requirement: Import-Package: com.google.gson; version="[2.13.0,3.0.0)"
at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1847) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1840) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1783) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1745) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1667) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) ~[org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234) [org.eclipse.osgi-3.18.0.jar:?]
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345) [org.eclipse.osgi-3.18.0.jar:?]