Support fine-grained configuration

[ebaauw]

Currently, homebridge-hue support a few, coarse-grained parameters in config.json, basically enabling or disabling a resource type (i.e. lights, groups, sensors, schedules).
Would there be any interest in being able to specify this more fine-grained, e.g. per sensor type (only Hue Motion Sensors), per group type (e.g. only Luminaires), per light model (only Color Temperature Lights)? Would that indeed be per type or would you rather specify a list of IDs?

We might also need a way to store different usernames per bridge. I was thinking something like:

"platforms": [
  {
    "platform": "Hue",
    "name": "Hue",
    "bridges": [
      {
        "host": "192.168.1.10",
        "username": "S1QXtWWVemUMAy30Yz6iCDaucPvr84z8ztV0ru70"
      },
      {
        "bridgeid": "001788FFFE2C23BF",
        "username": "84z8ztV0S1QXtWWVemUMAy30Yz6iCDaucPvrru70"
      }
    ],
    ...
  }
}

The second entry would be the password for a discovered bridge. Would we want heartrate and timeout per bridge or globally?

[ebaauw]

Did a simpler setup for usernames, see README. Also made a distinction between lights and alllights.

[lnlyssg]

Following on from the issue I had due to geofences I think I'd definitely like more control over which sensors get added. Unfortunately I now have way too many sensors that are of little value to me in HomeKit e.g, 12 Hue Labs ClipGenericStatus sensors and 6 "iPhone" geofence occupancy sensors.

[ebaauw]

Hi Jim, @jaytay79

I did have a quick look at the Hue app routines. Indeed, it seems to be creating way too many sensors without any cleanup. I haven't looked at Hue Labs. Not sure if homebridge-hue should provide a workaround for some-one else's mess, but OK.

Would you want to mark individual sensors (e.g. only the CLIPGenericStatus sensors created by HueLabs) rather than sensor types (e.g. all CLIPGenericStatus and Geofence sensors)? Would you prefer to whitelist the sensors to be included, or to blacklist the sensors to be ignored? Of course, when blacklisting, newly created sensors by the app for routines or by Hue Labs would be exposed by default, whereas when whitelisting, newly connected Hue Motion sensors and Hue Dimmer and Hue Tap switches would be excluded by default. Neither feels quite right to me.

For individual sensors you would need something in config.json like:

"platforms": [
  {
    "platform": "Hue",
    "name": "Hue",
    "bridges": [
      {
        "id": "xxxxxxxxxx",
        "username": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "sensors": {
          "enabled": true,
          "blacklist": [ 1, 13, 14, 15, 20 ] 
        }
      }
    ]
  }
]

to ignore /sensors/1, /sensors/13, /sensors/14, /sensors/15, /sensors/20 and expose the other sensors. I think this would become too ugly, too complex. As you need to interact manually with the bridge to find the IDs of the sensors, I would probably prefer to use a resourcelink on the bridge to white/blacklist resources.

Alternatively, when only marking sensor types, config.json could be something like:

"platforms": [
  {
    "platform": "Hue",
    "name": "Hue",
    "sensors": {
      "zigbee": true,
      "CLIPGenericFlag": true,
      "CLIPGenericStatus": false,
      "GeoFence": false
    }
  }
]

to ignore CLIPGenericStatus and Geofence sensors. Seems more accessible, but you would still need to understand the types of your sensors.

As a workaround, you could create a dummy HomeKit room and move all the unusable sensors there, marking them as non-favourite. That way, they would hardly get in your way.

[lnlyssg]

I think at the moment I would just like the ability to turn off/hide sensor types as per the second example. As you say it has the potential to get very messy, very fast if you want to hide or show only specific sensors. It's very annoying that the Bridge seems to keep creating extra sensors when turning on/off geofencing, perhaps I need to feed that back to Philips......

[ebaauw]

Added config.json parameters clipsensors and rooms and changed alllights to philipslights in v0.1.0.

[lnlyssg]

