Pairing Issue "Hue Bridge"

[Apollon77]

AFter trying another library I found yours where I like the interfaces and feature more ... So I unpaired the other one and trying to pair with your lib

Found device! {
  name: 'Philips hue - 84B26C',
  address: '192.168.178.146',
  port: 8080,
  'c#': 12,
  ff: 2,
  id: 'AD:62:54:73:8C:72',
  md: 'BSB002',
  pv: '1.1',
  's#': 24,
  sf: 1,
  ci: 2
}
(node:93521) UnhandledPromiseRejectionWarning: Error: M2: Error: 1
    at PairingProtocol.parsePairSetupM2 (/Volumes/Dev/hapclient2/node_modules/hap-controller/lib/protocol/pairing-protocol.js:173:19)
    at HttpClient.startPairing (/Volumes/Dev/hapclient2/node_modules/hap-controller/lib/transport/ip/http-client.js:64:37)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async IPDiscovery.<anonymous> (/Volumes/Dev/hapclient2/node_modules/hap-controller/pair-setup-promps.js:19:16)
(node:93521) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:93521) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

With the other lib I can still do pairing! (https://github.com/Apollon77/hap-client)

[Apollon77]

If I do the pairing process with the other lib and then transfer the data over in your structure I can use getaccessories and other calls without any issue!

[Apollon77]

BTW: If I try a "pair" call again with your lib after being paired with the other I get this response

(node:94390) UnhandledPromiseRejectionWarning: Error: M2: Error: 6
    at PairingProtocol.parsePairSetupM2 (/Volumes/Dev/hapclient2/node_modules/hap-controller/lib/protocol/pairing-protocol.js:173:19)
    at HttpClient.startPairing (/Volumes/Dev/hapclient2/node_modules/hap-controller/lib/transport/ip/http-client.js:64:37)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async IPDiscovery.<anonymous> (/Volumes/Dev/hapclient2/node_modules/hap-controller/pair-setup-promps.js:19:16)

In fact an error is expected because only one bridge can be paired a a time (the other lib returns an "http like 429 error")

[Apollon77]

PPS: Ok the error 6 according to the one table is correct for an "already paired" device ... so only the Error 1 (aka Unknown) is meehhh

[Apollon77]

PPPS: If you like I can also paste some debug log from the other library what they send out in pairing Step 1 because for me it seems that the Hue do not like what your lib send :-)

[mrstegeman]

Unfortunately, it's very hard to debug these issues, since the device-side is a black box.

[Apollon77]

In fact I have both libs and the device here ... tell me what I should do ... I can try to get some debug inside your lib and we at least could compare the messages that are send on a "buffer" basis? Would this be an idea?

[Apollon77]

Ok I added some debug ... and there seems to be a differnce if I'm not stupid ...

Other lib:

  hap-client:tlv turning 0 into buffer +0ms
  hap-client:tlv adding 1 bytes of type 0 to the buffer starting at 0 +0ms
  hap-client:tlv turning 1 into buffer +1ms
  hap-client:tlv adding 1 bytes of type 6 to the buffer starting at 0 +0ms
  hap-client:hap encoded request: <Buffer 00 01 00 06 01 01> +1ms
  hap-client:http POSTing to /pair-setup: <Buffer 00 01 00 06 01 01> +0ms

Your lib sends out: POST /pair-setup ,body 060101000101

YOur message is in any case different

[Apollon77]

If I swap these two lines https://github.com/mrstegeman/hap-controller-node/blob/b517c497dab5dfe288d6f9510e78cbd2ccbb1d49/src/protocol/pairing-protocol.ts#L224-L225 then we come a bit more near ... but still incorrect :-)

POST /pair-setup ,body 000101060101

Byte3 still incorrect

[mrstegeman]

The data is in TLV format, so the ordering shouldn't matter. The biggest difference here is that one is using Methods.PairSetup, while the other is using Methods.PairSetupWithAuth.

[Apollon77]

But interestingly the Hue bridge likes the ony and the other not :-)

I adjusted the code and now it works!

[Apollon77]

So I just remove the "WithAUth" in https://github.com/mrstegeman/hap-controller-node/blob/b517c497dab5dfe288d6f9510e78cbd2ccbb1d49/src/protocol/pairing-protocol.ts#L225 ...

Maybe allow to make that configurable?

Whats the difference ... ? (I also will read the specs after dinner) :-)

[mrstegeman]

Originally, authentication was always done as part of the pairing procedure. There's now a way to do it separately, where you'd use PairSetup instead, but the separate pairing procedure isn't documented in the community spec, as far as I can tell.

[Apollon77]

In fact PairSetup just worked with your lib fine ... :-)) He finished pairing and I got the accessories , so from my perspective it should be new standard (or configurable) ... or with extra method (whatever you like more) :-)

But then my issues are solved

[mrstegeman]

Would you want to open a PR?

[mrstegeman]

Probably just make it configurable, that makes the most sense.

[Apollon77]

Sure I can do a PR ...

[Apollon77]

PS: I only might need TypeScript support for the types and such .. lets see how far I come

[Apollon77]

DoI you think that "WithoutAuth" pocess also works for BLE? SOsdame there? I have no BLE devic to test it

[mrstegeman]

Yes, the pair procedure works the same across both protocols.

[Apollon77]

@mrstegeman The community HAP spec I have just downloaded some days go includes infgo on that other method.

[mrstegeman]

Right, mine does as well, but it doesn't detail the "separate optional authentication procedure" at all, or what the other states of the pair setup procedure should look like if authentication is not occurring.

[Apollon77]

Also here with the other lib the flags are not sent at all ... but it works ... interesting interesting

[Apollon77]

@mrstegeman happy reviewing :-)