[APP][Pro] HomeKit Controller - for a better Homey

[Peter_Bittner]

@Martin_Verbeek

Generic procedure to add a device.

1. Add your Homekit capable device to the app that came with the device and configure it.

2. If added with iOS device, remove the device from the iOS Home app, a device only can have one controller.

3. Most of the time the device can be discovered and added now, using the PIN.
   Additional services are made available over time, as its capabilities. But in some cases it can take multiple minutes that the homekit service is advertised on the network.
   As a start the Apple defined services and capabilities. When available some other vendor specific might be added as well.

I have gone through these steps. But still not able to discover the FP2. I’m assuming I select Homekit over IP.
Appreciate some help.

[David_De_Smedt]

Hi everyone,

I’m hoping someone (or Arie) can help me investigate what appears to be a HomeKit Controller discovery issue.

Environment
• Homey Pro (2023)
• HomeKit Controller 2.1.19
• Aqara FP2 firmware v1.3.6_0003.0099
• Apple TV configured as Home Hub
• Same LAN
• Synology network
• FP2 connected to 2.4 GHz WiFi

What works
FP2 works perfectly in the Aqara app.
FP2 can be paired with Apple Home immediately using the official HomeKit QR code.
Apple Home communicates with the FP2 correctly.

What does NOT work
HomeKit Controller never discovers the FP2.

I have tried:
• Removing the FP2 completely from Apple Home.
• Waiting until it disappears.
• Powering the FP2 off for more than 5 minutes.
• Powering it back on.
• Trying HomeKit Controller BEFORE adding it back to Apple Home.
• HomeKit over IP.
• HomeKit over Thread.
• Manual HomeKit setup code supplied by Aqara Technical Support.

The result is always:
“No new devices found.”

The HomeKit Controller debug log shows:
getMDNSPairableDevices for tcp
pairing found devices: []

So HomeKit Controller appears to find zero pairable HomeKit devices.

Aqara Technical Support has been very helpful. They even retrieved the original HomeKit pairing code and QR code from their backend. Apple Home accepts that QR code immediately, so I don’t believe this is an Aqara or FP2 issue.

Has anyone successfully paired an FP2 with HomeKit Controller 2.1.19 recently?

Or does this look like an mDNS discovery issue?

I’m happy to perform additional tests if needed.

Thanks!

David

[David_De_Smedt]

Additional diagnostics

I performed some additional network diagnostics that may help narrow this down.

The HomeKit Controller log consistently reports:

pairing found devices: []

To verify whether the FP2 was advertising HomeKit on the network, I used Avahi on a Linux machine (Synology NAS) connected to the same LAN.

Running:

avahi-browse -rt _hap._tcp

only discovers these HomeKit accessories:

• Homey Pro
• HomeKitty F91C

The Aqara FP2 never appears.

I also ran:

avahi-browse -at | grep Aqara
avahi-browse -at | grep Presence
avahi-browse -at | grep 192.168.1.239

All three return no results.

Current situation:

• FP2 works normally in the Aqara app.
• Apple Home pairs with and controls the FP2.
• Apple TV is configured as the Home Hub.
• FP2 is connected to the same LAN (2.4 GHz WiFi).
• HomeKit Controller never discovers the FP2.

I’ve attached a screenshot of the Avahi output. I can also provide the HomeKit Controller log screenshot if needed, but the forum currently limits me to one embedded image because this is a new account.

Based on these diagnostics, it appears the FP2 is not advertising a HomeKit (_hap._tcp) service that HomeKit Controller can discover on the network, even though Apple Home can pair with and control it normally. Does that point to an FP2/mDNS issue, or could HomeKit Controller still be missing something during discovery?

[David_De_Smedt]

@MartinVerbeek

I performed some additional diagnostics after my previous post.

• Factory reset of the FP2 completed.
• Apple Home immediately discovers and pairs with the FP2.
• Apple Home controls the FP2 correctly.
• HomeKit Controller still reports “No new devices found”.

I also verified the network using Avahi (avahi-browse -rt _hap._tcp). Other HomeKit accessories are advertised correctly, but the FP2 never appears.

Would it be possible to enable more detailed logging of the raw mDNS advertisements that HomeKit Controller receives, rather than only logging the list of pairable devices? That would help determine whether:

• the FP2 is advertising but being filtered out, or
• the FP2 never appears in the discovery process at all.

