Thanks for your work on this plugin!

I'm trying to use it to control Groups (as I've got quite a few Hue bulbs I breach the 100-devices per bridge Homekit limit if I add each bulb individually).

Everything seems to work fine apart from setting the Hue of the Group. Whenever I set the Hue either via a Scene or recalling a favourite color (using the iOS10 Home app) it fails. Dragging around the colour wheel does seem to work fine.

Hello friends,

i've set up homebridge-hue and everything is working good except for the room and Name setup.
Everytime i set rooms and namens to my motion sensors and the rest which is added by homebridge, it gets back to "standard room" after a few seconds. It's not working with different Apps (Apple Home, eve..) and parameters in config.
Does anybody know what could be wrong?

Thank you very much!
Wince

Hi,

I'm just wondering if anyone has added more than one Hue Bridge to their config.json file. I have three I want to add, but I'm trying to avoid having to reset my homekit configuration or deleting homebridge if anything goes wrong.

Any advice or pitfalls to look out for, or indeed a working process for adding more than one Hue Bridge via this plugin?
Your help is much appreciated.

Currently, homebridge-hue doesn't support the dark and daylight ZLLLightLevel sensor state attributes.

HomeKit apps display Error for temperature sensors when temperature drops below zero.

By default, HomeKit limits the Current Temperature characteristic to values between 0.0˚C and 100.0˚C. While this might be appropriate for room temperature, it is not for outside temperature.

Rather than spending money on a weather station, I run a little shell script that updates a CLIPTemperature and a CLIPHumidity sensor every 30 minutes from wunderground.com. When the temperature drops below zero, homebridge-hue sets the Current Temperature sensor to a negative value, which HomeKit doesn't accept as it's out of range, hence the Error.

Fix is easy: overwrite the default properties for the Current Temperature characteristic to allow a larger range. As this is a read-only characteristic, better set the range as large as conceivable: from absolute zero (-273.15, or rounded -273.2˚C) to 1000.0˚C. Even the iOS 10 Home app seems to like this. I suppose that's how accessories like the Eve Weather deal with this as well.

Hi,

if I use homebridge-hue as my only plugin, then everything works like a charm. But If I enable my other plugins (e.g. harmony-hub, homematic), then all my hue devices are gone in the home kit app. The log shows:

[2016-12-09 23:54:28] Homebridge is running on port 51826.
[2016-12-09 23:54:28] [Hue] Philips hue: hue bridge communication error ECONNRESET - retrying in 300ms
[2016-12-09 23:54:28] [Hue] Philips hue: hue bridge request: get /sensors
[2016-12-09 23:54:30] [Hue] Philips hue: found 13 accessories

It seems, that the hue plugin loads to slow and therefor the bridge is already running.

If I use it as the only plugin, then the info "Philips hue: found 13 accessories" appears before "Homebridge is running on port 51826."

Is there any chance that homebridge waits for the hue plugin?

I am using Hue Bridge v1 and a Raspberry Pi Model B. Looking forward for any help/support.

Thanks,
Daniel

Currently homebridge-hue uses static homebridge accessories, configured at start-up time.

With dynamic homebridge accessories, homebridge-hue could dynamically add or remove accessories as they are added to or removed from the Hue bridge, without restarting homebridge. Not sure if that's really a big win (how often do you buy new hue lights, switches, or sensors), but it could be handy for CLIP sensors and schedules.

However, the ability to store an accessory context might be useful to store the bridge username in the bridge accessory (once we support that) without the need to update manually config.json. Also, this would allow for config switches for lights, groups, sensors, schedules in the bridge accessory.

Recently I discovered that request actually takes a json option, which allows requestObj.body to be an object (instead of a string) and returns responseBody as an object as well, eliminating the need to call to JSON.parse().
Using this would simplify HueLight.set...(), HueSensor.setValue(), etc, as well as HueBridge.request() and HuePlatform.findBridges().

Not really sure what to make of these, but they appear in the error log when I attempt to change the lights. Using the iOS 10 Home app, I get a "Failed" state on Philips Hue bulbs when attempting to tap a scene. From what I can tell, it looks like this usually occurs for bulbs that are trying to change more than one parameter (e.g. hue, saturation, brightness) within on scene.

[11/10/2016, 11:31:59 AM] [Hue] Philips hue: hue bridge communication error Error: ESOCKETTIMEDOUT
[11/10/2016, 11:33:59 AM] [Hue] Philips hue: hue bridge communication error Error: ESOCKETTIMEDOUT
[11/10/2016, 11:58:02 AM] [Hue] Philips hue: hue bridge communication error Error: ESOCKETTIMEDOUT
[11/10/2016, 12:05:58 PM] [Hue] Philips hue: hue bridge communication error Error: ESOCKETTIMEDOUT
[11/10/2016, 12:10:58 PM] [Hue] Philips hue: hue bridge communication error Error: ESOCKETTIMEDOUT
[11/10/2016, 12:20:14 PM] [Hue] Philips hue: hue bridge communication error Error: ETIMEDOUT

I've also noticed in the log file that bulbs appear to be changed from "0" to "false" (or vice versa), and "1" to "true". Seems like the type of a variable isn't set correctly, but I could be wrong...

[11/10/2016, 10:28:48 AM] [Hue] Bedroom - Tall: set homekit power from false to 0
[11/10/2016, 10:28:48 AM] [Hue] Bedroom - Medium: set homekit power from false to 0
[11/10/2016, 10:28:48 AM] [Hue] Bedroom - Medium: set homekit color temperature from 2000K to 3984K
[11/10/2016, 10:28:48 AM] [Hue] Bedroom - Short: set homekit power from false to 0
[11/10/2016, 10:28:48 AM] [Hue] Bedroom - Short: set homekit color temperature from 2000K to 3984K

I am running Homebridge on a Raspberry Pi 2 B+ and I have the 1st Generation Hue Hub. This is my config file:

