Pairing failed - Host Unreachable

[sargonphin]

Describe the bug
Upon attempting to pair a Netatmo Air Quality Sensor to the adapter using IP, a "Host Unreachable" error appears and the device fails to pair (despite being, for sure, in pairing mode)

To Reproduce

• Pair the Netatmo Air Quality Sensor to Apple HomeKit on an iPhone/iPad to add it to local network
• • The Sensor appears as reachable but already paired on iobroker
• Put the sensor in pairing mode by long-pressing the top until the light blinks white (pairing mode)
• • The sensor now appears as reachable and ready to pair
• Input PIN number with the dashes
• (Almost) immediately fails and throws the following error:

Cannot pair with device IP-8C:D7:F4:CF:8A:81 because of error undefined (undefined): connect EHOSTUNREACH 192.168.200.244:5001

Expected behavior
Pairing is successful

Screenshots & Logfiles

Adapter	Timestamp	Loglevel	Message
homekit-controller.0	2022-11-10 23:27:42.979	info	Cannot pair with device IP-8C:D7:F4:CF:8A:81 because of error undefined (undefined): connect EHOSTUNREACH 192.168.200.244:5001
homekit-controller.0	2022-11-10 23:27:39.915	debug	IP-8C:D7:F4:CF:8A:81 Start Homekit Device Client initialization on 192.168.200.244:5001
homekit-controller.0	2022-11-10 23:27:39.914	info	Use PairMethod 1 to pair IP-8C:D7:F4:CF:8A:81
homekit-controller.0	2022-11-10 23:27:39.913	debug	state homekit-controller.0.IP-8C:D7:F4:CF:8A:81.admin.pairWithPin changed: xxx-xx-xxx (ack = false)

I don't know if 8C:D7:F4:CF:8A:81 was supposed to be a MAC address but this address is actually wrong for the device I have connected here

Versions:

• Adapter version: v0.5.1
• JS-Controller version: v4.0.23
• Node version: 16.17.1
• Operating system: RaspberryOS

Additional context
PiHole was disabled this time btw :)

[sargonphin]

Also shouldn't this be a "error" instead of "info" in terms of logs?

[Apollon77]

Please provide a full debug log with additional logging as described in the readme troubleshooting section of this project and post to me.

EHOSTUNREACH means that the device is not in WLAN and so the IP is network wise not reachable.

The 8C:D7:F4:CF:8A:81 is the "ID" of the device and not a maxc address

[sargonphin]

I apologize I thought enabling Debug on the instance would be enough!

Here is the output of the logging:

root@superberry:~# DEBUG=hap* node /opt/iobroker/node_modules/iobroker.homekit-controller/build/main.js 0 --debug --logs
2022-11-11 16:37:31.524  - debug: homekit-controller.0 (2066873) Redis Objects: Use Redis connection: 0.0.0.0:9001
2022-11-11 16:37:31.665  - debug: homekit-controller.0 (2066873) Objects client ready ... initialize now
2022-11-11 16:37:31.674  - debug: homekit-controller.0 (2066873) Objects create System PubSub Client
2022-11-11 16:37:31.678  - debug: homekit-controller.0 (2066873) Objects create User PubSub Client
2022-11-11 16:37:31.747  - debug: homekit-controller.0 (2066873) Objects client initialize lua scripts
2022-11-11 16:37:31.756  - debug: homekit-controller.0 (2066873) Objects connected to redis: 0.0.0.0:9001
2022-11-11 16:37:31.786  - debug: homekit-controller.0 (2066873) Redis States: Use Redis connection: 0.0.0.0:9000
2022-11-11 16:37:31.805  - debug: homekit-controller.0 (2066873) States create System PubSub Client
2022-11-11 16:37:31.807  - debug: homekit-controller.0 (2066873) States create User PubSub Client
2022-11-11 16:37:31.878  - debug: homekit-controller.0 (2066873) States connected to redis: 0.0.0.0:9000
2022-11-11 16:37:31.992  - debug: homekit-controller.0 (2066873) Plugin sentry Initialize Plugin (enabled=true)
2022-11-11 16:37:32.002  - info: homekit-controller.0 (2066873) Plugin sentry Sentry Plugin disabled for this process because sending of statistic data is disabled for the system
2022-11-11 16:37:32.235  - info: homekit-controller.0 (2066873) starting. Version 0.5.1 in /opt/iobroker/node_modules/iobroker.homekit-controller, node: v16.18.1, js-controller: 4.0.23
2022-11-11 16:37:32.315  - debug: homekit-controller.0 (2066873) Init 1 known devices without discovery ...
2022-11-11 16:37:32.317  - debug: homekit-controller.0 (2066873) Init IP-8C:D7:F4:CF:8A:81 as known device
2022-11-11 16:37:32.321  - info: homekit-controller.0 (2066873) IP-8C:D7:F4:CF:8A:81 (Healthy Home Coach) found without pairing data but available for pairing: Create basic objects
2022-11-11 16:37:32.323  - debug: homekit-controller.0 (2066873) Service: {"name":"Healthy Home Coach","address":"192.168.200.244","port":5001,"c#":4,"ff":1,"id":"8C:D7:F4:CF:8A:81","md":"Healthy Home Coach\u0000","pv":"1.1","s#":1,"sf":1,"ci":10,"availableToPair":true}
2022-11-11 16:37:35.410  - debug: homekit-controller.0 (2066873) Message getDiscoveredDevices received: {"command":"getDiscoveredDevices","message":null,"from":"system.adapter.admin.0","callback":{"message":null,"id":31,"ack":false,"time":1668181055407},"_id":38575933})
2022-11-11 16:37:35.412  - debug: homekit-controller.0 (2066873) Response to Command getDiscoveredDevices: {"success":true,"error":false,"devices":[{"id":"IP-8C:D7:F4:CF:8A:81","serviceType":"IP","connected":false,"discovered":true,"availableToPair":true,"discoveredName":"Healthy Home Coach","discoveredCategory":"Sensor","pairedWithThisInstance":false}]}
2022-11-11 16:37:36.717  - debug: homekit-controller.0 (2066873) Message getDiscoveredDevices received: {"command":"getDiscoveredDevices","message":null,"from":"system.adapter.admin.0","callback":{"message":null,"id":32,"ack":false,"time":1668181056714},"_id":38575934})
2022-11-11 16:37:36.719  - debug: homekit-controller.0 (2066873) Response to Command getDiscoveredDevices: {"success":true,"error":false,"devices":[{"id":"IP-8C:D7:F4:CF:8A:81","serviceType":"IP","connected":false,"discovered":true,"availableToPair":true,"discoveredName":"Healthy Home Coach","discoveredCategory":"Sensor","pairedWithThisInstance":false}]}
2022-11-11 16:38:01.361  - debug: homekit-controller.0 (2066873) Message pairDevice received: {"command":"pairDevice","message":{"deviceId":"IP-8C:D7:F4:CF:8A:81","pin":"XXX-XX-XXX"},"from":"system.adapter.admin.0","callback":{"message":{"deviceId":"IP-8C:D7:F4:CF:8A:81","pin":"XXX-XX-XXX"},"id":33,"ack":false,"time":1668181081358},"_id":38575935})
2022-11-11 16:38:01.364  - info: homekit-controller.0 (2066873) Use PairMethod 1 to pair IP-8C:D7:F4:CF:8A:81
2022-11-11 16:38:01.365  - debug: homekit-controller.0 (2066873) IP-8C:D7:F4:CF:8A:81 Start Homekit Device Client initialization on 192.168.200.244:5001
  hap-controller:tlv Add 1 bytes for tag 6: 01 +0ms
  hap-controller:tlv Add 1 bytes for tag 0: 01 +2ms
  hap-controller:http-connection 192.168.200.244:5001 POST /pair-setup 060101000101 (application/pairing+tlv8) +0ms
