homebridge/to/get {"name": "*"} - output

[bakman2]

The output format of homebridge/to/get {"name": "*"} is a bit strange to parse.

Would this not make more sense to output :

[cflurin]

This is because an accessory can have more than one service. Sure, it could be simplified for accessories with only one service (probably 90% of them).

I'll put it on my todo list. I'd also accept a pull request.

[LaborEtArs]

I also stumbled across this, but may I'd like to have it even a bit more complicated... As an accessory may have several services, and every service may have several characteristics, wouldn't it make sense to copy this hierarchical structure to the JSON response also: name: "Light Hub", services: [ ..{ ....name: "Light 1", ....characteristics: [ ......{ On: true }, ......{ Brightness: 75}]} ..{ ....name: "Light 2", ....characteristics: [ ......{ On: false }, ......{ Brightness: 75}]}]

[cflurin]

@bakman2, @LaborEtArs

To get an idea which structure is suitable, could you please describe how you are using:

topic: homebridge/to/get
payload: {"name": "*"}

The original intention is to return an object for your doc/info.

[LaborEtArs]

@cflurin I'm thinking about ESP8266 clients, that could do a 'self-register' to homebridge(-mqtt). To do so, they should be able to find out, if they have been already registered, which would be possible by calling 'homebridge/to/get' and lookup the accessory/service name. Of course, this may be possible based on the current response, too. I developed a ESP-based HAP client (but had to find out, after it is running, that the ESP8266 is just a bit to slow for HAP communication...). Therefore I'm already in HAP a bit deeper... When registering a new accessory to homekit, the new HAP device has to send it's 'Accessory Attribute Database (AAD)' to homekit. This AAD is structured hierarchically, therefore I'm used to this format and think it would feel more 'native', if the mqtt plugin would deliver the same format. You can find the HAP spec here HAP spec R2, look at 6.6.4. If such a format (the hierarchical style) would be interesting to you, maybe I can deliver a PR :-)

[cflurin]

Hi @LaborEtArs

Thanks for your answer, sure I'd appreciate a PR.

First I'd like to read the HAP spec R2 but it seems to be broken, I can only read the first 50 pages.

[LaborEtArs]

Just downloaded the file; here it's OK. You may use google to lookup 'HAP-Specification-Non-Commercial-Version pdf'

[cflurin]

Download 👍 . I'll have a look later.

[cflurin]

Okay, to keep backwards compatibility I'd add a new topic

homebridge/to/get/hap

I don't think that we need all the properties as described in the HAP spec, just add what you need.

[bohtho]

Just to chime in, my 2p is that I am thinking along the same lines. I would like certain devices to easily check if their service and characteristic is already registered under the desired accessory. Also automatic removal when offline for a long period of time.

[roscoe81]

While looking at this issue, would it also be possible to output any optional characteristics that have been configured? That would be a valuable capability when using homebridge/to/get to verify the entire accessory/service configuration.

[cflurin]

@LaborEtArs and other users.

I'm working on other projects so I'll appreciate a PR for this feature.