{
	"bridge": {
		"name": "Homebridge",
		"username": "<<REDACTED>>",
		"port": <<REDACTED>>,
		"pin": "<<REDACTED>>"
	},

	"description": "Description - not very helpful...",

	"platforms": [
		{
			"platform": "Hue",
			"name": "Hue",
			"host": "<<REDACTED>>",
			"users": {
				"<<REDACTED>>": "<<REDACTED>>"
			},
			"heartrate": 5,
			"timeout": 5,
			"lights": true,
			"alllights": true,
			"groups": false,
			"sensors": true,
			"schedules": false,
			"rules": false
		}
	],
	
	"accessories": [
		{
			"accessory": "WUNDERGROUND",
			"name": "Weather Conditions",
			"device": "Raspberry Pi",
			"key": "<<REDACTED>>",
			"city": "<<REDACTED>>"
		},
		{
			"accessory": "people",
			"name": "People",
			"people": [
				{"name": "<<REDACTED>>", "target": "<<REDACTED>>"},
				{"name": "<<REDACTED>>", "target": "<<REDACTED>>"}
			],
			"threshold": 15
		},
		{
			"accessory": "HttpTemphum",
			"name": "Living Room Conditions",
			"url": "<<REDACTED>>",
			"sendimmediately": "",
			"http_method": "GET"
		}
	]
}

I'm looking at switching from homebridge-philipshue to homebridge-hue as I'd love to HomeKit-ify some tap sensors, so they also control non-hue accessories. So far this is working great.

One thing I lost in the transition though is being able to see an up-to-date current state of Hue lights within the Home app. It seems when the lights are controlled through HomeKit the last requested state is remembered, but for lights controlled via Tap switches, Alarms, or the native Hue app this is not the case.

Would you consider polling the light state from he bridge when it is requested over HomeKit?

Hi,

I have two plarforms in my config.json: eDomoticz and Nest. Both work perfectly. When I added the hue platform, both stopped working.
I don't know if it is because of node.js version since I see npm WARN engine [email protected]: wanted: {"homebridge":"^0.4.16","node":"^6.9.1"} (current: {"node":"4.5.0","npm":"2.15.9"}) when installing homebridge-hue or not.
Here is how my config.json is:

{
        "bridge": {
                "name": "Homebridge",
                "username": "CC:21:3E:E4:DE:33",
                "port": 51826,
                "pin": "031-45-154"
        },
        "description": "Configuration file for (e)xtended Domoticz platform.",
        "platforms": [{
                        "platform": "eDomoticz",
                        "name": "eDomoticz",
                        "server": "192.168.0.104",
                        "port": "8888",
                        "ssl": 0,
                        "roomid": 0
                }, {
                        "platform": "Nest",
                        "username": "#######",
                        "password": "#######"
                }, {
                        "platform": "Hue",
                        "name": "Hue"
                }

        ],
        "accessories": []
}

If you have any idea, I'd be grateful.
Thanks.

Everything works fine until it asks to click the button to create a user. I have clicked several times but I get: "Philips hue: hue bridge error 2: body contains invalid json".

Anything simple I am missing?

I finally got me some Philips color temperature lights. It appears that for these lamps, the gen2 (square) Hue bridge actually exposes color temperature as a custom characteristic type E887EF67-509A-552D-A138-3DA215050F46. Like the color temperature exposed by homebridge-hue, this custom characteristic type is not supported by the iOS Home app, but Elgato's Eve and Matthias Hochgatterer's Home do support this. Philips did a lousy job, however, as they expose the Hue bridge ct value instead of the color temperature in Kelvin (Eve actually converts the ct value to Kelvin in the app). In addition, the Hue bridge only exposes this characteristic for color temperature lights, not for extended color lights (which also support ct).

I want to mimic the gen2 Hue bridge behaviour as closely as possible in homebridge-hue and expose color temperature using the same custom characteristic type as the gen2 Hue bridge. However, both Eve and Home use a fixed range for the values this characteristic type can take, rather than a range per characteristic instance. The fixed range is from 153 to 454, or ~6500K to ~2200K, which is the range the Philips color temperature lights support. Of course, hoembridge-hue would specify the range the light supports for each characteristic instance (153 to 500 (~2000K) for Philips extended color lights; 153 to 370 (~2700K) for Osram Lightly color temperature lights). I've contacted both Elgato and Matthias to see if they are willing to support this.

For now I'll be exposing the "old" Color Temparature characteristic type, in addition to the Hue bridge type. To expose the Hue bridge color temperature, set "ct": true in config.json.

Following on from some issues with my homebridge set-up I had to remove homebridge and re-add it. I also updated all my plugins at the same time. I have 4 innr GU10 bulbs in my kitchen and since re-doing the HomeKit set-up I now find that all but one are getting mis-identified - like this. Note that when I first re-added homebridge all of these 4 lights appeared correctly as lights....

I attempted to perform an Identify on the homebridge accessory using Elgato Eve as per the troubleshooting instructions but no debug bridge json file is getting created when I do it....

The relevant part of my config.json is below, and here is my slightly edited log file

{
		"platform": "Hue",
		"name": "Hue",
		"host": "",
		"users": {
			"removed": "removed"
		},
		"heartrate": 5,
		"timeout": 5,
		"lights": true,
		"philipslights": false,
		"groups": false,
		"group0": false,
		"rooms": false,
		"sensors": true,
		"clipsensors": true,
		"schedules": false,
		"rules": false,term
                "excludeSensorTypes": [ "CLIP", "ZLLSwitch", "ZGPSwitch", "Geofence"]
	}

Quick edit: I removed the accessories and persist folders, removed homebridge and re-added it again and everything is showing correctly again, for now.....

Im trying to test homebridge-hue, but at the start of homebridge i'm getting this log message:

[2017-01-18 23:10:37] [Hue] Philips hue: hue bridge request #108: post / {"devicetype":"homebridge-hue#Mac-mini-di-Emanuele-7.local"}
[2017-01-18 23:10:37] [Hue] Philips hue: hue bridge error 7: invalid value,  homebridge-hue#Mac-mini-di-Emanuele-7.local, for parameter, devicetype
[2017-01-18 23:10:37] [Hue] Philips hue: press link button on the bridge to create a user