Fantastic work @ebaauw! Thanks again.

[leoneleone]

Hello,

I would like to expose the Hue Motion Sensors I have, ignoring all the other sensors on the bridge (Tap, Dimmer, daylight and ambient light sensors).
What's the easiest to go about this? Can I use the blacklist method described above?
my preference would be to whitelist the sensors I want to include, rather than having to blacklist the sensors I don't want.
Also, how can I easily determine the which sensor is which from the numbering the Hue Bridge gives each sensor?

Thanks

[ebaauw]

Hi @leoneleone
It would seem you actually want to specify what types of sensors to expose, not which individual sensors. Apart from clipsensors, philipslights, and rooms, nothing mentioned in this issue has been implemented yet. I'm trying to understand what would be useful. From your remark about figuring out the IDs of the individual sensors, I gather that would become too complicated?
Interesting that you mention to leave out the lightlevel sensors. Each Hue Motion sensor is actually three sensors on the Hue bridge: a presence sensor, a lightlevel sensors, and a temperature sensor. So you would want to be able to specify the bridge sensor types, not the physical devices?

[leoneleone]

@ebaauw
Yes you are correct, Sensor Types is a more accurate term. I'd like to decide what Sensor Types to include in HomeKit (in my case, only the motion/presence sensor) otherwise my HomeKit setup becomes too cluttered. I have no real need to expose the Tap or Dimmer Switches to HomeKit, or the added Daylight and Ambient light parameters I see as part of my HomeKit setup now.

I've since figured out how to get the IDs for the Sensors, but Philips Hue doesn't make that easy for the average user.

The other thought I have is to perhaps combine the Sensor Types according to the Sensor Device itself. One Sensor Device (main service) with 3 HomeKit Services nested within it, you've mentioned this before in the ReadMe. While Home app would only show the main service, the others can be accessed and used as triggers via another HomeKit app (Evefor example). I think this would really clean up and simplify the Hue (Sensor) devices appearing in Home app. I think it's best to combine all the separate sensor services the Hue Bridge throws out HomeKit based on Sensor Type (Motion Sensor, Tap, Dimmer).

Another thought regarding the Hue Motion Sensors in particular:
I think it would be more accurate for the Hue Presence (Motion) component to be exposed as a HomeKit "Motion Sensor" rather than an "Occupancy Sensor". It is after all detecting motion and not monitoring the occupancy. I know this is a small and seemingly inconsequential adjustment, just wanted to point it out.

Also, it would be great to have control of the delay/sustain time for the motion off message using a HomeKit Custom Characteristic which could at least be Read and Written to using the Eve app. It could be called "Sustain" or "Delay". The same goes for the Sensitivity parameter. I would consider control of Delay and Sensitivity an added bonus for the plugin though. I believe Apple with ultimately add them as official HomeKit Characteritics at some point, now that Fibaro and Elgato have HomeKit Motion Sensors out on the market. We could just wait and see what comes in a new ios update.

Your plugin is great though man. Very good work.
I appreciate that you're thinking in terms of simplicity for the end user when making changes to the plugin.

[leoneleone]

Just to clarify more:
I want to specify which Hue Devices Types (Motion Sensor, Hue Tap, Hue Dimmer) to expose to HomeKit, but I also think the individual Hue Sensors (presence, light level, Temperature) should be combined HomeKit Services nested in the one HomeKit Accessory/device that appears in Home app. This may be more applicable to the Hue Motion Sensor in practice.
So what I would see in Home app is a representation of the Hue "physical" device (Motion Sensor), but if I click on details for that device then I would see the light level and temperature readings as extra Characteristics or parameters within that one Motion Sensor Device.

I hope that isn't confusing you at all 😬

[lnlyssg]

Another thought regarding the Hue Motion Sensors in particular:
I think it would be more accurate for the Hue Presence (Motion) component to be exposed as a HomeKit "Motion Sensor" rather than an "Occupancy Sensor". It is after all detecting motion and not monitoring the occupancy. I know this is a small and seemingly inconsequential adjustment, just wanted to point it out.

