homebridge/to/get {"name": "*"} - output
See original GitHub issueThe output format of homebridge/to/get {"name": "*"}
is a bit strange to parse.
Would this not make more sense to output :
Issue Analytics
- State:
- Created 4 years ago
- Comments:11 (7 by maintainers)
Top Results From Across the Web
Only one of my TVs shows up in CC remote #121 - GitHub
+1. I have 3 WebOS TV's (all different models) and only one of them appears in the control centre remote. All appear in...
Read more >homebridge-daikin-oneplus - npm
To get an integration token: Open the Daikin One Home app; Go to account settings on the Location/root/top screen of the app. ·...
Read more >Simple settimeout function - General - Node-RED Forum
I´m getting the state of my door sensor from Homebridge (ContactSensorState) and want to return a payload "true" msg if the state stays...
Read more >[RELEASE] HubConnect - Share Devices across Multiple ...
Can you get me all of the output from Homebridge when it starts up? ... I seem to have to still reboot homebridge...
Read more >c# 4.0 - How to change the output name of an executable built ...
Open the Project Properties in Visual Studio (right click on project in Solution Explorer and select "Properties" from popup menu) ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@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 😃
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}]}]