I love this concept, sounds like it would be much better than the SSID tracking and IP tracking I use. As a noob to ESP32, are there any Guides for Dummies to help point the way?
Like with wifi it varies greatly depending on your building and radio pollution. But around ten meters should be doable.
They are just small affordable chips that have been used for all sorts of things. They are actually contained in a lot of wifi based smart home products. Shellies contain them for example. And many enthusiasts use them to make legacy devices smart. For most boiler manufacturers you can get something built on an esp platform to integrate it in your smart home.
But anyways espresence is a software you can flash on an esp32. There are some tutorials on YouTube to get it set up. One small drawback is that for android I had to use a third party app to emit a beacon. Because normally a phone changes the Bluetooth mac address all the time to prevent tracking.
@AndrewFG, Iāve got a rule which turns my heating off when a window is opened, and on when it is closed. But sometimes, a window is opened and almost immediately closed again (e.g. to let the dog into the house).
It looks like something went wrong this morning. This particular window is tied to two tado zones: zone 6: the kitchen, with Thing homekit:bridged-accessory:72157980e9e1:5 (a TVR), and zone 2: the dining room, with Things homekit:bridged-accessory:72157980e9e1:2 (the thermostat) and homekit:bridged-accessory:72157980e9e1:6 (a TVR).
When the window is opened:
items[verwarmingsitemstring + "_Heating_Cooling_Target"].sendCommand(0);
items[verwarmingsitemstring + "_mode"].postUpdate("MANUAL");
When the window is closed:
items[verwarmingsitemstring + "_mode"].sendCommand("SCHEDULE");
items[verwarmingsitemstring + "_Heating_Cooling_Current"].postUpdate("1");
items[verwarmingsitemstring + "_Heating_Cooling_Target"].postUpdate("1");
If more than one tado zone is linked to a window, the script iterates over the relevant verwarmingsitemstrings, in this case Verwarming_keuken and Verwarming_eetkamer.
I still control Items Verwarming_keuken_mode and Verwarming_eetkamer_mode via the tado binding.
This is an extract from events.log:
2025-12-15 06:51:03.414 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Keukenvenster_noordoosten_status' changed from CLOSED to OPEN
2025-12-15 06:51:03.431 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Verwarming_keuken_Heating_Cooling_Target' received command 0
2025-12-15 06:51:03.432 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Verwarming_keuken_Heating_Cooling_Target' predicted to become 0
2025-12-15 06:51:03.434 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Verwarming_keuken_mode' changed from SCHEDULE to MANUAL
2025-12-15 06:51:03.436 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Verwarming_keuken_Heating_Cooling_Target' changed from 1 to 0
2025-12-15 06:51:03.436 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Verwarming_eetkamer_Heating_Cooling_Target' received command 0
2025-12-15 06:51:03.438 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Verwarming_eetkamer_mode' changed from SCHEDULE to MANUAL
2025-12-15 06:51:03.439 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Verwarming_eetkamer_Heating_Cooling_Target' predicted to become 0
2025-12-15 06:51:03.440 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Verwarming_eetkamer_Heating_Cooling_Target' changed from 1 to 0
2025-12-15 06:51:07.147 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Verwarming_keuken_mode' changed from MANUAL to SCHEDULE
2025-12-15 06:51:07.228 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Verwarming_eetkamer_mode' changed from MANUAL to SCHEDULE
2025-12-15 06:51:09.455 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Keukenvenster_noordoosten_status' changed from OPEN to CLOSED
2025-12-15 06:51:09.488 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Verwarming_keuken_mode' received command SCHEDULE
2025-12-15 06:51:09.493 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Verwarming_keuken_mode' predicted to become SCHEDULE
2025-12-15 06:51:09.493 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'Verwarming_eetkamer_mode' received command SCHEDULE
2025-12-15 06:51:09.493 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Verwarming_keuken_Heating_Cooling_Current' changed from 0 to 1
2025-12-15 06:51:09.494 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Verwarming_keuken_Heating_Cooling_Target' changed from 0 to 1
2025-12-15 06:51:09.494 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Verwarming_eetkamer_Heating_Cooling_Current' changed from 0 to 1
2025-12-15 06:51:09.494 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Verwarming_eetkamer_Heating_Cooling_Target' changed from 0 to 1
2025-12-15 06:51:09.496 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'Verwarming_eetkamer_mode' predicted to become SCHEDULE
2025-12-15 06:51:50.342 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Verwarming_eetkamer_Heating_Cooling_Target' changed from 1 to 0
2025-12-15 06:51:50.344 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Verwarming_eetkamer_Heating_Cooling_Current' changed from 1 to 0
For some reason, Verwarming_eetkamer_Heating_Cooling_Target was switched to 0 again⦠Maybe because there are two Channels (for the two Things) connected to this Item?
This is the relevant extract from the log of the HomeKit binding:
2025-12-15 06:51:03.451 [TRACE] [.handler.HomekitBaseAccessoryHandler - 47375 ] - homekit:bridged-accessory:72157980e9e1:2 throttling call for 1999 ms to respect minimum interval
2025-12-15 06:51:03.451 [TRACE] [.handler.HomekitBaseAccessoryHandler - 45527 ] - homekit:bridged-accessory:72157980e9e1:5 throttling call for 1999 ms to respect minimum interval
2025-12-15 06:51:03.453 [TRACE] [.handler.HomekitBaseAccessoryHandler - 46801 ] - homekit:bridged-accessory:72157980e9e1:6 throttling call for 1999 ms to respect minimum interval
2025-12-15 06:51:05.450 [TRACE] [mekit.internal.transport.IpTransport - 47375 ] - HTTP request:
PUT /characteristics HTTP/1.1
Host: tado\032Internet\032Bridge\032IB3857268224._hap._tcp.local.
Content-Length: 50
Content-Type: application/hap+json
{"characteristics":[{"iid":13,"value":0,"aid":2}]}
2025-12-15 06:51:05.469 [TRACE] [mekit.internal.transport.IpTransport - 47375 ] - HTTP response:
HTTP/1.1 204 No Content
Content-Length:0
2025-12-15 06:51:05.718 [TRACE] [mekit.internal.transport.IpTransport - 46801 ] - HTTP request:
PUT /characteristics HTTP/1.1
Host: tado\032Internet\032Bridge\032IB3857268224._hap._tcp.local.
Content-Length: 50
Content-Type: application/hap+json
{"characteristics":[{"iid":13,"value":0,"aid":6}]}
2025-12-15 06:51:05.770 [TRACE] [mekit.internal.transport.IpTransport - 46801 ] - HTTP response:
HTTP/1.1 204 No Content
Content-Length:0
2025-12-15 06:51:06.021 [TRACE] [mekit.internal.transport.IpTransport - 45527 ] - HTTP request:
PUT /characteristics HTTP/1.1
Host: tado\032Internet\032Bridge\032IB3857268224._hap._tcp.local.
Content-Length: 50
Content-Type: application/hap+json
{"characteristics":[{"iid":13,"value":0,"aid":5}]}
2025-12-15 06:51:06.072 [TRACE] [mekit.internal.transport.IpTransport - 45527 ] - HTTP response:
HTTP/1.1 204 No Content
Content-Length:0
2025-12-15 06:51:50.247 [TRACE] [mekit.internal.transport.IpTransport - 47432 ] - HTTP request:
GET /characteristics?id=6.14,6.13,4.12,4.13,6.15,4.14,4.15,10.12,10.13,2.15,2.14,2.13,2.12,6.12,10.14,10.15,7.15,5.12,7.14,5.13,5.14,5.15,3.15,3.14,3.13,9.14,3.12,9.15,7.13,9.12,7.12,9.13 HTTP/1.1
Host: tado\032Internet\032Bridge\032IB3857268224._hap._tcp.local.
2025-12-15 06:51:50.339 [TRACE] [mekit.internal.transport.IpTransport - 47432 ] - HTTP response:
HTTP/1.1 200 OK
Content-Length:983
Content-Type:application/hap+json
{"characteristics":[{"aid":2,"iid":12,"value":0},{"aid":2,"iid":13,"value":0},{"aid":2,"iid":14,"value":18.1},{"aid":2,"iid":15,"value":18},{"aid":3,"iid":12,"value":0},{"aid":3,"iid":13,"value":1},{"aid":3,"iid":14,"value":19.3},{"aid":3,"iid":15,"value":17},{"aid":4,"iid":12,"value":0},{"aid":4,"iid":13,"value":1},{"aid":4,"iid":14,"value":17},{"aid":4,"iid":15,"value":17},{"aid":5,"iid":12,"value":0},{"aid":5,"iid":13,"value":1},{"aid":5,"iid":14,"value":18.9},{"aid":5,"iid":15,"value":18},{"aid":6,"iid":12,"value":0},{"aid":6,"iid":13,"value":0},{"aid":6,"iid":14,"value":18.1},{"aid":6,"iid":15,"value":18},{"aid":7,"iid":12,"value":0},{"aid":7,"iid":13,"value":1},{"aid":7,"iid":14,"value":19.5},{"aid":7,"iid":15,"value":17},{"aid":9,"iid":12,"value":0},{"aid":9,"iid":13,"value":1},{"aid":9,"iid":14,"value":17.2},{"aid":9,"iid":15,"value":17},{"aid":10,"iid":12,"value":0},{"aid":10,"iid":13,"value":1},{"aid":10,"iid":14,"value":17.2},{"aid":10,"iid":15,"value":17}]}
For some reason, the HomeKit binding went 44 seconds without a GET requestā¦
But more importantly, {"aid":5,"iid":13,"value":1}, while {"aid":2,"iid":13,"value":0} and {"aid":6,"iid":13,"value":0}ā¦
Logs from the tado Binding:
2025-12-15 06:50:07.154 [DEBUG] [ado.internal.handler.TadoZoneHandler] - Updating state of home 1375166 and zone 8
2025-12-15 06:51:07.134 [TRACE] [ado.internal.handler.TadoZoneHandler] - Api response: homeId:1375166, zoneId:5, objectId:ZoneState, content:
{
"tadoMode": "HOME",
"geolocationOverride": false,
"setting": {
"power": "ON",
"temperature": {
"celsius": 17.0,
"fahrenheit": 62.6
},
"type": "HEATING"
},
"link": {
"state": "ONLINE"
},
"activityDataPoints": {
"heatingPower": {
"timestamp": "2025-12-15T05:49:42.171Z",
"percentage": 0.0
}
},
"sensorDataPoints": {
"insideTemperature": {
"timestamp": "2025-12-15T05:47:34.15Z",
"celsius": 19.39,
"fahrenheit": 66.9
},
"humidity": {
"timestamp": "2025-12-15T05:47:34.15Z",
"percentage": 66.5
}
}
}
2025-12-15 06:51:07.134 [DEBUG] [ado.internal.handler.TadoZoneHandler] - Updating state of home 1375166 and zone 5
2025-12-15 06:51:07.134 [TRACE] [ado.internal.handler.TadoZoneHandler] - Api response: homeId:1375166, zoneId:9, objectId:ZoneState, content:
{
"tadoMode": "HOME",
"geolocationOverride": false,
"setting": {
"power": "ON",
"temperature": {
"celsius": 17.0,
"fahrenheit": 62.6
},
"type": "HEATING"
},
"link": {
"state": "ONLINE"
},
"activityDataPoints": {
"heatingPower": {
"timestamp": "2025-12-15T05:35:02.599Z",
"percentage": 0.0
}
},
"sensorDataPoints": {
"insideTemperature": {
"timestamp": "2025-12-15T05:48:45.524Z",
"celsius": 19.51,
"fahrenheit": 67.12
},
"humidity": {
"timestamp": "2025-12-15T05:48:45.524Z",
"percentage": 51.4
}
}
}
2025-12-15 06:51:07.134 [DEBUG] [ado.internal.handler.TadoZoneHandler] - Updating state of home 1375166 and zone 9
2025-12-15 06:51:07.141 [TRACE] [ado.internal.handler.TadoZoneHandler] - Api response: homeId:1375166, zoneId:6, objectId:ZoneState, content:
{
"tadoMode": "HOME",
"geolocationOverride": false,
"setting": {
"power": "ON",
"temperature": {
"celsius": 18.0,
"fahrenheit": 64.4
},
"type": "HEATING"
},
"link": {
"state": "ONLINE"
},
"activityDataPoints": {
"heatingPower": {
"timestamp": "2025-12-15T05:32:46.461Z",
"percentage": 0.0
}
},
"sensorDataPoints": {
"insideTemperature": {
"timestamp": "2025-12-15T05:50:32.459Z",
"celsius": 18.92,
"fahrenheit": 66.06
},
"humidity": {
"timestamp": "2025-12-15T05:50:32.459Z",
"percentage": 53.3
}
}
}
2025-12-15 06:51:07.141 [DEBUG] [ado.internal.handler.TadoZoneHandler] - Updating state of home 1375166 and zone 6
2025-12-15 06:51:07.142 [TRACE] [ado.internal.handler.TadoZoneHandler] - Api response: homeId:1375166, zoneId:3, objectId:ZoneState, content:
{
"tadoMode": "HOME",
"geolocationOverride": false,
"setting": {
"power": "ON",
"temperature": {
"celsius": 17.0,
"fahrenheit": 62.6
},
"type": "HEATING"
},
"link": {
"state": "ONLINE"
},
"activityDataPoints": {
"heatingPower": {
"timestamp": "2025-12-15T05:36:30.404Z",
"percentage": 0.0
}
},
"sensorDataPoints": {
"insideTemperature": {
"timestamp": "2025-12-15T05:38:31.294Z",
"celsius": 17.26,
"fahrenheit": 63.07
},
"humidity": {
"timestamp": "2025-12-15T05:38:31.294Z",
"percentage": 54.4
}
}
}
2025-12-15 06:51:07.142 [DEBUG] [ado.internal.handler.TadoZoneHandler] - Updating state of home 1375166 and zone 3
2025-12-15 06:51:07.223 [TRACE] [ado.internal.handler.TadoZoneHandler] - Api response: homeId:1375166, zoneId:2, objectId:ZoneState, content:
{
"tadoMode": "HOME",
"geolocationOverride": false,
"setting": {
"power": "ON",
"temperature": {
"celsius": 18.0,
"fahrenheit": 64.4
},
"type": "HEATING"
},
"link": {
"state": "ONLINE"
},
"activityDataPoints": {
"heatingPower": {
"timestamp": "2025-12-15T05:43:09.629Z",
"percentage": 0.0
}
},
"sensorDataPoints": {
"insideTemperature": {
"timestamp": "2025-12-15T05:43:38.497Z",
"celsius": 18.18,
"fahrenheit": 64.72
},
"humidity": {
"timestamp": "2025-12-15T05:43:38.497Z",
"percentage": 55.1
}
}
}
2025-12-15 06:51:07.223 [DEBUG] [ado.internal.handler.TadoZoneHandler] - Updating state of home 1375166 and zone 2
2025-12-15 06:51:07.257 [TRACE] [ado.internal.handler.TadoZoneHandler] - Api response: homeId:1375166, zoneId:8, objectId:ZoneState, content:
{
"tadoMode": "HOME",
"geolocationOverride": false,
"setting": {
"power": "ON",
"temperature": {
"celsius": 17.0,
"fahrenheit": 62.6
},
"type": "HEATING"
},
"link": {
"state": "ONLINE"
},
"activityDataPoints": {
"heatingPower": {
"timestamp": "2025-12-15T05:48:15.594Z",
"percentage": 0.0
}
},
"sensorDataPoints": {
"insideTemperature": {
"timestamp": "2025-12-15T05:37:13.712Z",
"celsius": 17.01,
"fahrenheit": 62.62
},
"humidity": {
"timestamp": "2025-12-15T05:37:13.712Z",
"percentage": 49.3
}
}
}
2025-12-15 06:51:07.257 [DEBUG] [ado.internal.handler.TadoZoneHandler] - Updating state of home 1375166 and zone 8
2025-12-15 06:51:14.500 [DEBUG] [ado.internal.handler.TadoZoneHandler] - Removing overlay of home 1375166 and zone 6
2025-12-15 06:51:14.505 [DEBUG] [ado.internal.handler.TadoZoneHandler] - Removing overlay of home 1375166 and zone 2
2025-12-15 06:51:14.670 [TRACE] [ado.internal.handler.TadoZoneHandler] - Api response: homeId:1375166, zoneId:6, objectId:ZoneState, content:
{
"tadoMode": "HOME",
"geolocationOverride": false,
"setting": {
"power": "ON",
"temperature": {
"celsius": 18.0,
"fahrenheit": 64.4
},
"type": "HEATING"
},
"link": {
"state": "ONLINE"
},
"activityDataPoints": {
"heatingPower": {
"timestamp": "2025-12-15T05:32:46.461Z",
"percentage": 0.0
}
},
"sensorDataPoints": {
"insideTemperature": {
"timestamp": "2025-12-15T05:50:32.459Z",
"celsius": 18.92,
"fahrenheit": 66.06
},
"humidity": {
"timestamp": "2025-12-15T05:50:32.459Z",
"percentage": 53.3
}
}
}
2025-12-15 06:51:14.670 [DEBUG] [ado.internal.handler.TadoZoneHandler] - Updating state of home 1375166 and zone 6
2025-12-15 06:51:14.678 [TRACE] [ado.internal.handler.TadoZoneHandler] - Api response: homeId:1375166, zoneId:2, objectId:ZoneState, content:
{
"tadoMode": "HOME",
"geolocationOverride": false,
"setting": {
"power": "ON",
"temperature": {
"celsius": 18.0,
"fahrenheit": 64.4
},
"type": "HEATING"
},
"link": {
"state": "ONLINE"
},
"activityDataPoints": {
"heatingPower": {
"timestamp": "2025-12-15T05:43:09.629Z",
"percentage": 0.0
}
},
"sensorDataPoints": {
"insideTemperature": {
"timestamp": "2025-12-15T05:43:38.497Z",
"celsius": 18.18,
"fahrenheit": 64.72
},
"humidity": {
"timestamp": "2025-12-15T05:43:38.497Z",
"percentage": 55.1
}
}
}
2025-12-15 06:51:14.678 [DEBUG] [ado.internal.handler.TadoZoneHandler] - Updating state of home 1375166 and zone 2
2025-12-15 06:52:07.243 [TRACE] [ado.internal.handler.TadoZoneHandler] - Api response: homeId:1375166, zoneId:9, objectId:ZoneState, content:
{
"tadoMode": "HOME",
"geolocationOverride": false,
"setting": {
"power": "ON",
"temperature": {
"celsius": 17.0,
"fahrenheit": 62.6
},
"type": "HEATING"
},
"link": {
"state": "ONLINE"
},
"activityDataPoints": {
"heatingPower": {
"timestamp": "2025-12-15T05:35:02.599Z",
"percentage": 0.0
}
},
"sensorDataPoints": {
"insideTemperature": {
"timestamp": "2025-12-15T05:48:45.524Z",
"celsius": 19.51,
"fahrenheit": 67.12
},
"humidity": {
"timestamp": "2025-12-15T05:48:45.524Z",
"percentage": 51.4
}
}
}
2025-12-15 06:52:07.243 [DEBUG] [ado.internal.handler.TadoZoneHandler] - Updating state of home 1375166 and zone 9
2025-12-15 06:52:07.248 [TRACE] [ado.internal.handler.TadoZoneHandler] - Api response: homeId:1375166, zoneId:3, objectId:ZoneState, content:
{
"tadoMode": "HOME",
"geolocationOverride": false,
"setting": {
"power": "ON",
"temperature": {
"celsius": 17.0,
"fahrenheit": 62.6
},
"type": "HEATING"
},
"link": {
"state": "ONLINE"
},
"activityDataPoints": {
"heatingPower": {
"timestamp": "2025-12-15T05:36:30.404Z",
"percentage": 0.0
}
},
"sensorDataPoints": {
"insideTemperature": {
"timestamp": "2025-12-15T05:51:31.17Z",
"celsius": 17.11,
"fahrenheit": 62.8
},
"humidity": {
"timestamp": "2025-12-15T05:51:31.17Z",
"percentage": 54.8
}
}
}
2025-12-15 06:52:07.249 [DEBUG] [ado.internal.handler.TadoZoneHandler] - Updating state of home 1375166 and zone 3
2025-12-15 06:52:07.253 [TRACE] [ado.internal.handler.TadoZoneHandler] - Api response: homeId:1375166, zoneId:5, objectId:ZoneState, content:
{
"tadoMode": "HOME",
"geolocationOverride": false,
"setting": {
"power": "ON",
"temperature": {
"celsius": 17.0,
"fahrenheit": 62.6
},
"type": "HEATING"
},
"link": {
"state": "ONLINE"
},
"activityDataPoints": {
"heatingPower": {
"timestamp": "2025-12-15T05:49:42.171Z",
"percentage": 0.0
}
},
"sensorDataPoints": {
"insideTemperature": {
"timestamp": "2025-12-15T05:47:34.15Z",
"celsius": 19.39,
"fahrenheit": 66.9
},
"humidity": {
"timestamp": "2025-12-15T05:47:34.15Z",
"percentage": 66.5
}
}
}
2025-12-15 06:52:07.253 [DEBUG] [ado.internal.handler.TadoZoneHandler] - Updating state of home 1375166 and zone 5
2025-12-15 06:52:07.260 [TRACE] [ado.internal.handler.TadoZoneHandler] - Api response: homeId:1375166, zoneId:6, objectId:ZoneState, content:
{
"tadoMode": "HOME",
"geolocationOverride": false,
"setting": {
"power": "ON",
"temperature": {
"celsius": 18.0,
"fahrenheit": 64.4
},
"type": "HEATING"
},
"link": {
"state": "ONLINE"
},
"activityDataPoints": {
"heatingPower": {
"timestamp": "2025-12-15T05:32:46.461Z",
"percentage": 0.0
}
},
"sensorDataPoints": {
"insideTemperature": {
"timestamp": "2025-12-15T05:51:22.509Z",
"celsius": 18.92,
"fahrenheit": 66.06
},
"humidity": {
"timestamp": "2025-12-15T05:51:22.509Z",
"percentage": 53.3
}
}
}
2025-12-15 06:52:07.261 [DEBUG] [ado.internal.handler.TadoZoneHandler] - Updating state of home 1375166 and zone 6
2025-12-15 06:52:07.354 [TRACE] [ado.internal.handler.TadoZoneHandler] - Api response: homeId:1375166, zoneId:2, objectId:ZoneState, content:
{
"tadoMode": "HOME",
"geolocationOverride": false,
"overlay": {
"setting": {
"power": "OFF",
"type": "HEATING"
},
"termination": {
"type": "MANUAL"
}
},
"setting": {
"power": "OFF",
"type": "HEATING"
},
"link": {
"state": "ONLINE"
},
"activityDataPoints": {
"heatingPower": {
"timestamp": "2025-12-15T05:43:09.629Z",
"percentage": 0.0
}
},
"sensorDataPoints": {
"insideTemperature": {
"timestamp": "2025-12-15T05:43:38.497Z",
"celsius": 18.18,
"fahrenheit": 64.72
},
"humidity": {
"timestamp": "2025-12-15T05:43:38.497Z",
"percentage": 55.1
}
}
}
2025-12-15 06:52:07.354 [DEBUG] [ado.internal.handler.TadoZoneHandler] - Updating state of home 1375166 and zone 2
I donāt see why this went wrongā¦? Why didnāt 2025-12-15 06:51:14.505 [DEBUG] [ado.internal.handler.TadoZoneHandler] - Removing overlay of home 1375166 and zone 2 do the trick?
You mentioned too many things at the same time in your post, so it is not clear what actually are you complaining about. So can you please be more precise?
ā-
But anyway a few thoughts..
- You said it takes 44 seconds before the next GET request. So why do you think that is a problem? The things have a default refresh cycle of 60 seconds.
- Normally if a channel is evented then you might see an EVENT message (and respective item state update) when that channel changes state.
- HOWEVER the HomeKit spec requires the accessories to consolidate multiple fast events. Which means that a value toggle change might cancel out and no event be sent at all.
The real-world problem (or problematic symptom) is that the heating in the dining room (āEetkamerā) didnāt get turned on again.
And this is something unexpected, which is a symptom of the problem.
So is it a problem with the HomeKit binding? Or is it a problem with the tado binding? Or is it a problem with the tado system? Or is it a problem with your system configuration? Or is it a problem with your rules? If you just throw everything in the pot, then I have no idea what is cooking. Also if you just say itās not cooking that doesnāt help me either. I need specifics. Please help me. Exactly what happens normally? And exactly what is not happening in this particular case?
How exactly does such a Channel EVENT log look like? Maybe for that to be visible, the log level needs to be raised?
I assume thatās the throttling call for 1999 ms?
Thatās the question, of course. ![]()
In essence, this is my JS rule:
var verwarmingsitemstrings: [
"Verwarming_keuken",
"Verwarming_eetkamer"
];
if ( [window is closed (pseudo-code)] ) {
for (itemstring in verwarmingsitemstrings) {
var verwarmingsitemstring = verwarmingsitemstrings[itemstring];
items[verwarmingsitemstring + "_mode"].sendCommand("SCHEDULE");
items[verwarmingsitemstring + "_Heating_Cooling_Current"].postUpdate("1");
items[verwarmingsitemstring + "_Heating_Cooling_Target"].postUpdate("1");
}
} else {
for (itemstring in verwarmingsitemstrings) {
var verwarmingsitemstring = verwarmingsitemstrings[itemstring];
items[verwarmingsitemstring + "_Heating_Cooling_Target"].sendCommand(0);
items[verwarmingsitemstring + "_mode"].postUpdate("MANUAL");
}
}
So if the window is opened, the heating is turned off via the heating-cooling-target Channel(s) of the HomeKit binding. Also, two Items are being updated:
- the Item connected to the
heating-cooling-currentChannel of the HomeKit binding, and - the Item connected to the
operationModeChannel of the tado binding.
If the window is closed, the heating is reactivated again via the operationMode Channel of the tado binding. Also, two Items are being updated:
- the Item connected to the
heating-cooling-targetChannel(s) of the HomeKit binding, and - the Item connected to the
heating-cooling-currentChannel(s) of the HomeKit binding.
For some reason, Item Verwarming_eetkamer_Heating_Cooling_Target (linked to Channels homekit:bridged-accessory:72157980e9e1:6:thermostat#heating-cooling-target-13 and homekit:bridged-accessory:72157980e9e1:2:thermostat#heating-cooling-target-13) was switched to 0 again.
I donāt understand why, because the tado binding claimed it did what it was asked:
2025-12-15 06:51:14.505 [DEBUG] [ado.internal.handler.TadoZoneHandler] - Removing overlay of home 1375166 and zone 2
Log trace.
No. The accessory simply does not send an event.
You know how the tado binding works dont you? The device sends information to the hub. The hub sends the infornation to the cloud. The binding polls the cloud. So there is a lot of latency in that process. Potentially minutes.
By contrast, the Homekit binding is locally connected to the hub. If only relying on polling there may be latency of up to one minute. But if relying on eventing it may be immediate. Unless the events are so closely spaced that they cancel each other within one event conflation.
In short your logic āwhen this, then thatā has too many variables to permit deducing anything meaningful about the consequent state..
Of what exactly? Because Iām of course already logging both bindings on TRACE level.
Sure, but I donāt rely on any polling. And the only command sent via the tado binding to the cloud, is what should be the last command anyway:
items[verwarmingsitemstring + "_mode"].sendCommand("SCHEDULE");
So that command should arrive last.
Also here, my rule doesnāt rely on any polling. It sends only one command:
items[verwarmingsitemstring + "_Heating_Cooling_Target"].sendCommand(0);
I would expect that command to reach my tado bridge long before the command sent to the cloud, especially, since that command to the cloud is sent later.
But technically, this does translate to 2 commands: there are 2 Channels linked to that Item, both for one Thing.
Since either operation (opening the window or closing the window) only sends out one command, and does so via a different binding, this canāt occur in my setup, I would think.
If you dont see any EVENT messages with log trace turned on, then apparently your device does not support eventing.
But anyway, I think we are going in circles, so let me make this clear: unless you can give me specific causal exanples if what you think is sometimes going wrong, then I regret I cannot help you. You are not even telling me which binding you think is going wrong..
Not because I refuse to, but because I donāt know. I hoped to find a way to pinpoint the problem in this topic. ![]()
But I actually suspect the root of the problem is because the thermostat is in the mix, not just TVRās. My rule works in other setups with only TVRās, although in those rooms, the relevant Items are always only linked to one Channel.
So as an experiment, I unlinked Verwarming_eetkamer_Heating_Cooling_Target from homekit:bridged-accessory:72157980e9e1:2:thermostat#heating-cooling-target-13 (the thermostat). Weāll see if the erratic behavior persists. Or whether this causes other unwanted behaviorā¦
hi there,
Today, I attempted to integrate the Tado Bridge, which I added to HomeKit, via the HomeKit binding in OH 5.1. It is detected via AutoDiscovery, but the pairing fails.
I assume this is because it is already connected (sf = 0).
Is there a way to cancel the pairing?
Many thanks
Yes there is a Methos by pressing and holding one of the buttons on the bridge. But youāll need to look up the tado documentation to prevent the accidentak resetting of the thermostats.
You can also activate pairing from the tado app. Seems easier ![]()
But maybe thatās not the problem/solution?
And if it is already in the Apple Home App you can go to the Apple Home App Settings and remove it.
That was the solution. I assumed that the bridge also had to be integrated into HomeKit⦠After removing it from HomeKit, the pairing worked.![]()
Most devices will only pair with one controller.
If you want the data in both OH and in the Apple Home app, then import the data into OH via the OH Homekit binding, and then re-export the items from OH to the Home app via the OH Homekit io integration.
Just picking up on this last point. Iām running OH 5.1.1 and have a HomeKit Bridge setup through the HomeKit add-on.
In the HomeKit App, Iām seeing my OH items (e.g Tradfri Lights) and can control them as expected.
As an experiment, Iāve added a few existing Tado X TRVs directly to HomeKit app on my iPhone. These are all paired and working with the Tado Programmer X. I can control them via the HomeKit App on my iPhone as expected.
Iāve installed the HomeKit binding and it is discovering all of my OH items from HomeKit, except for the Tado X items.
My question is: Should the HomeKit Binding be exposing the Tado X TRVs to OH when configured in this way? Should I be able to āseeā the TRVs in discovery through the UI and maybe read the temperature in a room from there? Or am I completely wrong!!
Thanks
Depending on the manufacturer and device concerned, I have observed at least three different behaviours as far as discovery is concerned (there may be others):
-
The device always advertises itself via mDNS regardless of whether it is already paired with Apple Home. (But obviously if it is already paired it cannot be paired also with the OH binding).
-
The device only advertises itself via mDNS if it is not already paired with something.
-
The device only advertises itself via mDNS if it is specifically instructed. This may be via a physical button on the device, or a command from the manufacturerās App. Often the discovery mode expires after some time.