I’m happy to run any additional diagnostics if that would help.

Addition:

Aqara has now confirmed in writing that the FP2 advertises its HomeKit service using the standard _hap._tcp mechanism and that this behaviour does not change with firmware updates.

However, on my network an Avahi scan still only discovers Homey Pro and another HomeKit accessory. The FP2 never appears, even though Apple Home immediately discovers and pairs with it.

Does HomeKit Controller use a different discovery path than a standard mDNS browser such as Avahi, or is there additional debug logging that could show the raw advertisements HomeKit Controller receives?

[PvWoody]

Hi @Martin_Verbeek,

Thanks for fixing the Atag One Zone thermostat device class. It is now fully functional in Homey. Much appreciated!

[Martin_Verbeek]

Apologies David, have been very busy with other (non-Homey) things. I am using standard mDNS discovery.

I know for sure that Apple themselves are doing things a bit different when discovering devices.
Aqara app does not use mDNS, they have a straight IP connection.

But as it looks the FP2 never shows itself on the network thru mDNS, you gave the evidence for that by running the alternative discovery, it should show the advertisement in that case.

If the FP2 is paired to another controller, it will not show as a device capable of pairing in HK controller app. If the FP2 is still paired to Apple Home you should remove it. Then try again adding it to Homey (powercycle might help).

Another thing that sometimes messes things up is that the router has disabled Bonjour services (or called something similar).

You might check with the test version as well, HomeKit Controller | Homey. That should show services that are found:

2026-07-23T13:48:46.399Z [log] INITIAL SERVICEUP EMIT FOR Presence-Sensor-FP2-B820._hap._tcp.local
2026-07-23T13:48:46.400Z [log] Txt: {
sh: ‘4NBMtg==’,
ci: 10,
sf: 0,
‘s#’: 5181,
pv: ‘1.1’,
md: ‘PS-S02D’,
id: ‘EA:E8:6B:14:33:C3’,
ff: 2,
‘c#’: 31,
aid: 1,
class: ‘sensor’,
availableToPair: false, BOUND TO ANTOHER CONTROLLER
pairMethod: 0
}

[David_De_Smedt]

Thank you for taking the time to look into this and for explaining how the discovery works.

Unfortunately, I had already returned the FP2 before your reply, so I’m no longer able to test the development version or continue the diagnostics.

I’ll close this here for now. I may revisit the FP2 or a successor later, and if I do, I’ll test again from a clean setup.

Thanks again for your help and for maintaining the app.

[David_De_Smedt]

Hi @Martin_Verbeek

Could not resist after your last answer to reorder and try again …
But similar issue. Just would not connect.

Then tried with your test version. Connected immediately. Showing up in Homey.
Is it safe to keep using your test version?

Thanks so much for your time and support.

[Martin_Verbeek]

That is safe to use…

[Stijn_Dr]

Hello @Martin_Verbeek,

I have been trying to get my FP2 to work with my Homey Pro 2023, but am running into the following error. I have made sure the device is not in Apple Home, I have power cycled many times and the FP2 works well in the Aqara app.

After waiting some time, the FP2 shows up in HomeKit Controller, I can select it and I get to the filling in of the password and after doing that, I get the following error code time after time. Do you have any suggestions?

[Paul_Rade]

Hi Martin,

just like Dr Stijn, I have the same issue. With some help I managed to do some analysis:

Title: Netatmo Weather Station V4 pairing fails because accessory is already offline when Pair-Setup starts

Environment

• HomeKit Controller app: 2.2.9

• Homey Self-Hosted Server: 192.168.30.10

• Netatmo Weather Station V4: 192.168.30.248

• Netatmo MAC address:

• Homey SHS and Netatmo are on the same VLAN

• mDNS is enabled

• Client isolation was disabled during testing

• Other HAP devices, including a VELUX gateway and Netatmo Doorbell, work from the same SHS instance

Problem

The HomeKit Controller app discovers the Netatmo correctly:

• Service: Weather Station._hap._tcp.local

• Address: 192.168.30.248

• Port: 5001

• sf=1

• availableToPair=true

• pairMethod=1

After selecting the station and entering the HomeKit PIN, pairing fails after approximately 14 seconds.

The user-facing error is:

pairSetup Cannot set properties of null (setting 'errorCode') => undefined

