iOS 13

[netRunner0]

Please make an option to group, ungroup sensors, since in ios 13 they are grouped by default.

[netRunner0]

And this is how it is displayed through another plugin (as separate services):

[ebaauw]

I used an old iPhone 5S for testing iOS betas, but 13 no longer supports the 5S. We’ll have to wait until iOS 13 will be released, before I can have a look.

From what I understand, Apple’s Home app combines multiple services of the same accessory into a single tile. There’s nothing any plugin can do about that, you should ask Apple.

While technically, I could provide an option to expose a multi-sensor as separate accessories, there will be consequences:

• You’ll hit the limit of 150 accessories per HomeKit bridge sooner;
• Eve Weather history will no longer work.

[netRunner0]

Moreover, in beta2 it was displayed in one tile, but the temperature and humidity were visible. I do not know what to do, can you just wait?

A long time ago in the homekit they increased the limit to 150 devices per hub?

[b2un0]

i use ios 13 beta too so i can confirm that already some sensors grouped like hue motion sensor - but not 100%.

look here, this is the same motion sensor.

note: i use deCONZ for alle my zigbee devices.

[tomky]

I think an option to expose a multi-sensor or switch as separate accessories would be great. By default this could be off.

But I am curious why we will lose Eve history when it is on ? We may still keep those with history bounded with their corresponding Eve history? ( as it makes no sense to have them separate )

[ebaauw]

Eve is very picky on what the accessory should look like for history. It combines the temperature, humidity, and air pressure into one history service. It won’t display history for just air pressure or humidity. That’s why I introduced the forceEveWeather setting.

@b2un0 I think you have set hueMotionTemperatureHistory? With that setting homebridge-hue exposes the temperature sensor as a separate accessory (because Eve doesn’t support a combined history for motion and temperature). HomeKit doesn’t know that the two accessories are the device. You can even place them in different rooms.

[tomky]

Eve is very picky on what the accessory should look like for history. It combines the temperature, humidity, and air pressure into one history service. It won’t display history for just air pressure or humidity. That’s why I introduced the forceEveWeather setting.

@b2un0 I think you have set hueMotionTemperatureHistory? With that setting homebridge-hue exposes the temperature sensor as a separate accessory (because Eve doesn’t support a combined history for motion and temperature). HomeKit doesn’t know that the two accessories are the device. You can even place them in different rooms. It seems to me that this means it is still possible to provide separate accessory option while preserving Eve history by properly assigning the history to the correct exposed accessories?

For me, this greatly increases my interests in this function as I'm using the Aqara Double Key Wall Switch QBKG03LM as my main entrance switch, which controls the light of the living room and kitchen. In the current setup, I cannot assign those two lights to different rooms as they are controlled by the same device. This causes some troubles in my homekit setup.

[ebaauw]

@tomky, Is this a wall switch that controls dumb lights wired to the switch? Yeah, that's exposed as a single accessory with two Lightbulb services. Interesting use case. Technically I could just as easily expose it as two accessories, each with a single Lightbulb service.

The challege is: how to indicate this. I don't want per-device settings in config.json - that'll only lead to more issues by end users who don't understand JSON. I'll probably (ab)use another type of resourcelink to indicate which (/sensors and /lights) resources should be exposed as a standalone accessory.

[tomky]

I agree that per-device configuration would be confusing to beginners. A setting to specify which types of resources should be exposed as standalone accessories would be a good starting point.

[00lex]

actual there I just the solution to put this Multisensors into the status to split them:

@ebaauw you can give meanwhile pubbeta6 a try on your main device. no dramatic bugs.

[tomky]

Today I got iPhone 11 with iOS 13. Confirmed that the accessory merge is really bothering. This is especially troublesome for the Xiaomi two-button switch which now I need to tap twice to close a lamp. So I think the individual accessory per lamp/switch would be very helpful if you can provide such a function.

[ebaauw]

Please familiarise yourselves with HomeKit, in particular the difference between accessories and services, see https://github.com/ebaauw/homebridge-hue#caveats. Note that Apple's Home app uses these terms incorrectly, often referring to services as accessories. Siri deals with services; as do HomeKit groups, scenes, and automations. HomeKit rooms deal with accessories.

homebridge-hue exposes a ZigBee device as a single HomeKit accessory, combining the REST API resources for the device. Typically it exposes a service per REST API resource. This is the standard way to expose physical devices with multiple functions (virtual devices) to HomeKit, also used by the gen2 Hue bridge.

Up to iOS 12, Apple's home app used to display a tile per service (except for Stateless Programmable Switches). As of iOS 13, it displays a tile per accessory, combining the services. While it might look the same, this is unrelated to grouping of services (into HomeKit groups).
If you don't like this new behaviour, please complain to Apple, or simply use another HomeKit app.