Erm, mine show up as motion sensors.... The icon in Apple's Home app is the same for Presence and Motion sensors but they are definitely different sensor types as can be seen in the Elgato Eve app.

[ebaauw]

I'd like to decide what Sensor Types to include in HomeKit (in my case, only the motion/presence sensor) otherwise my HomeKit setup becomes too cluttered.

I'll see what I can do. Personally, I'm more worried about the 99 bridged accessories limit, than I am about my HomeKit becoming too cluttered. I assign all the accessories I'm not interested in to a dummy room, and mark them non-favourite. They're hardly noticed...

Erm, mine show up as motion sensors.... The icon in Apple's Home app is the same for Presence and Motion sensors but they are definitely different sensor types as can be seen in the Elgato Eve app.

Indeed, Hue Motion sensors (or rather ZLLPresence sensors on the Hue bridge) are exposed to HomeKit as Motion Sensor, because, basically, that's what they are. CLIPPresence and Geofence sensors are exposed to HomeKit as Occupancy Sensor, because that's how the Hue app routines use these.

The other thought I have is to perhaps combine the Sensor Types according to the Sensor Device itself.

Yes I would like to expose the Hue Motion sensor as one HomeKit accessory with three services. Also in light of the 99 bridged accessory limit (I've got ten Hue motion sensors at my home, so this would free me up 20 accessories). I need to change the homebridge-hue design to be able to do that, however. The Hue bridge doesn't report (nor knows for that matter) that the three bridge sensors belong to the same physical device. I could connect them through their uniqueid, which starts with the Zigbee mac address, but there's no guarantee in which order they appear on the bridge. So I would have to create the accessory and the first service for the first bridge sensor, and add a service to the existing accessory for the second and third bridge sensor. This splitting of services from accessories comes close to the redesign needed for the the dynamic platform accessories (issue #4), which I've been delaying because it's challenging and a lot of work.

While Home app would only show the main service

I'm not at home right now so I cannot verify this, but I'm pretty sure it would show all three services, as separate tiles. It does for my homebridge-zp plugin for Sonos, which now exposes two services for one accessory.

Also, it would be great to have control of the delay/sustain time for the motion off message using a HomeKit Custom Characteristic which could at least be Read and Written to using the Eve app. It could be called "Sustain" or "Delay". The same goes for the Sensitivity parameter.

Controlling sensitivity From HomeKit is also on my wish list, see issue #9. Controlling the delay from HomeKit will not be possible, as this isn't a bridge attribute. Instead, it's hardcoded in the Hue bridge rules; it cannot even be parameterised through a CLIP sensor. Maintaining Hue bridge rules from HomeKit seems like a step too far, but granted, this is a slippery slope, see issue #41.

I've since figured out how to get the IDs for the Sensors, but Philips Hue doesn't make that easy for the average user.

For CLIP sensors, I expose the sensor ID (or rather the full resource) as Serial Number in the Accessory Information service. For Zigbee devices, I use the Zigbee mac address instead (except for Hue Motion Sensors and for Dresden Elektronik lights, which the Hue bridge treats as multiple resources - for these, I use the full uniqueid instead). I'll see if I can find another characteristic so I can expose the resource for Zigbee devices as well.

I appreciate that you're thinking in terms of simplicity for the end user when making changes to the plugin.

Thanks! That's the fun thing about this project: I'm also an end-user myself.

[leoneleone]

@ebaauw, @jaytay79
Yes you a right. They do show up as Motion Sensors in HomeKit. That remark was an oversight on my part. apologies.

I've been running into a problem which is tied to the naming of extra sensors (temp, ambience, etc) homebridge generates, because I am using 3 Hue bridged, this throws up multiple hue temp sensors with the same name. This eventually throws up an "Cannot add a bridged Accessory with the same UUID as another bridged Accessory". I don't know how to rename these accessories on the Hue Bridge so Homebridge doesn't see duplicate names when it runs:
[1/13/2017, 11:48:45 PM] [Hue] Hue Bedroom: 10 accessories [1/13/2017, 11:48:45 PM] [Hue] Hue Living Room: 11 accessories [1/13/2017, 11:48:45 PM] [Hue] Hue Spare Room: 11 accessories [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Hue Bedroom'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Daylight'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Hue tap Bathroom'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Hue tap Bedroom (Bed)'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Hue temperature sensor 1'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Bathroom sensor'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Hue ambient light sensor 1'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Hue temperature sensor 2'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Bathroom Shower sensor'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Hue ambient light sensor 2'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Hue Living Room'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Daylight'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Hue temperature sensor 1'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Toilet sensor'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Hue ambient light sensor 1'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Hue temperature sensor 2'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Kitchen sensor'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Hue ambient light sensor 2'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Hue temperature sensor 3'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Boiler Room sensor'... [1/13/2017, 11:48:45 PM] [Hue] Initializing platform accessory 'Hue ambient light sensor 3'... [1/13/2017, 11:48:46 PM] [Hue] Initializing platform accessory 'Hue Spare Room'... [1/13/2017, 11:48:46 PM] [Hue] Initializing platform accessory 'Daylight'... [1/13/2017, 11:48:46 PM] [Hue] Initializing platform accessory 'Hue tap Guest'... [1/13/2017, 11:48:46 PM] [Hue] Initializing platform accessory 'Hue tap Bedroom Bed'... [1/13/2017, 11:48:46 PM] [Hue] Cannot add a bridged Accessory with the same UUID as another bridged Accessory: fe8b0e45-d58c-48aa-83f7-d8e8c6f3967d
This could be easily solved if I could blacklist these extra sensors (temp sensors, ambient light sensors, Daylight), but I don't know how to do that as I am config file exposes sensors (true), but not CLIPsensors (false) and I only see the Zigbee MAC addresses for these sensors.

Is there a way for me to mark only the sensor types I want in the plugin config?
ex:
Motion Sensor: true
Ambient Light Sensor: false
Temperature Sensor: false
Daylight: false

I'm unsure how to do this in plugin config.
Sorry for the stupid questions, but I'm so confused by the Hue Api names for these sensors and how I should correctly target those particular sensors for blacklisting in homebridge.

Should I be exposing the CLIPsensors instead and just blacklist everything but the motion sensor for my purposes?

It would be great to have config options to blacklist each Hue sensor type individually similar to the example you mention above:
"platforms": [ { "platform": "Hue", "name": "Hue", "sensors": { "zigbee": true, "CLIPGenericFlag": true, "CLIPGenericStatus": false, "GeoFence": false } } ]

Thanks for the help again guys. I really appreciate it

[ebaauw]

This eventually throws up an "Cannot add a bridged Accessory with the same UUID as another bridged Accessory".

The accessory UUID is based on the device uniqueid (for Zigbee devices) or on the bridge ID and resource path, not on the name. I suspect you moved the Hue Tap switch to another bridge and didn't delete it from the old bridge. If you attach a dump of each of your bridges (see Troubleshooting in the README), I could check.

I don't know how to rename these accessories on the Hue Bridge so Homebridge doesn't see duplicate names when it runs

Easiest way: in the official Hue app under Accessory Setup under Settings (the gear symbol in the upper left corner). Again, homebridge-hue won't mind. Siri won't like duplicate names for services, but these can be changed from any HomeKit app.
Here you could also check for old Tap switches, but I don't think the Hue bridge marks Tap switches as unreachable.

Is there a way for me to mark only the sensor types I want in the plugin config?

Still, no (except for clipsensors).

I'm so confused by the Hue Api names for these sensors

You're not alone. If you start homebridge with homebridge -D, homebridge-hue will issue a message for each bridge resource it finds (oops typo), e.g.:

[1/14/2017, 1:58:30 AM] [Hue] philipshue: Daylight: Daylight sensor
[1/14/2017, 1:58:30 AM] [Hue] philipshue: Outside Temperature: ingoring CLIPTemperature sensor
[1/14/2017, 1:58:30 AM] [Hue] philipshue: Outside Humidity: ingoring CLIPHumidity sensor
[1/14/2017, 1:58:30 AM] [Hue] philipshue: Living Room: ingoring CLIPGenericFlag sensor
[1/14/2017, 1:58:30 AM] [Hue] philipshue: Living Room Motion: ZLLPresence sensor
[1/14/2017, 1:58:30 AM] [Hue] philipshue: Living Room Light Level: ZLLLightLevel sensor
[1/14/2017, 1:58:30 AM] [Hue] philipshue: Living Room Temperature: ZLLTemperature sensor
[1/14/2017, 1:58:30 AM] [Hue] philipshue: Living Room Dimmer: ZLLSwitch sensor
[1/14/2017, 1:58:30 AM] [Hue] philipshue: Downstairs Tap: ZGPSwitch sensor
[1/14/2017, 1:58:30 AM] [Hue] philipshue: Upstairs Tap: ZGPSwitch sensor
[1/14/2017, 1:58:30 AM] [Hue] philipshue: Living Room Status: ingoring CLIPGenericStatus sensor

This should allow you to link the name to the type. Alternatively, when you check the accessory information (hold the service tile on the iOS built-in Home app, press Details and scroll down) you'll see the type under Model. The base for the UUID is listed under Serial Number.

[leoneleone]

@ebaauw
Thanks for the clarification. I'll have a look at the output today.

One thought I had about the Delay/Sustain I mentioned before:
Can the plugin itself create an added Delay Characteristic within homebridge/HomeKit which sustains the Motion Triggered HomeKit status, completely separately from the Hue Bridge rules? So it would just generate that delay within the HomeKit functionality of the Motion information visible only to HomeKit. The delay time for each (HomeKit) Motion Sensor can be set individually within the Home app and wouldn't rely on the Hue Bridge for this parameter?

[ebaauw]

If homebridge-hue would create a custom Delay characteristic, the iOS built-in Home wouldn't support it, but other HomeKit apps mights.

Not sure I understand what you're asking: do you want homebridge-hue to lie about the bridge sensor state and continue to report Motion Detected until the delay time has passed? I don't think homebridge-hue should be in the space of home automation rules: these should be in the Hue bridge and/or in HomeKit. In my view, homebridge-hue should "just" be a bridge between the Hue bridge and HomeKit.

I agree there's a huge mismatch between the functionality the Hue Motion sensor (or any motion sensor) offers (viz. Motion Detected) vs the functionality you'd want to turn off the lights automatically (viz. Occupancy Detected), but solving this requires way more than a simple delay.

For my home I've created a CLIPGenericStatus sensor per room to keep track of (amonst others) room occupancy and a CLIPGenericFlag sensor acting as virtual master switch for each room. I've created a whole bunch of Hue bridge rules, that update the room status based on the Hue motion sensors in that room and in the adjacent rooms (so I can actually detect leaving a room as opposed to no more motion detected), changing the room master switch appropriately. I can manually override the room master switch from any HomeKit app; the room's Hue Dimmer switch also sets the room master switch. Then I've created a second set of Hue bridge rules to interact with the room lights, based on the room master switch and the room light level.

For a number of reasons, I like to keep my HomeKit configuration lean and mean, and have most intelligence in the Hue bridge:

• The Hue bridge provides way richer functionality for rules than HomeKit does for triggers;
• Lights control through Hue Motion sensors and Hue Dimmer switches continues to work autonomously, even when the server running homebridge or the network is down;
• I don't have a backup of my HomeKit configuration - I would need to create an iOS HomeKit app for that.

The Hue bridge allows conditions like "1 minute after the status became 2". Unfortunately, both the "1 minute" and the "2" are hard-coded in the rule. I cannot programme the detection for leaving a room in HomeKit. I only use the room master switch in HomeKit triggers, to turn on/off the room Sonos speakers while turning on/off the lights from the Hue bridge.

Maintaining these Hue bridge rules is a real pain in the lower back. I use a series of shell scripts, wrapping around curl to interact directly with the Hue bridge over the Hue API. These scripts re-create my entire Hue bridge configuration, doubling as backup for my Hue bridge.

I've yet to publish these shell scripts on GitHub. The thing holding me back is these scripts rely on a little macOS command line utility I've written in Swift to format and manipulate json. I don't want to spend the time to port this utility to the Raspberry Pi (or other platforms).

[ebaauw]

Version 0.1.11 allows blacklisting of sensor types, see README.

E.g. to expose only the Motion Sensor and Light Sensor sensors of the Hue Motion sensor, specify in config.json

"excludeSensorTypes": [ "CLIP", "Geofence", "Daylight", "ZLLTemperature", "ZLLSwitch", "ZGPSwitch"]

[ebaauw]

As of v0.5.51 individual resources to be exposed to HomeKit can be whitelisted or blacklisted using bridge/gateway resourcelinks.

[homefuzz-oz]

Just started using homebridge-hue a few days ago and it‘s a great project - thank you!

my setup is a raspbee running on a PI as bridge. I’ve hooked up a generic (Sercomm) Zigbee plug to it, which Phoscon doesn’t fully support by means of allowing to configure the plug’s properties. Phoscon recognises it as a switch in setup, but then only allows adding it as light in room config (because it only supports lights and sensors, not switches, there). So, I can make it appear as a „light“ by adding lights=true in homebridge-hue, but that means it shows up as a light symbol in HomeKit. Optimally, I would have it as a power point symbol, but not sure if that is an ultimate limitation of Phoscon to assign the correct types and pass them on to homebridge-hue or if homebridge-hue could have an ability to reclassify the type coming from Phoscon to show up the correct device type in HomeKit. Ie incoming „light“ -> outgoing „plug“?

Also where I can I see the current type-granularity (light, sensor, switch, socket/plug etc) that homebridge-hue supports? From the wiki, I only gather lights and sensors.

[ebaauw]

The deCONZ REST API (as well as the Hue API) exposes Zigbee devices as /lights or /sensors resources. In config.json, you can specify what type of resources Homebridge Hue should expose, see https://github.com/ebaauw/homebridge-hue/wiki/Configuration.

For finer-grained control, of individual resources, you can create resourcelink through the API. An outlet resourcelink specifies which /lights (and /groups) resources are to be exposed as Outlet instead of Lightbulb. Too many Zigbee devices expose the wrong device type, so I no longer try to predict whether a /lights resource is actually for an outlet. ph outlet will create an initial resourcelink for you, based on the device types, but you might want to review that.

[homefuzz-oz]

Thank you. I think I had misunderstood the resourcelink topic before, so will give that a go.

[homefuzz-oz]

@ebaauw, thank you again for the advice above. That worked perfectly by adding the given device to an outlet resource link. Found a few interesting things by exploring the deCONZ REST API in the process, for example a ghost Philips Hue light that doesn't exist.
If I think ahead, since HomeKit supports many more devices types, including
Lights
Switches
Outlets
Thermostats
Window Blinds
Fans
Air Conditioners
Humidifiers
Air Purifiers
Sensors
Locks
Cameras
Doorbells
Garage Doors
Sprinklers
Speakers
Routers
TVs

Am I correct in assuming I can manually create a resourcelink for all these, so I can add the devices according to their actual device type and homebridge-hue would recognise that? Even though ph may not support an automated command for ph sprinkler, for example.

[ebaauw]

No, of course not. It doesn’t make sense e.g. to expose a light as a camera. See https://github.com/ebaauw/homebridge-hue/wiki/Resource-Links for the types of resource links that Homebridge Hue supports.