It looks like I messed something up. And I am really surprised to see the bridge in the inbox, since I did nothing in that area. So I need to figure it out. In the meantime I will put up a jar that reverts the prior changes. I will let you know when it is ready.
OK. The reverted JAR is on the link below. I need to do some deeper work concerning how to handle the embedded children, so I will let you know (again) when I am ready. In the meantime I apologies for the confusion.
Hi @AndrewFG, updated jar to latest one. Everything starts to work. I re-paired the doorbell. Snapshot is working fine.
Will keep further testing.
Thanks for your support 
I modified the jar file to auto update the camera snapshot when the doorbell Thing either detects motion or the button is pressed.
You can download it here
@AndrewFG, what is the expected behavior or the Heating_Cooling_Current Channels of the tado TVRâs? The value never seems to be anything but Off. if I look at the linked Items, and also in the logs, the value is only very seldom 1.
Frankly I dont know what is âexpectedâ in the case of Tado. If you can again share the trace log of the GET \accessories call then maybe I can at least try to guess with you what it might be..
Hi guys,
first of all: Great work with the binding, Iâm blown away by how well it works. I used to control my tados with a node script running a server but this solution is much more to my liking (and more stable as well).
Yesterday, however, I ran into a weird problem. I have a time rule in OH to change the setpoint temperature to night mode, 16°C. This runs at 17:30. When I went into one of the rooms later, I noticed the radiator was warm and checked the TRV, it was still set to 21°C. The other rooms that got this setpoint received them correctly, tho (I checked in the tado app). The logs look like this:
2026-01-22 17:30:00.635 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'CurrentTempSetpointKids' received command 16
2026-01-22 17:30:00.636 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'CurrentTempSetpointKids' predicted to become 16
2026-01-22 17:30:00.639 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentTempSetpointKids' changed from 21 to 16 (source: org.openhab.core.autoupdate.optimistic)
<-- other stuff happening -->
2026-01-22 17:31:19.876 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentTempSetpointKids' changed from 16 to 21 (source: org.openhab.core.thing$homekit:bridged-accessory:4b1c09b55b:12:thermostat#temperature-target-15)
As you can see, one thermostat didnât accept the new target temperature and instead overwrote the one I set. Then different TRVs began to ping-pong the setpoint:
2026-01-22 17:31:19.880 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentTempSetpointKids' changed from 21 to 16 (source: org.openhab.core.thing$homekit:bridged-accessory:4b1c09b55b:13:thermostat#temperature-target-15)
2026-01-22 17:32:20.005 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentTempSetpointKids' changed from 16 to 21 (source: org.openhab.core.thing$homekit:bridged-accessory:4b1c09b55b:12:thermostat#temperature-target-15)
2026-01-22 17:32:20.009 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'CurrentTempSetpointKids' changed from 21 to 16 (source: org.openhab.core.thing$homekit:bridged-accessory:4b1c09b55b:13:thermostat#temperature-target-15)
It just didnât go through. I changed the setpoint in the tado app, then it worked.
Any idea what could cause this or what I could do to help you find the root cause?
Have a great weekend!
Christoph
I think the tado devices must be in manual mode before Homekit commands can work.
The devices are in manual mode and usually it works as it should (did so for 3+ weeks before it didnât for the one TRV on one evening, everything worked as intended again tonight)
No, thatâs not necessary.
The Apple specification says the following.
And your JSON confirms that it should comply with the Apple specification â namely that the value is a uint8, it is an evented channel, it has possible values of 0, 1, or 2, and its current value is 0.
{
"iid": 12,
"type": "F",
"perms": [
"pr",
"ev"
],
"value": 0,
"maxValue": 2,
"minValue": 0,
"minStep": 1,
"format": "uint8"
},
valueis only very seldom1
I guess that essentialy confirms the above. Or?
EDIT: for completeness here is the specification for Heating_Cooling_Target
Hello again,
I activated TRACE mode and waited until the error or a similar error happens again. Today, this was the case. Upon closing the window, the Tado TRV state gets updated to on and then, approx. 1 minute later, when the binding periodically refreshes all devices, it reads back a zero and thus turns it off again.
The logs (the binding refreshed all data, about 8s later the window was closed and the TRV was activated and another minute later the TRV reads back as OFF):
2026-02-01 08:07:58.435 [TRACE] [mekit.internal.transport.IpTransport] - HTTP request:
GET /characteristics?id=14.13,6.13,12.13,13.15,14.17,11.14,12.15,13.13,14.14,11.13,12.14,13.14,14.15,9.15,12.17,11.15,13.17,11.17 HTTP/1.1
Host: tado\032Internet\032Bridge._hap._tcp.local.
2026-02-01 08:07:58.752 [TRACE] [mekit.internal.transport.IpTransport] - HTTP response:
HTTP/1.1 200 OK
Content-Length:580
Content-Type:application/hap+json
{"characteristics":[{"aid":6,"iid":13,"value":0},{"aid":9,"iid":15,"value":21},{"aid":11,"iid":13,"value":1},{"aid":11,"iid":14,"value":18.1},{"aid":11,"iid":15,"value":17},{"aid":11,"iid":17,"value":38},{"aid":12,"iid":13,"value":1},{"aid":12,"iid":14,"value":14.9},{"aid":12,"iid":15,"value":16},{"aid":12,"iid":17,"value":36},{"aid":13,"iid":13,"value":0},{"aid":13,"iid":14,"value":15.3},{"aid":13,"iid":15,"value":16},{"aid":13,"iid":17,"value":38},{"aid":14,"iid":13,"value":0},{"aid":14,"iid":14,"value":16.4},{"aid":14,"iid":15,"value":16},{"aid":14,"iid":17,"value":33}]}
2026-02-01 08:08:05.336 [INFO ] [tomation.jsscripting.rule.f2253f130d] - Fenstersensoren_Julius (Type=GroupItem, BaseType=ContactItem, Members=2, State=CLOSED, Label=, Category=, Tags=[Window], Groups=[Julius])
2026-02-01 08:08:05.337 [INFO ] [tomation.jsscripting.rule.f2253f130d] - Fenstersensoren_Julius
2026-02-01 08:08:05.339 [INFO ] [tomation.jsscripting.rule.f2253f130d] - Sending Window Timer Julius Message Cancelled
2026-02-01 08:08:05.343 [TRACE] [mekit.internal.transport.IpTransport] - HTTP request:
PUT /characteristics HTTP/1.1
Host: tado\032Internet\032Bridge._hap._tcp.local.
Content-Length: 51
Content-Type: application/hap+json
{"characteristics":[{"iid":13,"value":1,"aid":14}]}
2026-02-01 08:08:05.413 [TRACE] [mekit.internal.transport.IpTransport] - HTTP response:
HTTP/1.1 204 No Content
Content-Length:0
2026-02-01 08:08:59.066 [TRACE] [mekit.internal.transport.IpTransport] - HTTP response:
HTTP/1.1 200 OK
Content-Length:580
Content-Type:application/hap+json
{"characteristics":[{"aid":6,"iid":13,"value":0},{"aid":9,"iid":15,"value":21},{"aid":11,"iid":13,"value":1},{"aid":11,"iid":14,"value":18.1},{"aid":11,"iid":15,"value":17},{"aid":11,"iid":17,"value":38},{"aid":12,"iid":13,"value":1},{"aid":12,"iid":14,"value":14.9},{"aid":12,"iid":15,"value":16},{"aid":12,"iid":17,"value":36},{"aid":13,"iid":13,"value":1},{"aid":13,"iid":14,"value":15.3},{"aid":13,"iid":15,"value":16},{"aid":13,"iid":17,"value":38},{"aid":14,"iid":13,"value":0},{"aid":14,"iid":14,"value":16.3},{"aid":14,"iid":15,"value":16},{"aid":14,"iid":17,"value":33}]}
Is this of any help?
Have a nice sunday
Christoph
Umm. Can you please clarify exactly what is your issue?
aid=13 ?iid=13?homekit:bridged-accessory:4b1c09b55b:13:thermostat#heating-cooling-target-13 or alias 13.13 for short.13.13 channel is represented in the JSON logs by {"aid":13,"iid":13,"value":N} where N may change..08:07:58.752 the value of 13.13 / N is 0 i.e. OFF08:08:05.343 you sent a â1â command to the same channel iid=13 of a different Thing aid=14 alias 14.13 / 1 => no relevance to the state of 13.13..08:08:59.066 the value 13.13 / N is 1 i.e. HEATAnd BTW the 13.x thing has only four channels that are linked to Items as follows. I am guessing that it also has a channel 13.12 which is NOT linked to an Item?
13.13 = 0 resp. 113.14 = 15.3 C13.15 = 16 C13.17 = 38 %Did I make any mistakes in the above summary? And if not, then which part of the above is the problem that you are concerned about?
EDIT 2: given that Tact = 15.3, Tset = 16, and you say it went from window open to closed then the observed change of Heat_cooling_target from âOFFâ to âHEATâ seems entirely correct..
Hi
Sorry I didnât specify. The TRV Iâm having trouble with right now is aid 14, the characteristic iid 13. It was set to 1 (TRV on) and reset by the binding refreshing the data in the lower log 08:08:59. There you can see
{"aid":14,"iid":13,"value":0}
Itâs a bit confusing because the aid/iid order is flipped.
Kind Regards
Christoph
So it looks exactly as you say it. The state is 0 / OFF then you send a command 1 / HEAT and the command is accepted (204 OK) and then it reverts again to 0 / OFF.
The binding is only (correctly) representing the status of the device.
Notwithstanding what @ErikDB said, I think if the device is in auto mode via the app, then any manual commands from the binding will be rejected.
Note: this is a tado specific issue, and I regret that there is nothing that I can do on the binding side.
However please also look at the 14.12 channel just in caseâŠ
Thanks for the reply. I was kind of expecting it to be tados fault tbh because I had similar problems before with my own script. Iâm just gonna add an item for each room and link that to the respective channel and then check everytime the state or temperature of that changes if the setpoint is the same and of not correct it.
Thanks a lot for your time!
Christoph
Sounds like what Iâve also experienced: Tado API limits & HomeKit binding - #104 by ErikDB.
I only experience it with one TVR, thoughâŠ
@tizen apropos our prior discussion about you door bell (I think) with embedded accessories: I have been thinking about it further. The proposed architecture is in this post .. specifically case 2b. Your Thing would have initially been discovered as a simple accessory Thing, so I am implementing code to migrate it to be a Bridge instead; and this Bridge would contain one âvirtualâ accessory with the channels within the actual doorbell, plus other accessory Things for the imported external accessories.
In my earlier code, I had forgotten about the discovery. The problem was that the normal accessory Thing would be in the Inbox, and when you instantiate that Thing, the code removes the Thing from the Inbox, and then it converts the instance to a Bridge. However the discovery service on the next scan does not see a normal accessory Thing anymore, so it adds a new one to the Inbox. I am currently working to suppress the re-discovery if a Thing gets converted to a Bridge
The child devices, plus the âvirtualâ child with the own channels, should indeed be discovered once the accessory Thing has been migrated to a Bridge.
I have not yet fully completed the revised code. But I will PM you with a link when it is ready..
Hi @AndrewFG ,
The latest jar seems to be working fine for bridged accessory.
I m now seeing below issue.
Let me know if you need any details
Thanks
Can you clarify that this is not an embedded sensor but rather a regular accessory?
And when you say the port number changes when restarted, can you say what you are restarting (openhab, the binding, or the accessory). And when you say the port number changes, is it the port number of the ip address configuration parameter in the binding, or is it the actual port number of the device itself? If you run an independent mDNS discovery app, what does it show?
EDIT and what does the port number change from and to? Is/was it some actual number that changed to 0 or 80 or vice versa?