While it's technically possible to expose a single device as multiple accessories (I do this for the Hue motion sensor when hueMotionTemperatureHistory is set, to display Eve history for both motion and temperature), this is usually a bad idea. HomeKit only supports 149 accessories per bridge (i.c. homebridge instance). Using multiple accessories per device will hit that limit earlier. Eve is very strict in what an accessory should look like to display history. Splitting a temperature/humidity sensor into multiple accessories would break the humidity history.

So homebridge-hue would need to provide a mechanism to specify per REST API resource whether to expose it as a separate accessory. As this is too complex for config.json, this would be specified through another resourcelink, requiring manual interaction with the REST API to create and maintain the resourcelink on the Hue bridge or deCONZ gateway.

[tomky]

I understand your concern but I have different reasons for accessory separation specifically for Aqara Double Key Wall switch QBKG03LM, as I want to assign each switch (dumb light) to different rooms. This is not related to Home in iOS 13 but an existing limitation in HomeKit.

https://github.com/ebaauw/homebridge-hue/issues/493#issuecomment-519131227

Nevertheless, given that this is unrelated to iOS 13, how about I start a new issue to specify the reason and use case of accessory separation for double key switch?

[ebaauw]

I appreciate your use case, @tomky, no need to open a new issue. I’ll see what I can do.

[ebaauw]

Looks Home on iOS 13.2 will offer an option to show an accessory as one or as multiple tiles, see https://www.macrumors.com/2019/10/02/whats-new-in-ios-13-2-beta-1/.

[ebaauw]

@tomky, I added support for a splitlight resourcelink to indicate which /lights resources should be exposed as a separate accessory.

{
  "classid": 1,
  "description": "splitlight",
  "links": [
    "/lights/282"
  ],
  "name": "homebridge-hue",
  "owner": "3635D7B19D",
  "recycle": false,
  "type": "Link"
}

Note that the listed resources will be exposed as an accessory where the serial number is mac address followed by the endpoint, rather than just the mac address. If you run homebridge -D you should see this in the logfile:

[10/5/2019, 11:25:00 AM] [Hue] pi2: /resourcelinks/5: 1 splitlight entries
...
[10/5/2019, 11:25:00 AM] [Hue] pi2: 00124B00130A5FED: GLEDOPTO GLEDOPTO "Balcony 1"
[10/5/2019, 11:25:00 AM] [Hue] pi2: /lights/281: Dimmable light "Balcony 1"
[10/5/2019, 11:25:00 AM] [Hue] pi2: /lights/281: set model to RGBW
[10/5/2019, 11:25:00 AM] [Hue] pi2: /lights/281: config: {"on":true,"bri":true,"ct":false,"xy":false,"waitTimeUpdate":20,"unknown":false}
[10/5/2019, 11:25:00 AM] [Hue] pi2: 00124B00130A5FED-0B: GLEDOPTO GLEDOPTO "Balcony 2"
[10/5/2019, 11:25:00 AM] [Hue] pi2: /lights/282: Extended color light "Balcony 2"
[10/5/2019, 11:25:00 AM] [Hue] pi2: /lights/282: set model to RGB+CCT
[10/5/2019, 11:25:00 AM] [Hue] pi2: /lights/282: config: {"on":true,"bri":true,"ct":true,"xy":true,"waitTimeUpdate":20,"minCT":153,"maxCT":500,"gamut":{"r":[0.7006,0.2993],"g":[0.1387,0.8148],"b":[0.151,0.0227]},"unknown":false}

For reference, without the splitlight resourcelink:

[10/5/2019, 11:31:24 AM] [Hue] pi2: 00124B00130A5FED: GLEDOPTO GLEDOPTO "Balcony 2"
[10/5/2019, 11:31:24 AM] [Hue] pi2: /lights/282: Extended color light "Balcony 2"
[10/5/2019, 11:31:24 AM] [Hue] pi2: /lights/282: set model to RGBW
[10/5/2019, 11:31:24 AM] [Hue] pi2: /lights/282: config: {"on":true,"bri":true,"ct":false,"xy":true,"waitTimeUpdate":20,"minCT":153,"maxCT":500,"gamut":{"r":[0.7006,0.2993],"g":[0.1387,0.8148],"b":[0.151,0.0227]},"unknown":false}
[10/5/2019, 11:31:24 AM] [Hue] pi2: /lights/281: Dimmable light "Balcony 1"
[10/5/2019, 11:31:24 AM] [Hue] pi2: /lights/281: set model to RGBW
[10/5/2019, 11:31:24 AM] [Hue] pi2: /lights/281: config: {"on":true,"bri":true,"ct":false,"xy":false,"waitTimeUpdate":20,"unknown":false}

[tomky]

Tested and confirmed it works perfectly for me.

[ebaauw]

Cool. I'll include it in the next release, to be published shortly after deCONZ v2.05.70.