2022-11-11 16:38:19.837  - debug: homekit-controller.0 (2066873) Response to Command pairDevice: {"success":false,"error":"Cannot pair with device IP-8C:D7:F4:CF:8A:81 because of error undefined (undefined): connect EHOSTUNREACH 192.168.200.244:5001"}

[sargonphin]

BTW: yes the device is inside the WLAN since it successfully gets discovered and is actively connected to the router ^_^

[Apollon77]

Is the IP 192.168.200.244 correct?

Can you ping the IP if you open a shell on thie host?

As you can clearly see the device seems to act very strange becaus eif nodejs tells "EHOSTUNREACH 192.168.200.244" then it can not reach the host network wise to communicate with ... Yes you are right that it was discovered via MDNS before and this is also what I do not understand.

[sargonphin]

Okay so upon searching a little bit more, I ended up finding out that the sensor doesn't respond to ARP. I added a static entry in the Raspberry and got a different error "pairing method unavailable". I didn't get the full logs because I was searching for a way t o connect to the RPi, but ever since, the adapter doesn't see the sensor when it's set to pairing mode at all. I will try to figure sometihng out and I will get back to you whenever I find something

[sargonphin]

I am no longer able to see the sensor anymore in pairing mode. I'm clueless at to what's happening there, I tried to reset the sensor to factory defaults, remove the static entry in the ARP table, use a static DHCP lease, diagnosed the connection with Wireshark... the sensor suddenly drops the connection and stops responding entirely whenever it's in pairing mode now. It wasn't doing this before

[sargonphin]

Okay WOW i managed to FINALLY pair it...... but the process isn't really straightforward. Here are the steps I did to pair it to the adapter:

• Factory reset the sensor. Ideally, static DHCP lease makes the second step easier
• A static ARP entry must be defined in the system
• Sensor immediately goes into pairing mode but is not linked to any network. You must use an Apple device to start the pairing.
• When you start the pairing on iPhone, it immediately prompts if you want to share the WLAN settings to the device. You need to press "Allow" but DO NOT INPUT THE PIN
• The adapter will see the sensor as available for pairing but if you try it won't work, saying that "device is busy"
• Close the pairing process on the iPhone and wait & reload the adapter
• Try to pair with the sensor

This worked in my case but it may give very different results since I don't know what worked between restarting the adapter or waiting before the pairing process with the adapter

[Apollon77]

Wow ... thanks to NetAtmo for such a great user experience ;-) it is the first time I hear something like this honestly and all stuff I saw so far worked more simple. I will add this info to the Readme

[sargonphin]

It's a shame cause it means you must have an iPhone to do the pairing... but then, even if the pairing was working correctly, you'd have to use an iPhone to allow the WLAN settings to pass to the sensor :/