Even if I press the link button, I get the same message.

This is my config.json:

{
    "bridge": {
        "name": "Homebridge",
        "username": "CC:22:3D:E3:CE:30",
        "port": 51826,
        "pin": "031-45-154"
    },
    "platforms": [
    {
      "platform": "Hue",
      "name": "Hue",
      "host": "192.168.1.137",
      "users": {
      },
      "heartrate": 5,
      "timeout": 5,
      "lights": false,
      "philipslights": false,
      "ct": false,
      "groups": false,
      "group0": true,
      "rooms": false,
      "sensors": true,
      "excludeSensorTypes": [],
      "schedules": false,
      "rules": false
    }
    ],
    "accessories": [
    ]
}

Hi,

I'm try to add the plugin on my HomeBridge (OS X or Linux). I have an error on Home App, with iOS 10.1.1.

The Dimmer Icon tell me that's not compatible.

This is my config.json (only hue I added to try):

server:.homebridge thegod$ cat config.json
{
"bridge": {
"name": "HomeProva",
"username": "XXXXX",
"port": 51826,
"pin": "XXXXX"
},

"platforms": [
{
"platform": "Hue",
"name": "Hue",
"host": "XXXX",
"users": {
"XXXX": "XXXXXX"
},
"heartrate": 5,
"timeout": 5,
"lights": true,
"philipslights": true,
"groups": false,
"group0": true,
"rooms": false,
"sensors": true,
"clipsensors": false,
"schedules": false,
"rules": false
}]
}

Log when start:

server:.homebridge thegod$ homebridge
[2016-12-13 13:13:01] Loaded plugin: homebridge-foscam
[2016-12-13 13:13:01] Registering accessory 'homebridge-foscam.Foscam'
[2016-12-13 13:13:01] ---
[2016-12-13 13:13:01] Loaded plugin: homebridge-hue
[2016-12-13 13:13:01] Registering platform 'homebridge-hue.Hue'
[2016-12-13 13:13:01] ---
[2016-12-13 13:13:01] Loaded plugin: homebridge-ifttt
[2016-12-13 13:13:01] Registering platform 'homebridge-ifttt.IFTTT'
[2016-12-13 13:13:01] ---
[2016-12-13 13:13:01] Loaded plugin: homebridge-netatmo
[2016-12-13 13:13:01] Registering platform 'homebridge-netatmo.netatmo'
[2016-12-13 13:13:01] ---
[2016-12-13 13:13:01] Loaded plugin: homebridge-roomba980
[2016-12-13 13:13:01] Registering accessory 'homebridge-roomba980.Roomba980'
[2016-12-13 13:13:01] ---
[2016-12-13 13:13:01] Loaded config.json with 0 accessories and 1 platforms.
[2016-12-13 13:13:01] ---
[2016-12-13 13:13:01] Loading 1 platforms...
[2016-12-13 13:13:01] [Hue] Initializing Hue platform...
[2016-12-13 13:13:01] [Hue] homebridge-hue v0.1.0, node v6.9.1, homebridge v2.1
[2016-12-13 13:13:01] [Hue] Philips hue: BSB002 bridge, api v1.16.0
[2016-12-13 13:13:02] [Hue] Philips hue: 20 accessories
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Philips hue'...
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Ufficio'...
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Camera'...
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Bagno'...
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Palla'...
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Divano'...
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Salotto'...
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Cucina'...
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Entrata'...
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Comodino Marco'...
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Balcone Cucina'...
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Striscia'...
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Sottoscala'...
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Balcone Soggiorno'...
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Comodino Sara'...
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Daylight'...
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Pulsante Entrata'...
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Pulsante Camera'...
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Grandepuffo'...
[2016-12-13 13:13:02] [Hue] Initializing platform accessory 'Puffetta'...
Scan this code with your HomeKit App on your iOS device to pair with Homebridge:

The bulbs aro ok. But dimmer and button not function.

Can you help me?

Because homebridge-hue polls the Hue bridge, it cannot detect reliably all buttonevents. E.g. when a button is pressed and released between to heartbeats, homebridge-hue only sees the release buttonevent; but when the button is pressed just before a heartbeat and released just after, homebridge-hue sees both events. To cope with this, homebridge-hue currently only changes the Output State of the Stateful Programmable Switch service corresponding to a Hue Dimmer switch, when a dimmer button is released.

This causes the HomeKit change to happen late, especially when a button is pressed, held for several seconds and then released. Homebridge-hue should change the Output State as soon as it detects the first event in a press/hold/release series, and not change the state for the next events in the same series.

I restarted homebridge earlier today to find nothing showing up from homebridge-hue in HomeKit. The log showed no errors other than a lot less messages from homebridge-hue. After restarting homebridge with the -D option I spotted "[12/28/2016, 11:22:43 AM] [Hue] contacting meethue portal" in the log and then when I went and looked at my bridge spotted that the internet/meethue light was flashing merrily away. A quick reboot of my router got it all back working again, however would it be possible for the plugin to spit out an error message to the log when it can't get a response from meethue.com? It would have made it much easier to see what was wrong!

Currently homebridge-hue only supports the on, battery, and alert sensor config attributes, where on maps to StatusActive, which is readonly in homekit, battery to BatteryLevel and alert to Identify, which is write only in homekit.

I wanted to support enabling/disabling a sensor from homekit, by mapping on to a homekit On characteristic. However homekit doesn't support multiple characteristics of the same type for one service (which would be needed for enabling/disabling a CLIPGenericFlag or supporting additional boolean configuration parameters, like ledindication and usertest. Homekit does support multiple services per accessory, but this seems to confuse most homekit apps.

I don't know what is the problem exactly, but i do see that the homebridge stops working when installing the homewizard-hue.

