multiple services on a single accessory

[richardklose]

As far as i can see, it is currently not possible to add an accessory with multiple service. I think this should be possible, at least HAP-NodeJS supports this, and so i think homebridge will also do. But when an accessory is added through homebridge-mqtt, i see no way to do this.

topic: homebridge/to/add
payload: {"name":"office_lamp","service":"Switch"}

I would suggest something like this (if possible):

topic: homebridge/to/add
payload: {"name":"office_lamp","services":{"myfirstservice":"Switch","mysecondservice":"Switch"}}

[cflurin]

Correct, homebridge-mqtt supports only one service. Have you got any practical examples of accessories that need several services?

[danielsen2009]

I was wondering this as well. I'm building an all in one environmental sensor + presence . And wall switches with multiple buttons, adding them all as separate devices works but quickly clutters up the home app. It would be nice to consolidate them into one accessory with all of its services.

[cflurin]

I tried adding one accessory with 2 Switch services using HomeKit Accessory Simulator. I don't see any benefits, there is one accessory in my case hk_switch with 2 names (Switch-1 and Switch-2) but you still need two buttons.

Okay you can assign the room name to the accessory once but this isn't really amazing.

[richardklose]

In my case i have a lamp with two lightbulbs. I agree that there is no visible benefit in the iOS Home App. It's more an how-to-organize thing, from a logical point of view. Another more valid example might be the battery service. If i have a physical device, e.g. a battery powered smoke detector, i would have to define two different accessories with also different names. If the device runs out of battery iOS would notify me with a different name than the real device has, because for iOS this would be two complete separate accessories. This seems to be more a design problem, but makes it more complicated to configure if you have many accessories you want to configure.

[cflurin]

@richardklose: thanks for your feedback. I'll have a look at the code, probably it'll not be easy to add multiple services, let's see.

For now you can define the name of your lamp this way:

{"name": "lamp.bulb1", "service": "Switch"}
{"name": "lamp.bulb2", "service": "Switch"}

[Stelian]

@cflurin another use case would be something like a DHT22 sensor, and I would like to set both humidity and temperature for one accessory.

[rmhomecouk]

I would love this functionality - One example (in my case) is a custom wireless sensor providing temperature and humidity. As it's battery operated it also provides the voltage level and also if the battery is low. I have created a custom plugin that provides all this in one accessory but I'd love to use this platform as a replacement.

cheers and good job!

[danielsen2009]

I have one esp running multiple services, it would be great to have this so I could set the availability for all of the "accessories" with one last will of mqtt.

[cflurin]

I'm working on the homebridge-mqtt API, it has to be compatible with the actual version. I hope to be able to upload a new version with the multiple services feature soon.

[cflurin]

@all: I've just uploaded version 0.3.0.

Please install from GitHub:

sudo npm install -g cflurin/homebridge-mqtt

Doc: https://github.com/cflurin/homebridge-mqtt#multliple-services

[danielsen2009]

Thank you! Cant wait to update my devices with this. You can see a little of what I'm doing here.

[zieherf]

@cflurin thanks for adding the multi - service capability for accessories. I find the choice of "subtype" a bit odd since it is just the service name of the service added. Would an attribute such as "service_name" (or "servicename") be more descriptive. Just a thought.

[cflurin]

@zieherf: subtype has been defined in:

https://github.com/KhaosT/HAP-NodeJS/blob/master/lib/Service.js

which is generated from the HomeKit Accessory Simulator. Like name, service, characteristic, so I used this definition.

But yes I don't like subtype neither. What about subname instead of subtype?

(I already used service_name for "Switch", TemperatureSensor" etc. also for the name of the service.)

[zieherf]

Looking at the Apple HomeKit developer SDK documentation, the concept of subtype does not exist and when looking into Service.js from HAP-NodeJS, then I think "subtype" just covers a special case of multiple services within an Accessory. Services with the same type, e.g. "Lightbulb" and with the same UUID, thus differentiated by the service_name (aka "subtype"). I would rather skip this (in my understanding) special case and just have services added to the accessory that have by itself a different UUID, the primary service is the one that is created when creating the accessory

homebridge/to/add {"name":"accessory_name", "service": "Lightbulb"}

In this case, the service name defaults to the accessory_name (backwards compatible). In case that also a name for the service is given,

homebridge/to/add {"name":"accessory_name", "service_name": "service_name", "service": "Lightbulb"}

the primary service name can be different from the accessory name (more consistent when adding multiple services).

Multiple services would be added as you described, but not with the concept of subtype. homebridge/to/add/service {"name":"accessory_name", "service_name": "service_name", "service": "Lightbulb"}

A typical weather station accessory could then host 3 services

• TemperatureSensor
• HumiditySensor
• AirQualitySensor

homebridge/to/add {"name":"My_weather_station", "service_name":"Temperature", "service":"TemperatureSensor"}
homebridge/to/add/service {"name":"My_weather_station", "service_name":"Humidity", "service":"HumiditySensor"}
homebridge/to/add/service {"name":"My_weather_station", "service_name":"AirQuality", "service":"AirQualitySensor"}

Does this make sense? BTW: I use homebridge-mqtt for all my esp8266-based accessories.

[cflurin]

@zieherf: thanks for your feedback.

I agree service_name is more appropriate for the user API.

Services with the same type, e.g. "Lightbulb" and with the same UUID, thus differentiated by the service_name (aka "subtype"). I would rather skip this (in my understanding) special case ...

I don't think so, this use case makes sense, e.g. accessories with multiple Switch or Outlet Services, take a look at the first post (@richardklose).

Please install again from GitHub:

sudo npm install -g cflurin/homebridge-mqtt

[zieherf]

@cflurin thanks for updating the naming convention. I didn't test the new version yet - will do that later. Are all the other mqtt topics adapted as well, such as homebridge/to/get {"name":"*"} to return accessories with multiple services (I haven't seen that referenced in the documentation yet).

Something I noticed when looking through accessory.js: line 239 in lib/accessory.js:Accessory.prototype.set has a typeof missing, should read if ( typeof this.service_names[iid] === "undefined") { instead of if (this.service_names[iid] === "undefined") {

[danielsen2009]

Updated this morning, everything seems to be working fine. I really like the new naming convention, makes a little more sense.

[cflurin]

@zieherf: thanks for your reporting. 'typeof' fixed -> new commit homebridge/to/get {"name":"*"} should work.

@danielsen2009: thanks for your feedback.