Jimmy Selgen Nielsen

4 minute read

When i last looked into automating the light control, i was using IFTTT, and decided to write my own implementation because IFTTT was not very precise, and rather limited for the finegrained control i wanted.

A year has passed, and there’s a new version of the Phillips Hue Bridge which supports Apple HomeKit, and has a new version of the Hue API, which supports things like sunrise/sunset triggers. My own solution has been running on my Raspberry Pi for the better part of a year, and has worked very well, but with the new API it is possible for me to create the schedules directly on the Hue Bridge, removing the dependency on the Server, and allowing interaction from the Hue Apps.

Setting up a trigger for sunset/sunrise is rather easy. Simply perform a POST request to /api/[username]/rules with “instructions” for what should happen.

The rule can operate on lights and groups. To find your groups (and define new ones), either use the app, or perform a GET request to /api/[username]/groups

Then POST something like this to /api/[username]/rules:

{
    "name": "Turn on outdoor lights",
    "conditions": [
        { 
            "address": "/sensors/1/state/daylight",
            "operator": "eq",
            "value": "false"
        }
    ],
    "actions": [    
        {
            "address": "/lights/4/state",
            "method": "PUT",
            "body": { "on":true, "bri":254, "sat":0, "transitiontime":36000 }
        },
        {
            "address": "/lights/5/state",
            "method": "PUT",
            "body": { "on":true, "bri":254, "sat":0, "transitiontime":36000 }
        },
         {
            "address": "/groups/7/action",
            "method": "PUT",
            "body": { "on":true, "bri":254, "sat":0, "transitiontime":36000 }
        }
    ]
}

The above rule turns on all my outdoor lamps, along with a few indoor lamps as well. Similarly, for turning lights off at sunset:

{
    "name": "Turn off lights at sunrise",
    "conditions": [
        { 
            "address": "/sensors/1/state/daylight",
            "operator": "eq",
            "value": "true"
        }
    ],
    "actions": [    
        {
            "address": "/groups/3/action",
            "method": "PUT",
            "body": { "on":false, "bri":0, "transitiontime":36000 }
        },
        {
            "address": "/groups/2/action",
            "method": "PUT",
            "body": { "on":false, "bri":0, "transitiontime":36000 }
        }
    ]
}

Keep in mind the syntax difference between groups and lights Lights has an address of “/lights/[id]/state” and Groups has an address of “/groups/[id]/action”

As for scheduling repeated events at a set time, i used the iOS Hue App. It is possible to do this thought the REST API as well, but the app seemed like a lot less “work”. I.e. for dimming the front door lights at midnight

{
	"name": "Dim Outdoor Lights",
	"command": {
		"address": "/api/[username]/groups/3/action",
		"method": "PUT",
		"body": {
	        "bri":150,
	        "transitiontime":36000 
		}
	},
	"localtime": "W127/T00:00:00"
}

I wrote a web interface for the original implementation, where i could keep track on statistics. These are now available from the Bridge itself, and when queuerying /api/[username]/rules you get a list of defined rules. Add your rule ID to the string, and get details for that rule only, i.e.

{
  "status": "enabled",
  "owner": "username",
  "recycle": false,
  "conditions": [
    {
      "address": "/sensors/1/state/daylight",
      "operator": "eq",
      "value": "false"
    }
  ],
  "lasttriggered": "none",
  "created": "2016-05-25T09:15:42",
  "timestriggered": 0,
  "name": "Turn on outdoor lights",
  "actions": [
    {
      "address": "/groups/3/action",
      "method": "PUT",
      "body": {
        "bri": 0,
        "transitiontime": 36000,
        "on": false
      }
    }
  ]
}

As you can see, i created this rule for this blog post, and it has yet to be triggered, but the timestriggered and lasttriggered keys update whenever the rule is run. These statistics reset whenever you reset your Bridge.

There are, of course, also downsides to using the Bridge.

My original solution had concepts for dusk/dawn along with sunset/sunrise. Hue has offsets for sunset/sunrise, but these are static, and defaults to +/- 30 minutes. Around here, Civil twilight doesn’t vary more than +/- 30 minutes, from 30 minutes before/after sunset/sunrise, to ~60 minutes (as opposed to nautical/astonomical twilight, which part of the year lasts all night around here) I would prefer Phillips to add calculations for civil dusk/dawn as well, but i’ve settled on using the built in times, along with a transitiontime setting of 30-60 minutes.

Also, Rules are nonexistant in the official Hue app, where the only use of sunrise/sunset is to trigger an action when you arrive home and it’s after sunset. Schedules are “transformed” into routines, which only gives a portion of the API’s power. I would prefer an advanced setting that would allow me to interact with the indiviual types, groups/lights/rules/schedules/scenes, and edit the raw data, or at the very least let me use sunrise/sunset as a time when creating a schedule.

Furthermore, in the new iOS app, Phillips has decided that a light cannot logically belong to two different groups, since they now insist on calling these groups “rooms”. You can configure this via the REST API, but if you make changes through the iOS app, it overwrites this, so the easy solution is to operate directly on the lights themselves, or simply create “rooms” for every light, and then add more rooms to the rules.

So, despite my love for writing my own stuff (and learning about it in the process), i have an even greater love for “stuff that just works”, a category that Hue now seems to fit into. I’ve removed my own implementation, and am now solely relying on the Bridge to perform it’s duties. I fear my Raspberry Pi may soon be out of work.

comments powered by Disqus