Announce new HomeKit client binding

Add-ons Bindings
101

Hi,

This is not embeded accessory. it is standalone.

When I restarted the accessory then I started getting connection refused error. Based on my understanding homekit accessory changes the port in certain cases. This then not allow the thing to connect to device.

but after i did the restart of OH everything seems to be working fine again. Let me keep watch on this.

I will keep you posted if I find anything not working as intended.

102

In theory the mDNS discovery should update the Thing’s configured Ip address and Port if it would change. The is a surprising feature of OH that I only learned about this week. Certainly a restart of OH would cause such an update. But also background mDNS scans would probably also do it from timevto time.

103

Hi @AndrewFG ,

The latest jar seems to work fine. I m not seeing any errors and all fp2 sensors and doorbell is working fine. Snapshot is also getting updated based on doorbell event , motion or doorbell press.

Will let you know if I find anything

Thanks for all the help.

104

Thanks to you too. :slight_smile:

105

Hi @AndrewFG,

I m seeing connection refused error for accessories if they are restarted. I have assigned static ip for all accessories but port also i belive changes if homekit accessory restarts. I think binding is not listening to mDNS update event. This might be issue based on my chat on copilot.

I have to restart the openhab to get homekit accessories reconnected.

Thanks!

106

What do you mean by “restarted”? Is it restarting OH? Restarting the binding? Disabling and reenabling the Thing in OH? Or power cycling the physical device?

And in any case can you provide a Trace log for when the Thing is connected before such restart, and ditto after such restart?

107

Hi @AndrewFG,

by restart i mean rebooting openhab. Enable /disable of binding does not work. I can reconnect to homekit accessories again only after doing reboot of openhab.

This happens when accessory is power cycled physically. FP2 aqara presence sensor is powered by usb and same with doorbell. These are not battary powered.

The place I live power, outage happen once in awhile.

Will share logs soon.

Thanks!

108

The Thing has an ipAddress configuration parameter (like 123.123.123.123:45678). This is initially set by the mDNS discovery process for the respective accessory. And if the accessory goes away and comes back again with a new IP address, then the next mDNS discovery refresh cycle should also ‘auto-magically’ update the Thing’s ipAddress configuration parameter.

=> So when you next have one of your accessories going offline in this way, can you please check if its ipAddress configuration parameter did indeed update, or does it is still show the old IP address?

109

Hi @AndrewFG , I have set static ip for all accessories. What i m observing is port also gets updated. And then it breaks connection.

I m away from home for some time. Will see if I can replicate remotely the seneario.

Thanks.

110

Same comment as before since ipAddress is an amalgam of the dotted ipv4 address and the port number.

111

As a general rule, when the binding has a connection error, it will retry the connection; whereby the interval between reconnection attempts increases from 2 seconds by square law (2,4,16,256) to 300 seconds. So after the port value self- adjusts it will probably take 2+4+16+256+300 seconds (about 10 minutes) to recover.

However this will make it quicker..

112

Hi @AndrewFG ,

I m running your latest jar you shared previous with me. I keep on facing issue of accessories not connecting to binding. Issue i found is if my network or router restarts the binding still uses old port to connect to devices but generally they are updated. I m manually updating the port no in each device thing.

I have set static ip for all devices that is why only port is incorrect. I used service browser to check the port of device in following information in mdns.

_hap._tcp.local

I have a general network connection refused error in logs.

113

@tizen thanks for reporting this. Just to make sure that I fully understand this issue, can you please confirm that the binding is keeping the prior configured port number on its side, and it is the actual devices that are changing their port numbers on their side?

It depends on what type of Thing you have (see below) .. but it may be that you just need to wait some time before the port number will be auto updated.

There are two sources of Things in OH – namely 1) those created directly from a discovered Thing in the inbox (called a ‘Managed Thing’), or 2) those created manually from a .things file.

  1. Managed Things

    • config params come from the inbox discovery result
    • if inbox discovery results change (e.g. a new port id) then thing config params get updated automatically
    • but you can also manually edit the config params too

  2. File based Things

    • config params come from the file
    • if inbox discovery results change (e.g. a new port id) then thing config params do NOT get updated
    • but you can manually edit the the .things file to change the config params

If your Thing is Managed and it changes its port id, then – when it is next re-discovered into the Inbox, (with a new port id) – then in general OH Core will automatically update the configuration for you. Perhaps you are being too fast in manually changing the configuration. Are you letting enough time for the OH discovery process to do the auto update of the configuration?

By contrast if your Thing is File based and it changes its port id, then OH Core cannot automatically update the configuration for you. And in this case you will need to edit the file yourself.

114

Thanks @AndrewFG for quick reply. The port is changing from device side. Thing keeps old port no.

I have used managed approach I.e device is auto discovered and I have added them from inbox. I m not using file based thing config.

I have waited several hours but devices remain offline due to port change. I also did openhab restart but thing keeps old port no.

I have observed this over several weeks before I reported it today.

115

Hmm. Then something is going wrong concerning how OH Core is (not) updating the thing configuration. If I remember it right you are on OH v4 ? Or an early version of v5 ? In more recent versions of v5 we did some more work on mDNS discovery which may have resolved whatever issue you may have. Can you try it on an OH v5.2 snapshot? Unfortunately it will not be possible for me to debug on a prior version.

116

Hi @AndrewFG

I m on OH 5.1.0 release version. I also think issue with oh core as after OH restart the config is not updated.

Let me see if I can move to 5.2.0

Thanks for you support!