Pair setup fails with HomeKit app

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi all,

I've got a custom board with the Auth chip, which is largely based on the eval board, with the auth chip connected correctly. I am able use WAC to configure the board with WiFi access. I've created one simple "outlet" accessory, with one accessory information service, and one outlet service and two characteristics (on and outlet-in-use). I am able to call wiced_homekit_start, and it returns the success code.

Now when I use either HAT or the demo app from Apple, I am able to see this accessory. A bonjour browser app also verifies that the _hap._tcp service is being advertised. I have also been able to run the identify routine, but this didn't work out of the box. I had to play with the timings of other initializations I was performing in my accessory, and it somehow started working.

At this point, I expect I should be able to pair with the device. However, I'm unable to do this either with the HMCatalog demo iOS app, or via HAT. I do get prompted to enter the code, and I'm using the wiced_configure_accessory_password_for_device_with_no_display() method.

With HAT, I get a the following message, which is the only  information I'm able to obtain to debug this problem:

Message: __46-[HAPAccessoryServerIP _pairSetupTryPassword:]_block_invoke ### Unable to send request to try password during Pair Setup, received response object: (null), MIME type: Unknown, error: Error Domain=HMErrorDomain Code=59 "Failed with OSStatus code 200500 (Internal Server Error)" UserInfo=0x60000086b240 {NSLocalizedDescription=Failed with OSStatus code 200500 (Internal Server Error)}

Otherwise, the whole HomeKit module is a black box. I'm using OS X with 3.1.2 for firmware development. Most of build and code downloading for HomeKit seems to work fine, I just use the make scripts on the command line (no IDE). I have USE_MFI=1. I assume GEDDAY is being used. When I try USE_BONJOUR=1 in addition, I think there are memory issues, because the application hangs, so I'm not using the Bonjour flag.

In SDK 3.1.1, I used to get some debug outputs during the WAC process. With 3.1.2, there are no debug outputs. I have no idea where to start debugging. Is there any WICED HomeKit documentation other than that is in the comments of the sample HomeKit app? Any help is greatly appreciated.

0 Likes
3 Replies
Anonymous
Not applicable

Hi,

I have seen this error before, though the problem went away once HAT was restarted, so I suspect the issue is on that side. Perhaps HAT gets itself into an invalid state. I have never seen this happen consistently or had a chance to capture any data the one time I saw it. How are you seeing this?

If it is frequently, can I ask if

1) You seeing this behavior with the accessory simulator also?

2) You have a packet capture trace, from a tool such as wireshark to see what communication is actually taking place. We just want to make sure tcp packets are indeed sent to the accessory.

Does this happen with the latest HAT release (HAT7, 1.0 (84) )?

Just a note that a HAT7 compliant release coming this month to the forum ( due to apple making some spec changes to the protocol ). Your current HomeKit library will still work with HAT7, but you will notice error notifications in responses.

Otherwise all of the steps you described to be taking are correct, including your assumption that Gedday is being used. In fact we will be pulling Bonjour from the build option in future releases as it consumes much more memory for no real gain.

Thanks,

Milan

0 Likes
Anonymous
Not applicable

Milan,

Thanks for the response. I think I was able to get past this issue. It has been a while, but I suspect it was after I switched to a newer version of HAT. I think HAT still has some issues where it seems to save some state and become inoperable even if I restart it. I've had to delete and re-install on occasion. I've filed a bug report with Apple for this issue.

I've not used the accessory simulator. I use the iOS sample app and HAT alternatively to see if the issue is with my accessory. So far, at least one works, the iOS app or HAT, so I've been fortunate.

The two key issues I face are:

1. The Auth Chip gets into a bad state and then refuses to authenticate/respond correctly. When this happens, even a complete power cycle followed by new firmware download doesn't always work. I suspect this may be due to the HAT saving state issue (I'm on the latest version of HAT-- beta 7), in addition to some issues with the Apple HAP firmware + WICED wrapper. It is impossible to narrow this down because no debug messages are available.

2. How does one turn on debug messages? As I've mentioned before, I used to get some WAC related messages in 3.1.1, which I can't seem to bring back in WICED 3.1.2. The only debug messages I've been able to get are from the Auth chip I2C write module, which is useful because it shows that the Auth chip rejects some pairing requests from time to time. However, I can't tell what exactly is causing the rejection.

Any pointers on debugging are greatly appreciated. There isn't a whole lot of HomeKit specific code I've had to write to get the basic outlet service up and running (including callbacks), but I can't get consistent behavior from the accessory.

Arvind

0 Likes
Anonymous
Not applicable

Hi Arvind,

Try adding these to the makefile snippet for more debug info when using auth chip.

GLOBAL_DEFINES += DEBUG=1

GLOBAL_DEFINES += WPRINT_ENABLE_LIB_DEBUG=1


This wont yield any debug prints for HomeKit specific issues though. They are best traced through the logs seen in HAT.


To eliminate the possibility of it being an auth chip issue, try pairing without mfi, and check how reliable that is. It will be prompted as an un-authenticated accessory, but you should still be able to pair reliably. Also just compile for debug mode, run in eclipses debug environment and keep an eye out for any asserts ( which map to breakpoints), which may get triggered if you run out of memory during pairing.


Apple just released HAT8, along with a spec update, so we are just integrating that now, and should release an updated HomeKit library in a week or two to this forum. Hopefully, that along with the new HAT8, will resolve the inconsistent behavior you are seeing.


In general, the problem you described seems to be state mismatch between HAT and the accessory (ie HAT thinks accessory is not paired, but accessory thinks it is paired ), which can happen if, for example a pairing is removed before being discovered (HAT doesnot send out remove pairing request in that case). In which case your best best is what you seem to doing already, which is reflash the eval board and restart HAT.


Thanks,

Milan

0 Likes