Centralized custom Service/Characteristic repository

[SphtKr]

An idea, not sure how best it fits.

When I wrote the homebridge-yamaha platform, I created a custom AudioDeviceService and two custom Characteristics AudioVolume and Muting. Obviously these have application outside of only the Yamaha AVR integration. I thought it would be valuable to consider somehow collecting generally applicable custom Characteristics and making them available on a similar footing as the Apple-standard ones included in HAP-NodeJS. Also in this category are the Eve power usage characteristics, which are apparently being used in the FHEM Homebridge plugin and I want to add them to the Z-Way plugin as well. It seems sensible to attempt to apply DRY and find somewhere to define these reusable characteristics in one place.

By collecting and promoting the use of shared, commonly used Characteristics, we could possibly even set de facto standards that app developers could incorporate--or I suppose even Apple (even if they wouldn't adopt the UUIDs, the taxonomies of custom Services and Characteristics could provide inspiration--I'd settle for being "Sherlocked").

Unsure how best to implement this, especially since I'm not sure what HomeKitTypes.js is generated from. A separate GitHub project/repo for this might well make sense, but some hooks would be needed at Hap-NodeJS or Homebridge. It seemed like HAP-NodeJS might be the better place to connect, but whichever is fine with me.

[PaulWieland]

+1 for this. @rodtoll check this out...

[snowdd1]

I like the idea. A separate repo (eg hapnodejs-customtypes) is a little strange, as plugins using these custom services/characteristics need to depend on the existence of the mod. I think if plugins have the repo in their dependencies npm will install it in a location so deep and away that a

try { require('hapnodejs-customtypes') } 

as a hook within hap-nodejs would always lead to nothing, even if it does not break with an exception. Said that, I haven't tried.

[SphtKr]

What the...Eve recognizes my custom Audio Volume characteristic all of a sudden!

So I guess app devs are willing to add support for custom services and Characteristics!

[KhaosT]

@SphtKr That's awesome :)

[snowdd1]

I am really flabbergasted. @SphtKr You made up the UUID and the name for that characteristic, right? How does EVE recognize it, even with an icon? Can you try with a misspelled "Audio Volume" to see whether Elgato (the maker of EVE) is reading here (and is using your UUID) or if the match of display name did the trick?

:astonished:

[SphtKr]

@snowdd1 I'll do one better. I went into the YamahaAVR plugin code and changed the custom characteristic's UUID by one digit. No icon (gets Eve's generic circle-in-square icon). Changed it back, speaker icon is back.

Now, I added that custom characteristic with that UUID back in September, so it's been there a while now. And it's just a percentage value, so very easy to implement. But the only possible conclusion is that Eve's developers have added support for that custom characteristic by its UUID since then.

Gentlemen, I think we have a mole. :open_mouth: Someone at Elgato must use the Yamaha plugin.

[justme-1968]

yes. we should do that. there are already two other issues and a gist where such data is collected:

https://github.com/KhaosT/HAP-NodeJS/issues/155 https://github.com/KhaosT/HAP-NodeJS/issues/140 https://gist.github.com/gomfunkel/b1a046d729757120907c

having everything in one place and easily includable would be great.

using the same uuid across different plugins would not only avoid that i have to change my volume characteristic to the one eve apparently recognizes :( and allows them grouping in homekit apps but also makes it easier to switch it apple decides to include new standard characteristics.

[KhaosT]

I currently maintains a metadata for all built-in HomeKit services and characteristics that has special properties, sample. Maybe we can build like a platform to allow people to search and submit new services and characteristics so it can be easier for app developers to integrate?

[justme-1968]

just changed my old custom volume characteristic to the one eve apparently recognizes and it really just works. very nice :)

we should try to get them to include more of these...

color temperature for lights would be one canditate.

[SphtKr]

Of note, here's some more use cases: https://github.com/SphtKr/homebridge-itunes/blob/master/HomeKitMediaTypes.js . I'll be building out the taxonomy for media device controls more and would welcome feedback/suggestions.

[inator]

Hello all -

I think this issue warrants reopening, as there's a ton of merit in setting up a way to share and use custom homekit types across apps. The simplest approach to me is via separate node module with various type categories as individual methods that can be loaded as required.

I'll work something up as a proof of concept and share here for comment/participation.

[ebaauw]

Just stumbled upon this issue. Any news on this? I would like to support it. I think HomeKit app developers would as well.

Here's the potentially re-usable custom characteristics I've come across:

• Color Temperature: the Philips Hue bridge uses a custom characteristic type E887EF67-509A-552D-A138-3DA215050F46 for color temperature lights. However, this type uses the value in Mired instead of in Kelvin. Eve actually converts this to Kelvin. Elgato support tell me that Nanoleaf uses A18E5901-CFA1-4D37-A10F-0071CEEEEEBD with value in Kelvin, which they will support from Eve v2.6. See https://github.com/ebaauw/homebridge-hue/issues/35;
• The Philips Hue bridge uses a custom characteristic type D8B76298-42E7-5FFD-B1D6-1782D9A1F936 which holds the uniqueid of a light. The Hue app uses this when syncing rooms between the Hue bridge and HomeKit, see https://github.com/ebaauw/homebridge-hue/issues/55;
• Sensors connected to the Hue bridge have an attribute lastupdated, which holds the date/time of the last change. I use a custom type to expose this to HomeKit.
• The light sensor in the Hue Motion sensors have configurable thresholds for dark and daylight, typically used in rules instead of the light level. I plan to use custom types to expose these.
• I plan to expose the CLIPGenericStatus sensors on the Hue bridge using a custom type for Status, just an integer number. I currently use ProgrammableSwitchOutputState, but that doesn't seem to work for iOS 10.3, see KhaosT/HAP-NodeJS#134;
• Similarly, I plan to expose the interval (in seconds) for polling the Hue bridge using a custom Heartrate characteristic instead of ProgrammableSwitchOutputState;
• Volume and Mute: are now standard HomeKit types. I'm using these for my homebridge plugin for Sonos. I'm also using custom characteristics for Current Track, Treble, Bass, Loudness, Balance (not yet implemented). I'm still trying to figure out the best way to do input selection - the homebridge-itunes types look promising.

Related to this:

• How best to pick a UUID for a custom characteristic?
• What about custom services? I used these some years ago, but today most HomeKit apps seem to hide/ignore them, even when they contain standard characteristics. Semantically it makes sense to model the Sonos services to the UPnP services, similarly to homekit-itunes. Practically this is kinda useless, if no app is supports this.

[SphtKr]

Hi folks. FWIW, I had started to build this but just had to spend time on other projects. And, I never watched my own repo 🤦‍♂️ , so didn't realize there are already five forks of it. Not sure if one of those have taken off and run with it. But you might use what I had as a model or as a lesson. Anyone want to own the repo I'll transfer it too, I've just not had the time to keep it up.

[NorthernMan54]

@SphtKr I looked at your work a few months back and found that the @homespun fork to be the most updated.

[mrose17]

@NorthernMan54 - if not, please let me know.... thanks!

[ToddGreenfield]

Has anyone figured out a way to do a custom type for Audio Input (CD, NET, etc)?