Homebridge did work, but never with hue. Normally i use homebridge-homewizard. But because after a while the homebridge cannot be seen on my iphone i wanted to find out what the problem could be. homebridge? homebridge-homewizard?

So i did unnstall all plugins and only installed the homebridge-hue. But can't get it to work.
I have a version 1 philips bridge.

This is in the install:
npm install -g homebridge-hue
This in in the config:
{
"bridge": {
"name": "Homebridge is Working",
"username": "CC:22:33:11:EE:88",
"port": 51825,
"pin": "012-34-567"
},

"platforms": [{
"platform": "Hue",
"name": "Hue"
}

],

"accessories": [

]

}

This is the log:
2017-01-19 10:09:16 stdout at Function.Module._load (module.js:424:3)
2017-01-18 20:09:16 stdout at tryModuleLoad (module.js:432:12)
2017-01-18 20:09:16 stdout at Module.load (module.js:473:32)
2017-01-18 20:09:16 stdout at Object.Module._extensions..js (module.js:565:10)
2017-01-18 20:09:16 stdout at Module._compile (module.js:556:32)
2017-01-18 20:09:16 stdout at Object. (/usr/lib/node_modules/homebridge/bin/homebridge:17:22)
2017-01-18 20:09:16 stdout at module.exports (/usr/lib/node_modules/homebridge/lib/cli.js:40:10)
2017-01-18 20:09:16 stdout at Server.run (/usr/lib/node_modules/homebridge/lib/server.js:77:36)
2017-01-18 20:09:16 stdout at Server._loadPlatforms (/usr/lib/node_modules/homebridge/lib/server.js:281:45)
2017-01-18 20:09:16 stdout at API.platform (/usr/lib/node_modules/homebridge/lib/api.js:118:13)
2017-01-18 20:09:16 stdout Error: The requested platform 'Hue' was not registered by any plugin.
2017-01-18 20:09:16 stdout
2017-01-18 20:09:16 stdout ^
2017-01-18 20:09:16 stdout throw new Error("The requested platform '" + name + "' was not registered by any plugin.");
2017-01-18 20:09:16 stdout /usr/lib/node_modules/homebridge/lib/api.js:118
2017-01-18 20:09:16 stdout [1/19/2017, 10:09:16 AM] Loading 1 platforms...
2017-01-18 20:09:16 stdout [1/19/2017, 10:09:16 AM] ---
2017-01-18 20:09:16 stdout [1/19/2017, 10:09:16 AM] Loaded config.json with 0 accessories and 1 platforms.
2017-01-18 20:09:16 stdout [1/19/2017, 10:09:16 AM] �[33mNo plugins found. See the README for information on installing plugins.�[39m
2017-01-18 20:09:16 stdout [1/19/2017, 10:09:16 AM] �[1m�[31m====================�[39m�[22m
2017-01-18 20:09:16 stdout at Module.load (module.js:473:32)�[39m�[22m
2017-01-18 20:09:16 stdout at Object.Module._extensions..js (module.js:565:10)
2017-01-18 20:09:16 stdout at Module._compile (module.js:556:32)
2017-01-18 20:09:16 stdout at Object. (/usr/lib/node_modules/homebridge/bin/homebridge:17:22)
2017-01-18 20:09:16 stdout at module.exports (/usr/lib/node_modules/homebridge/lib/cli.js:26:16)
2017-01-18 20:09:16 stdout at new Server (/usr/lib/node_modules/homebridge/lib/server.js:48:24)
2017-01-18 20:09:16 stdout at Server._loadPlugins (/usr/lib/node_modules/homebridge/lib/server.js:125:22)
2017-01-18 20:09:16 stdout at Array.forEach (native)
2017-01-18 20:09:16 stdout at Server. (/usr/lib/node_modules/homebridge/lib/server.js:129:14)
2017-01-18 20:09:16 stdout at Plugin.load (/usr/lib/node_modules/homebridge/lib/plugin.js:56:11)
2017-01-18 20:09:16 stdout [1/19/2017, 10:09:16 AM] �[1m�[31mError: Plugin /usr/lib/node_modules/homebridge-hue requires a HomeBridge version of ^0.4.16 which does not satisfy the current HomeBridge version of 0.4.6. You may need to upgrade your installation of HomeBridge.
2017-01-18 20:09:16 stdout [1/19/2017, 10:09:16 AM] �[1m�[31mERROR LOADING PLUGIN homebridge-hue:�[39m�[22m
2017-01-18 20:09:16 stdout [1/19/2017, 10:09:16 AM] �[1m�[31m====================�[39m�[22m
2017-01-18 20:09:15 stdout *** WARNING *** For more information see http://0pointer.de/avahi-compat?s=libdns_sd&e=nodejs&f=DNSServiceRegister
2017-01-18 20:09:15 stdout *** WARNING *** Please fix your application to use the native API of Avahi!
2017-01-18 20:09:15 stdout *** WARNING *** The program 'nodejs' called 'DNSServiceRegister()' which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi.
2017-01-18 20:09:15 stdout *** WARNING *** For more information see http://0pointer.de/avahi-compat?s=libdns_sd&e=nodejs
2017-01-18 20:09:15 stdout *** WARNING *** Please fix your application to use the native API of Avahi!
2017-01-18 20:09:15 stdout *** WARNING *** The program 'nodejs' uses the Apple Bonjour compatibility layer of Avahi.
2017-01-18 20:09:14 stdout Executing /root/.homebridge/install.sh.

Expose the bridge button as a homekit switch, so it can be used to trigger homekit rules.

Hi,
when using homebridge-hue I get the following error message:
throw new Error("Cannot add a bridged Accessory with the same UUID as another bridged Accessory: " + existing.UUID);

I assume this is due to the fact that I have a non Philips hue light which registers always twice:
[2016-11-03 20:51:13] [Hue] Philips hue: found 3 accessories
[2016-11-03 20:51:17] [Hue] Initializing platform accessory 'Philips hue'...
[2016-11-03 20:51:17] [Hue] Initializing platform accessory 'Treppenhaus-LED-Streifen'...
[2016-11-03 20:51:17] [Hue] Initializing platform accessory 'Dimmable light 1'...

However, the last two accessories are just one light! It is a RGBW-LED stripe module which simultaneously drives an RGB and a white (W) channel. The RGB part and the W part register as separate lights. It works without problems using the Philips Hue app. However, this light is not accessible via Homekit - hence my hope was to get it working via hombridge.
Link to the product web site below.

Any suggestion how to circuvent this error?
Thanks!
Thomas

https://www.dresden-elektronik.de/funktechnik/solutions/wireless-light-control/wireless-ballasts/fls-pp-lp/?L=1&cHash=c9c902ccdb43164696acccf81b62b2bd

Hi,

Thanks for your work on this!

I've got a Hue group made up entirely of these Osram bulbs:

https://www.amazon.co.uk/dp/B00YSXBHS4

Through the native Hue app I can adjust the color temperature, but then I expose them in a group via the plugin I only see "Brightness" via the iOS Home app, not Colour.

Is this the expected behaviour?

Thanks!

I see this in my log when starting home bridge

[12/5/2016, 12:27:55 PM] [Hue] Bow Quarter: api version 1.16.0 instead of 1.15.0

And I don't seem to have any sensors exposed...
Does something need updating?

Thanks.

It would be great if there was some way we could get a switch within home kit to enable or disable our hue motion sensors from running entirely.

first of all great plugin and thx for all the hard work and effort building/maintaining this. I use homebridge for harmony hub alongside some hue bulbs/hue bridge 2.0 that have homekit build in. Now I just added 2 hue dimmers and I want to add them to homekit through your plugin. I get to the point to add the hue platform and the notification in terminal to push my bridge and then the generated username and password. But when I include those in the config.json alongside the other stuff from heart rate until rules and restart homebridge I get an error message: There was a problem reading your config.json file. SyntaxError: Unexpected token   in JSON at position 262
at JSON.parse ()

verifying my config.json at jsonlint gives a valid json.

I tried using normal text editor and atom, I'm on Mac.

If you need more files etc. please let me know. Im new to Github so sorry if didn't include things I don't know of. Really would like to use your plugin.

As suggested by @dylanslewis (in issue #4), allow for changing the polling interval from HomeKit instead of from config.json. Add a StatefulProgrammableSwitch service to the Homekit accessory for each bridge, mapping the heartrate to Output State and the time of the last sync to Last Updated. Could even use Switch and use On to turn off polling altogether.

Notes to self:

• Need to change setInterval() loop in HuePlatform.accessories() to fire every second and call HueBridge.heartbeat() with counter and check for counter % heartrate === 0 in each bridge.
• Need to change the handling of "get" events from HomeKit to issue ad hoc bridge state refresh when heartbeat is off.

Folks, I'm thinking about changing the way homebridge-hue behaves when lights are off. I would like to hear your thoughts on this.
Note: by "off" or "on", I mean turning the light off or on through the Hue bridge, while the light remains connected to the mains power.

Current Behaviour
The Hue bridge does not accept changes to a light state (brightness, colour) when that light is off. Currently, homebridge-hue propagates each change to a light state from HomeKit to the Hue bridge, regardless whether the light is on or off. This could result in an error, e.g. when changing brightness while the light is off:

[1/7/2017, 10:30:59 AM] [Hue] philipshue: hue bridge error 201: parameter, bri, is not modifiable. Device is set to off.

Note that the v2 (square) Hue bridge silently ignores this limitation when exposing lights to HomeKit. HomeKit shows the new value, but the light state isn't changed on the Hue bridge (nor in the light).

The Hue bridge treats the light state as a single object, enabling changes to power, brightness, colour in a single command. HomeKit treats each attribute as a separate characteristic, notifying homebridge-hue one change at a time. Currently, homebridge-hue propagates these changes 1:1 to the Hue bridge, using a separate command for each characteristic.

In particular, a HomeKit scene turning a light on at a particular brightness and colour results in four characteristic changes in HomeKit (colour is actually two characteristics, hue and saturation), and four commands from homebridge-hue to the Hue bridge. The could lead to strange behaviour, e.g. when the colour change is received by homebridge-hue before the power change, the colour will not be set (because the light is still off); when the power change is received first, the colour will be set (because now the light is already on).

When only instructed to turn on (without specifying any brightness nor colour), most lights turn on using their previous brightness and colour from when they were turned off. Most lights, the exception being the innr lightstrips under my kitchen cabinets and the pucks in my bedroom Ikea wardrobes - these turn on at full brightness.

Proposed New Behaviour
When receiving HomeKit changes to brightness or colour, while a light is off, homebridge-hue could save these changes. Then, when the light is turned on from HomeKit, homebridge-hue would send a command to the Hue bridge to turn the light on with the saved brightness and colour, instead of leaving it up to the light to use its previous state.

Hello, everything worked fine. Thank you!

Today i just wanted to include some lightify plugs, which are in hue. But now the dockers on my synology stopped. So i reinstalled the homebridge, but i always get this message:

Error: Plugin /usr/lib/node_modules/homebridge-hue requires a HomeBridge version of ^0.4.16 which does not satisfy the current HomeBridge version of 0.4.6. You may need to upgrade your installation of HomeBridge

Internally, homekit identifies services by UUID. The homebridge-hue plug-in bases this UUID on the bridge id and the resource URI (e.g. /sensors/1), not on the resource name (e.g. Daylight). This way, homebridge-hue can deal with duplicate names between lights, groups, sensors, schedules. In addition, Homekit will still recognise the service after the resource name has changed on the Hue bridge, remembering which Homekit room, scenes, schedules, and rules it belonged to. However, when a Hue bridge resource is deleted and then re-created, resulting in a different URI, Homekit will not recognise the new service, and you need to re-add the new service to any Homekit rooms, scenes, schedules, and rules.
As Zigbee Lights and sensors already have a unique ID (something like a Zigbee MAC address?), this could be used as UUID base, using the current bridge id and URI scheme only for non-Zigbee resources like groups, CLIP sensors, and schedules. As this will break existing homekit configurations, we might need a config parameter to keep the current scheme.

Hi, I've recently installed homebridge-hue and believe I have set it up correctly. I only want access to the sensors as I have a gen 2 bridge already connected to HomeKit.

When I run homebridge I get:

[11/21/2016, 7:46:51 AM] [Hue] Initializing Hue platform...
[11/21/2016, 7:46:51 AM] Loading 3 accessories...

However in the Home app and in the Eve app I can't see any new devices.

My config is as follows:

{
	"platform": "Hue",
	"name": "Hue",
	"host": "",
	"users": {
		"###": "###-###"
	},
	"heartrate": 5,
	"timeout": 5,
	"lights": false,
	"alllights": false,
	"groups": false,
	"sensors": true,
	"schedules": false,
	"rules": false
}

Does sensors need to be something other than True? I have 2 Hue Motion Sensors, a Hue Tap and a Hue Dimmer.

Thanks

Currently, homebridge-hue creates a separate HomeKit accessory for each light connected to the Hue bridge, with a single HomeKit LightBulb service per accessory.

In my continuous struggle to workaround the HomeKit limitation of 99 accessories per HomeKit bridge (per homebridge instance), I'm playing with the thought to have homebridge-hue create a single accessory per room (as configured in the Hue bridge), with multiple Lightbulb services: one per light. I would use a config.json parameter to turn on this behaviour.

I'd love to hear your thoughts on this.

I have 4 different wake up routines in the hue app. But in the home app spear 12 switches for them. (Same in the eve app) 4 have the routine names and the other 8 appear in doubles with names like L_04_NwhyN and L_04_NwhyN_Start. The ones with Start in the ending have the status "on" and all the others are off.
Is this normal? Is there an option to have just one switch per wakeup routine?

First of all, thank you for this plugin, it makes the Hue bridge truly HomeKit compatible. I have a few minor issues/suggestions though.

I only own two Hue bulbs that were included in my starter kit, the rest are Lightify devices as they just seemed more reasonable, first regarding the price and second the functionality - I don't need RGB lights in all of my rooms (I know, Philips makes them as well, but they're still twice as expensive).
Anyways…

The classic white bulbs work without any issues at all. I have three PAR16 spots that, after an update, are working fine, but don't seem to be recognised by home kit as color temperature enabled.
The third one is an LED strip that does work, better after updating, but I have it in a couple of scenes and every now and then (not always though) I get the error

[Hue] Philips hue: hue bridge error 201: parameter, bri, is not modifiable. Device is set to off.

Sometimes it doesn't turn on at all, sometimes it does but doesn't apply color changes (there's a second error message that I wasn't able to recreate right now)

And the fourth type of device is the Lightify plug. It only shows the on/off state as it's not dimmable, but I find it highly confusing that it shows up as a light bulb. A couple of other plugins I have installed, mainly switches, allow me to modify the type - whether it's a light bulb, fan or switch.

I know that a symbol for plugs exists as the Elgato one doesn't show up as a bulb, is there a way you can allow the symbol for the switch to be modified in a future update?

I don't know how I can provide any help with a better support for the spot lights or the LED strip, but if there's anything I can do I'd be glad to.

Folks, I would like your thoughts on using homebridge-hue to overcome the issue of the Hue light power-on defaults.
Note: by "power on" or "power off" I mean connecting/disconnecting a light to/from the mains power, e.g. by using a traditional wall switch (so 20th century ;-).

Issue
When powered on, most lights, notably the Philips Hue bulbs and spots, turn on using some unholy power-on defaults for brightness and colour, instead of using the previous light state (like when turning a light on through the Hue bridge). This is a nuisance when powering the lights on using a wall switch, but becomes plainly obnoxious when mains power is restored after an outage. Of course, Murphy will make sure this happens in the middle of the night or when you're away for a couple of days.
Even though this issue is by far the largest topic on the Hue developer's forum, it doesn't look like Philips will be changing this behaviour.

For each Zigbee device (lights but also switches and motion sensors), the Hue bridge keeps track whether that device is reachable. When the Zigbee communication to that device is interrupted, e.g. when a light is powered-off, the Hue bridge sets the reachable state attribute to false. When the communication is restored (after the light is powered-on), the Hue bridge sets reachable to true. Note that it typically takes some (several seconds up to a minute?) time for the bridge to update reachable after a light is powered off or on.

Possible Solution - scenario 1
Most of the workarounds suggested in the Hue developer's forum involve a programme monitoring the light state for the unholy power-on default state, overwriting it with some preferred state. As homebridge-hue already monitors the light states, this functionality could be added to it.

When a light state changes to its power-on defaults, homebridge-hue could (re-)apply the previous light state from HomeKit to the Hue bridge, rather than propagating the Hue bridge change to HomeKit. When combined with issue #40, one could even change the desired power-on state while the light is powered off. This would work for unholy power-on defaults, that will never be set from any Hue app. Alternatively, homebridge-hue would only do it when reachable was false, but then it might miss a brief power outage, where the bridge would not change reachable.

The main limitation of this approach is the time lag between powering on the light and the Hue bridge re-establishing communication with the light and updating the light state.

Possible Solution - scenario 2
I actually have a "heartbeat" timer schedule and a number of rules on my Hue bridge, that boldly recall a "heartbeat" scene with the desired light states every 5 seconds. Not only does this overwrite any unholy power-on details within 5 seconds, it also undoes any pranks my kids are playing with the light colours. For any legit change, I suspend this heartbeat (1), do the change (2), update the heartbeat scene (3), and resume the heartbeat (4), all from Hue bridge rules. When we want to play with the light colours, I simply disable the heartbeat timer schedule (from HomeKit as homebridge-hue can expose schedules).

The main limitation of this scheme is that all legit changes have to go through Hue bridge rules (so they can suspend the heartbeat). This is not as bad as it sounds in my case, where these changes are triggered by Hue motions sensors, Hue dimmer switches, or through virtual switches (CLIPGenericFlag sensors). Each of these sensors fires a rule on the bridge for (2) anyways. I use a CLIPGenericFlag sensor to suspend the heartbeat, so I only need to add a single action for (1) to each of these rules setting this flag; (3) and (4) are triggered automatically a fixed time after this flag has been set. I had some challenges with the timing of updating the scene, especially for changes with longer transition times (typically when dimming the lights using the Hue dimmer switch), but it's working quite to my satisfaction.

homebridge-hue could implement a similar scheme: applying a heartbeat Hue bridge scene on every heartbeat. When any change would be made from HomeKit, homebridge-hue would suspend the heartbeat (1), propagate the change to the Hue bridge (2), update the Hue bridge heartbeat scene (3), and re-enable the heartbeat (4). Effectively, this would treat any change from HomeKit as legit, and overwrite any other change, including those from Hue bridge rules for motion sensors and dimmer switches. So these changes would need to be enacted through HomeKit rules instead. Alternatively, homebridge-hue would use a CLIPGenericFlag sensor to suspend the heartbeat, so bridge rules can make legit changes just as with the heartbeat implemented on the Hue bridge.

Help wanted
I like to hear your thoughts on this. Would either scenario work in your setup? Do you interact with your lights exclusively from HomeKit? Using Hue switches and motion sensors? From Hue apps?

Is the original hue bridge supported?

I'm attempting to connect multiple bridges using Homebridge-hue. One is an HA-Bridge
https://github.com/bwssytems/ha-bridge
This emulates a hue bridge and exposes among other things harmony hub activities to homekit as "lights".
The other bridge is a real hue bridge 2.0.

The problem is that HA-Bridge does not identify itself to the meethue portal. This means i need to specify the host parameter. But since i have two bridges i'd then need to specify two hosts.
This would avoid the need for a second instance of homebridge to be used.
I'm sure that perhaps others with multiple real bridges might find it useful to just specify the host ip's as well.

Is it possible to create a trigger NobodyHome besides the AnybodyHome? The automation part of HomeKit can only be triggered by a value true. AnybodyHome won't trigger an automation if its false.

On my Hue bridge I have two motion sensors, one Tap switch and one Dimmer switch. I have enabled the sensors in homebridge-hue and when homebridge starts up I see the following:

[12/6/2016, 3:33:12 PM] [Hue] Initializing platform accessory 'Philips hue'...
[12/6/2016, 3:33:12 PM] [Hue] Initializing platform accessory 'Daylight'...
[12/6/2016, 3:33:12 PM] [Hue] Initializing platform accessory 'Downstairs tap'...
[12/6/2016, 3:33:12 PM] [Hue] Initializing platform accessory 'Go to sleep'...

I can see that the Tap appears as does one of the motion sensors but there's no sign of the second motion sensor or Dimmer switch (I believe that "Go to sleep" is a currently inactive routine I have set-up)

I have been having my first play at replacing actions for Hue Tap and Dimmer switches, from being setup in the Hue Bridge (setup in iConnectHue) to using automation rules in HomeKIT.

The switches are not recognised by Apple's Home.app but are visible in Eve and Home (by Hochgatterer) which is where I tried this.

I created two scenes (specific lights ON & OFF) activated by two triggers (specific switch ON & OFF).
e.g. a Hue Tap's triggers were Programmable Switch Output State → 1 for ON and Programmable Switch Output State → 3 for OFF. (1 & 4 for the Dimmer)

The two scenes function normally.
The two triggers very seldom work, i.e. they are not actually triggered.

I can see the value changing in homebridge logs, eg.

[11/16/2016, 8:59:01 PM] [Hue] Living Room Dimmer: set homekit output state from 1 to 4 on Wed Nov 16 2016 20:59:00

Only once or twice in testing did I see the logs of the scene running as a result of the trigger. The trigger typically saying it had never been triggered.

Should I be able to do this?
Is there anything I can do to help you debug this?

Currently, homebridge-hue retrieves the full bridge state, GET /, on each heartbeat. As this state doesn't include /groups/0, group 0 is currently not supported. Also, it might be more efficient to issue multiple requests, one for each resource type: GET /lights, GET /groups, GET /sensors, and GET /schedules, especially when you have a lot of rules. Of course, these requests would only be issued when the corresponding resource type is enabled through config.json.

I intended HueSchedule.js to also support enabling or disabling bridge rules, as well as tracking lasttriggered (like lastupdated for sensors). However, with the homekit limitation of 100 accessories per bridge I don't see much use for this now.

Issue
Currently, homebridge-hue reports Hue bridge (communication) errors like:

[1/13/2017, 12:00:48 PM] [Hue] <bridge name>: hue bridge communication error ETIMEDOUT
[1/13/2017, 12:06:25 PM] [Hue] <bridge name>: hue bridge error 201: parameter, bri, is not modifiable. Device is set to off.

The error message shows which bridge reported the error but gives no clue as to which bridge request failed.

When homebridge is started in debug mode through homebridge -D, homebridge-hue issues a debug message for each bridge request it makes. However, homebridge-hue issues these requests asynchronously, so it (or other homebridge plugins) can continue to do other stuff, instead of blocking while waiting for the response. In particular homebridge-hue could issue another bridge request, before the response (or error) of an earlier bridge request comes in. Consequently, the error message in the output might not related to the latest request, especially when the error is timeout related.

Solution

• homebridge-hue should log the request when logging a bridge (communication) error.
• When in debug mode, homebridge-hue should also log successful responses for each request, so response times can be derived from the debug output.

Note that in debug mode, each request would generate two log messages: one message when issuing the request and one when receiving the response or error. In normal mode, only requests that return an error would be logged.

Currently, homebridge-hue requires the Hue bridge username to be created manually.

I've noticed a few times now that when I restart my RPi, it wipes out all of the settings in the Home app. For example, all devices get reset back to "Default Room", scenes are deleted, automations are disabled, groupings of devices are ungrouped, and names of devices have been reset (e.g. Philips Hue Motion Sensor/Ambient List/Temperature).

I am running Homebridge on a Raspberry Pi 2 B+ and I have the 1st Generation Hue Hub. This is my config file:

{
	"bridge": {
		"name": "Homebridge",
		"username": "<<REDACTED>>",
		"port": <<REDACTED>>,
		"pin": "<<REDACTED>>"
	},

	"description": "Description - not very helpful...",

	"platforms": [
		{
			"platform": "Hue",
			"name": "Hue",
			"host": "<<REDACTED>>",
			"users": {
				"<<REDACTED>>": "<<REDACTED>>"
			},
			"heartrate": 5,
			"timeout": 5,
			"lights": true,
			"alllights": true,
			"groups": false,
			"sensors": true,
			"schedules": false,
			"rules": false
		}
	],
	
	"accessories": [
		{
			"accessory": "WUNDERGROUND",
			"name": "Weather Conditions",
			"device": "Raspberry Pi",
			"key": "<<REDACTED>>",
			"city": "<<REDACTED>>"
		},
		{
			"accessory": "people",
			"name": "People",
			"people": [
				{"name": "<<REDACTED>>", "target": "<<REDACTED>>"},
				{"name": "<<REDACTED>>", "target": "<<REDACTED>>"}
			],
			"threshold": 15
		},
		{
			"accessory": "HttpTemphum",
			"name": "Living Room Conditions",
			"url": "<<REDACTED>>",
			"sendimmediately": "",
			"http_method": "GET"
		}
	]
}

I have some Osram Gardenspot RGB lights, which currently seem to be unreachable. Every heartbeat I get the following entries in the console log:

[1/18/2017, 6:19:18 PM] [Hue] Wonderland Perimiter: set homekit hue from NaN˚ to NaN˚ [1/18/2017, 6:19:18 PM] [Hue] Wonderland Perimiter: homekit hue changed from NaN˚ to NaN˚ [1/18/2017, 6:19:18 PM] [Hue] Wonderland Perimiter: set homekit saturation from NaN% to NaN% [1/18/2017, 6:19:18 PM] [Hue] Wonderland Perimiter: homekit saturation changed from NaN% to NaN% [1/18/2017, 6:19:18 PM] [Hue] Philips hue: hue bridge request #1225: put /lights/25/state {"xy":[null,null]} [1/18/2017, 6:19:18 PM] [Hue] Philips hue: hue bridge error 7: invalid value, [null,, for parameter, xy [1/18/2017, 6:19:18 PM] [Hue] Philips hue: hue bridge request #1226: put /lights/25/state {"xy":[null,null]} [1/18/2017, 6:19:18 PM] [Hue] Philips hue: hue bridge error 7: invalid value, [null,, for parameter, xy

It seems to be firing off two requests to the Hue bridge and spamming the log with errors. The Hue bridge returns this status for the light when queried manually.

"25":{"state":{"on":true,"bri":254,"hue":0,"sat":0,"effect":"none","xy":[0.0000,0.0000],"alert":"none","colormode":"hs","reachable":false},"type":"Color light","name":"Wonderland Perimiter","modelid":"Gardenspot RGB","manufacturername":"OSRAM","uniqueid":"84:18:26:00:00:08:d6:0c-03","swversion":"V1.03.20"}

Currently, homebridge-hue only discovers hue bridges using nupnp, i.e. by querying the Meethue portal. Alternatively, the bridge IP address (or DNS name) can be specified in config.json.

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?

I currently have all my hue lights set up with Homekit, since they are supported out of the box.

I want to use Hue Motion Sensors, but haven't purchased because they don't work with HomeKit. I know there are other sensors available, but I'd prefer Hue ones.. I'd like to set it up to create scenes/rules using the Hue sensor. Example, detect motion with the hue sensor, set lights to X, set Nest to X.

Can I use this plugin, to ignore all the lights, but ONLY support the Motion Sensor? I don't want any duplicate lights, etc, showing up via siri, home app, etc.

Hoi Erik,

Installed the homebridge-hue plugin, ran it for a first time, pressed the button on my bridge, entered the info from he logging into the config.json file, started homebridge again and.. nothing :)

Well, what happens is that in the Home app (and also in Eve), there is a new 'Philips hue' accessory, but the Home app says it's not supported. See screenshot below. Checked with Eve, see the same accessory but cannot do anything with it, not even change it to another room. config.json & logging output also included below.

I must say that I have the Hue bridge itself connected directly to the Homekit already, only reason for me to include the plugin was for the Dimmer and Tap switch, as I can then include more actions than only hue updating hue lamps when these are used.

As I kept all additional parameters out of the config.json file, my expectation was that only these switches (and maybe other switches/sensors, except for the light bulbs themselves) would appear. My idea was to have those switches do nothing (or as little as technically possible) within the Hue environment itself but take advantage of the exposure of the switches/sensors to HomeKit to either use their characteristics as Triggers or Conditions.

Your thoughts & feedback are highly appreciated.

Met vriendelijke groet vanuit California.
Jurgen

config.json
{
"platform": "Hue",
"name": "Hue",
"users": {
"0XXXXXXXXX6": "AXXXXXXXXXXXXXXB"
}
}

Logging:
[1/1/2017, 11:50:14 PM] [Hue] Philips hue: hue bridge request: get /
[1/1/2017, 11:50:19 PM] [Hue] Philips hue: hue bridge request: get /
[1/1/2017, 11:50:24 PM] [Hue] Philips hue: hue bridge request: get /
[1/1/2017, 11:50:29 PM] [Hue] Philips hue: hue bridge request: get /
[1/1/2017, 11:50:34 PM] [Hue] Philips hue: hue bridge request: get /
Etc.. goes on like that