sqmk / phue Goto Github PK

Add getBridge and getLights on the Client for convenience.

Link to the read me on gitapidoc.

It is possible to get a list of bridges on your network by requesting http://www.meethue.com/api/nupnp

The bridge apparently phones home. Making a request to the API takes the client's IP to look up bridges coming from the same address.

The SetLightAlert command can be changed into SetLightState, which will allow changing more than just the light's alert mode.

Per the Hue developer API, the 'effects' attribute actually does something. This attribute accepts either 'none' or 'colorloop'.

Create setAlert method on Light object that will fire SetLightAlert command.

Light objects should now accept Client as argument in constructor to run commands. Light objects really should only be generated by commands, as there is no need to build them manually.

Create unit test for this as well.

Missing an error code for full light group table.

Per the Hue documentation, it is possible to modify schedules. This didn't work before when I tried, but perhaps that may be because I was doing something wrong via the API.

Currently, one API call is made per attribute change on a light. Allow changing attributes on a light, then saving those attributes in one API call.

Switch path and method parameters in sendRequest, and rely on constants for method types. Default method type to get.

Update all commands to work with the updates.

Continue developing of library to the point where we can authenticate with the bridge.

Some tags are no longer necessary for DocBlocks. This includes @Package and @subpackage tags, and @return if void.

Home page should be sqmk/Phue, and not sqmk/phue.

Add in the ability to set the name of the Light from itself. Also, add a command to support it.

Start documenting client usage.

More unit tests are needed. Continue to update for PSR2. Address comment fixes if needed. Whitespace changes as well.

Any commands that are schedulable should implement interface to allow passing in command objects to the scheduler commands.

Numerous tests are missing. Try to get as close to 100% coverage as possible.

Build a command to pull and return a list (array) of light objects.

Check autoloader path as repo and as composer dependency.

Add comment header to all libraries and tests.

Ensure classes also have comments.

To ensure PSR2 coding standards, include running it in travis builds across everything in /library/.

As ticket subject suggests, create basic directory structure for the project, initialize composer file, and other things.

Rename exceptions to match closely to that from the Hue documentation. There is also one more missing error code that is not included in the Phue client.

If the PHP environment does not have the cURL extension available, the HTTP transport call errors out.

The composer.json file should be updated to require or recommend this extension, and the transport class should check for the library's availability before it attempts the curl_init() call.

Some of the commands I created should be renamed to match more closely with whats available in the Hue documentation.

Brightness and color temp values should match acceptable values on the Philips Hue developer documentation.

Additional cleanup on the client before tagging.

Rather than include each alias/import in one bundle, separate by line to follow standards in major frameworks.

Add in more getters on Light to pull additional details, like bulb type, model, software version, etc.

When passing a time to CreateSchedule command, it should throw an exception for any values that can't be parsed.

Create new FindNewLights command, and build a script to ease finding lights via the bridge.

Per Hue documentation, it is possible to delete existing users. Create a new command to handle this, and possibly new convenience methods and objects to retrieve and delete users.

Phue/Transport/Http is currently not tested at all. Start refactoring so that tests can be written for it.

Also, there are more exceptions that can be built around the bridge's error codes.

Create command GetLightsById, that will accept an id and attempt to retrieve light from API. If light isn't found, should throw the proper resource exception.

It is possible to have a custom username via authentication. A hash isn't necessary.

Most PHP installations have curl included. Since this adapter can be used by nearly every PHP environment, AND is much faster than the streaming adapter, use it by default. Those who don't have curl installed will have to pass streaming adapter instance to the client to get it to work.

Phue\Light __toString should return the light's Id.

Commands that require a Light should accept now any value, and typecast to get Id. This is so that Lights do not have to be built from other commands prior to interacting with the light driven commands.

New commands are needed for managing groups:

• GetGroups
• GetGroupById
• CreateGroup
• DeleteGroup
• SetGroupConfig
• SetGroupAction

A \Phue\Group object might also be handy. Convenience methods to set it's name, lights, and single actions might be handy.

Also, create unit tests for all as well.

It was pointed out to me that tests for composer packages should be manually modifying the autoloader namespace/class map to point to tests, rather than clutter up the map in the composer file with that location.

Thanks @triplepoint.

Initialize the repo so we can start getting work done!

Experimenting with the bridge API, it appears that passing in an invalid username to config method will still yield the name of the bridge as well as software version.

Call "/none/config" for pinging the bridge.

There is a scheduling API available.

The list of commands are needed:

• CreateSchedule
• DeleteSchedule

A schedule object that is NOT updatable may be useful.

There are some other projects floating around that allow for changing lights from command line. Add such a script to this project.

Set up tests directory with phpunit config and initial Client test.

Set up CI with Travis.

This will require adding appropriate travis config, and status images in the readme.

Add PHPCS rules to ensure that comments are added for every class, function, and variable.