The underlying log error is:

_requestClear Socket error 192.168.30.248 5001 EHOSTUNREACH

Reproduction

1. Remove the Netatmo Weather Station from Apple Home.

2. Put it into HomeKit commissioning mode; the LED pulses white.

3. Start HomeKit Controller pairing.

4. The Weather Station is discovered successfully.

5. Select it and enter the HomeKit PIN.

6. Pairing fails after approximately 14 seconds with the errors above.

This was reproduced three times.

Timing from the latest attempt

HomeKit Controller received the mDNS advertisement at:

2026-08-21T14:29:19.217Z INITIAL SERVICEUP EMIT FOR Weather Station._hap._tcp.local

UniFi shows:

• Station connected at approximately 14:29:18Z

• Station disconnected at approximately 14:30:50Z

HomeKit Controller did not start Pair-Setup until:

2026-08-21T14:31:08.974Z pairSetup
2026-08-21T14:31:08.975Z startPairing Connection
2026-08-21T14:31:08.975Z startPairing M1

It therefore started the TCP connection approximately 19 seconds after the station had already disconnected.

The failure followed at:

2026-08-21T14:31:23.244Z pairing not successful
Cannot set properties of null (setting 'errorCode')

2026-08-21T14:31:23.244Z
_requestClear Socket error 192.168.30.248 5001 EHOSTUNREACH

Packet-capture evidence

A packet capture was made on the Proxmox interface connected to the SHS VM:

tcpdump -ni tap110i0 -tttt -vvv -S \
'(arp and ether host mac-adress) or
(host 192.168.30.248 and (tcp port 5001 or icmp))'

During another attempt:

• The Netatmo transmitted ARP requests until 18:18:41.

• The first TCP SYN from SHS to 192.168.30.248:5001 occurred at 18:19:03.

• No SYN-ACK or RST was returned.

• Several SYN retransmissions followed.

• SHS subsequently sent ARP requests for the Netatmo, but received no answer.

Therefore no HomeKit Pair-Setup M1 request reached the station. The TCP connection was initiated only after the Netatmo had already left the network.

Network verification

When the station is paired with Apple Home, the exact same route from SHS works:

curl -v http://192.168.30.248:5001/

This connects successfully and returns:

HTTP/1.1 470 Connection Authorization Required

This confirms that routing, VLAN connectivity, firewall access and TCP port 5001 work while the station is online.

The station can also be paired successfully with Apple Home. It has now been returned to Apple Home after testing.

Additional observation: duplicate Pair-Setup

In the latest attempt, pairSetup was started twice, 106 ms apart:

14:31:08.974Z pairSetup
14:31:09.080Z pairSetup

This duplication did not occur during the two earlier attempts, which each contained one pairSetup. It is therefore probably not the primary cause, but may indicate a UI event or pairing-state race.

Suspected issue

HomeKit Controller appears to retain and present a stale mDNS entry after the accessory has disconnected. When the PIN is submitted, it tries to connect to the cached address without first confirming that the accessory is still reachable.

The subsequent socket error also appears to be handled incorrectly, because the app attempts to set errorCode on a null object. This hides the useful EHOSTUNREACH error behind a JavaScript exception.

Expected behaviour

Ideally, the app should:

1. React to mDNS serviceDown or expiry of the service record.

2. Refresh or validate the selected accessory before starting Pair-Setup.

3. Prevent two simultaneous pairSetup calls.

4. Report an actionable connection error instead of throwing:
   Cannot set properties of null.

Could you check the mDNS cache/service expiry, the timing of the TCP connection and the null error handling in _requestClear/pairSetup?

The complete HomeKit Controller log and packet-capture screenshots are available.

Regards, Paul

[smarthomesven]

@Paul_Rade

• Netatmo MAC address

I would recommend you to remove this from your post. It can in some cases be used for accessing the device or determining its location. It’s not needed to publish that online anyway, it’s a unique identifier for the Netatmo device

[Martin_Verbeek]

Thx for the thorough analysis. Will be checking it.

[Martin_Verbeek]

There will be a release of 3.0.0. in test fairly quick.

It will introduce beta BLE support in addition to Thread and IP.

The whole pairing process has been changed to custom pairing view to show a bit more information on the status of Homekit devices.

Also a lot of changes to support stability of connections in all transports.

Enjoy when it releases.