The notifications posted by the PHNotificationManager are confusing when looking at the code completion.

Example:
"UIApplicationDidBecomeActiveNotification" tells you directly which class or SDK it is from, what type it is and when it is posted.
When you see "LOCAL_CONNECTION_NOTIFICATION" in your auto completion you don't know they're posted by the Hue SDK.
A better naming would be "PHBridgeConnectionEstablishedNotification"

When I change the groupsettings with

• createGroupWithName:lightIds:completionHandler: or
• updateGroupWithGroup:completionHandler:

I have to restart the bridge (By unplugging the powerconnection) to make my changes take effect. Changes in this case are creating and removing groups and adding are removing lights to a group.

Example:
I have a group with Light 1 and 2 and i can set the group state like On/Off that works fine.

Now I change the group:
group.lightIdentifiers = [NSArray arrayWithObjects:@"1",@"2",@"3", nil];

And Update the bridge:
[bridgeSendAPI updateGroupWithGroup:group completionHandler:^(NSArray *errors) ...

The bridge is updated correctly, Light 3 was added to the Lights Array.
I can see that by calling:
http://192.168.2.110/api/2beb86671081cadfa6d605712c826cf/groups/3/

When I send On/Off statechanges to this group only Light 1 and 2 are controlled.
After I restart the bridge by unplugging the powerconnection Light 3 is controlled too.

Following the usual conventions, the header file to import should have the name HueSDK.h

Since a while I have a huge issue. Every time I use a ramp, most of time to dim or dim to off, the lamp start dimming and suddenly reset. Then the lamp is at the default state. Most of the time there, it's reachable and working then, but sometimes it should be off already.

Currently, versions of your SDK > 1.0 use Cocoa Lumberjack for logging. While this may be useful within your department, developers not employed by Philips do not get much use out of this, because your framework is closed source.

Please either make Cocoa Lumberjack an optional dependency (preferred), or provide options to disable the console output.

Just a clarification: I'm working on a Cydia tweak, and Lumberjack cannot be included. For others, this may simply be a minor annoyance.

As the API is capable of doing xyY<->UIColor conversions it must be aware of the light's primary tristimulus values.

It would be nice to be able to query them.

I implemented PushLinking very similar to the sample App:

To start PushLinking it instantiate a controller from my Storyboard with
[self presentViewController:pushLinkAuthentificationNavigationViewController animated:YES completion:NO];

The controller itself work's as the one in the sample App displaying a progress bar. When I do not push the button within the 30 seconds, the authenticationFailed routine get's called

- (void)authenticationFailed {
    // Deregister for all notifications
    [[PHNotificationManager defaultManager] deregisterObjectForAllNotifications:self];

    // Inform delegate
    [_delegate pushlinkFailed:[PHError errorWithDomain:SDK_ERROR_DOMAIN code:PUSHLINK_TIME_LIMIT_REACHED userInfo:[NSDictionary dictionaryWithObject:@"Authentication failed: time limit reached." forKey:NSLocalizedDescriptionKey]]];
}

which itself calls succesfully the pushlinkFailed function on the delegate

- (void)pushlinkFailed:(PHError *)error {
    // remove push link view controller
    [self dismissViewControllerAnimated:YES completion:NO];
}

At that moment the app crashes with

2013-03-31 19:13:47.484 Hue Controller[3941:c07] -[PHCompleteBridgeParser1 noLocalConnectionNotificationReceiver]: unrecognized selector sent to instance 0x761a8f0
2013-03-31 19:13:47.484 Hue Controller[3941:c07] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[PHCompleteBridgeParser1 noLocalConnectionNotificationReceiver]: unrecognized selector sent to instance 0x761a8f0'

where the class PHCompleteBridgeParser1 is random.

This even happens when I never register any notification handler for NO_LOCAL_CONNECTION_NOTIFICATION in any class. The only thing that works is not to dismiss the ViewController. But when I write a small test-function for the NO_LOCAL_CONNECTION_NOTIFICATION within that class, it never get's called.

I don't understand what's going wrong here. Any hints appreciated.

Currently, your SDK for iOS is only compiled for i386, armv7, and armv7s.
It is not compiled for arm64.
This recompilation would not take long, and would allow native 64 bit apps and tweaks to use Hue's framework.
It would also allow Cydia tweaks to utilize the framework on 64-bit devices, something I am trying to accomplish.

The ZLL standard mentions fields for minimum and maximum supported color temperatures.

Would be nice to get them if the lamp supports color temperatures.

updateLightStateForId:withLighState:completionHandler: and setLightStateForGroupWithId:lightState:completionHandler: crash if the completionHandler is set to nil.

Provide a method to cancel a running bridge search.

Creating a brand new application and then adding the framework to my project with these lines to init the sdk fails to link. Am I doing something wrong or is this an issue?

Source added to ViewController.m:

#import <HueSDK_iOS/HueSDK.h>
PHHueSDK *hueSDK = [[PHHueSDK alloc] init];
[hueSDK startUpSDK];

Link Failure:

Ld /Users/codemonkey/Library/Developer/Xcode/DerivedData/HueTestApp-augdwxfcjtsfudenbnnvwtytgknq/Build/Products/Debug-iphonesimulator/HueTestApp.app/HueTestApp normal i386
cd /Users/codemonkey/Desktop/HueTestApp
setenv IPHONEOS_DEPLOYMENT_TARGET 7.0
setenv PATH "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/Users/codemonkey/.rvm/gems/ruby-2.0.0-p247/bin:/Users/codemonkey/.rvm/gems/ruby-2.0.0-p247@global/bin:/Users/codemonkey/.rvm/rubies/ruby-2.0.0-p247/bin:/Users/codemonkey/.rvm/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Users/jalal/Code/Scripts"
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk -L/Users/codemonkey/Library/Developer/Xcode/DerivedData/HueTestApp-augdwxfcjtsfudenbnnvwtytgknq/Build/Products/Debug-iphonesimulator -F/Users/codemonkey/Library/Developer/Xcode/DerivedData/HueTestApp-augdwxfcjtsfudenbnnvwtytgknq/Build/Products/Debug-iphonesimulator -F/Users/codemonkey/Desktop/HueTestApp -filelist /Users/codemonkey/Library/Developer/Xcode/DerivedData/HueTestApp-augdwxfcjtsfudenbnnvwtytgknq/Build/Intermediates/HueTestApp.build/Debug-iphonesimulator/HueTestApp.build/Objects-normal/i386/HueTestApp.LinkFileList -Xlinker -objc_abi_version -Xlinker 2 -ObjC -fobjc-arc -fobjc-link-runtime -Xlinker -no_implicit_dylibs -mios-simulator-version-min=7.0 -framework CoreGraphics -framework UIKit -framework HueSDK_iOS -framework Foundation -Xlinker -dependency_info -Xlinker /Users/codemonkey/Library/Developer/Xcode/DerivedData/HueTestApp-augdwxfcjtsfudenbnnvwtytgknq/Build/Intermediates/HueTestApp.build/Debug-iphonesimulator/HueTestApp.build/Objects-normal/i386/HueTestApp_dependency_info.dat -o /Users/codemonkey/Library/Developer/Xcode/DerivedData/HueTestApp-augdwxfcjtsfudenbnnvwtytgknq/Build/Products/Debug-iphonesimulator/HueTestApp.app/HueTestApp

Undefined symbols for architecture i386:
"OBJC_CLASS$_DDLog", referenced from:
objc-class-ref in HueSDK_iOS(PHHueSDK.o)
objc-class-ref in HueSDK_iOS(PHBridgeSearching.o)
objc-class-ref in HueSDK_iOS(PHCLIPWrapper2.o)
objc-class-ref in HueSDK_iOS(PHHeartbeatProcessingLocal.o)
objc-class-ref in HueSDK_iOS(PHHttpRequester.o)
objc-class-ref in HueSDK_iOS(PHAuthentication.o)
objc-class-ref in HueSDK_iOS(PHBridgeResourcesWriter.o)
...
"OBJC_CLASS$_DDTTYLogger", referenced from:
objc-class-ref in HueSDK_iOS(PHHueSDK.o)
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)

On my iPhone 5s. I get the PUSHLINK_LOCAL_AUTHENTICATION_FAILED_NOTIFICATION called immediately. It doesn't even wait for 1 second, let alone 30. The code that calls that notification is in the HueSDK.framework so I can't see what is causing it.

The stack trace has a postApiWithDeviceType:andUsername:completionHandler:

I couldn't get it to work on this device with the Philips Hue app, the Goldee app, or this SDK. All of my other devices work fine.

It would be nice to add 'ordering' field to the lights/groups so that we have a reproducible way to order the list on different devices. This could be simple integer value.

Will there (is there) a Cocoapod for the core of this Application? Would be a great way to stay up to date with the code provided by philips. Thx!

On PHBridgeSearching.m line 114
-[PHBridgeSearching addBridgeToResultsWithIp:andMac:]

CoreFoundation
-[__NSDictionaryM setObject:forKey:] + 818

Fatal Exception: NSInvalidArgumentException
*** setObjectForKey: key cannot be nil

I got the following stacktrace from a user:

Thread : Fatal Exception: NSInvalidArgumentException
0  CoreFoundation                 0x31289f4b __exceptionPreprocess + 130
1  libobjc.A.dylib                0x3b6ca6af objc_exception_throw + 38
2  CoreFoundation                 0x311c5667 -[__NSDictionaryM setObject:forKey:] + 818
3  App                            0x0011b8d5 -[PHBridgeSearching addBridgeToResultsWithIp:andMac:] (PHBridgeSearching.m:114)
4  App                            0x0011beef __57-[PHBridgeSearching getIPScanOperationForAdress:andPath:]_block_invoke (PHBridgeSearching.m:169)
5  Foundation                     0x31bc862f -[NSBlockOperation main] + 130
6  Foundation                     0x31bb87db -[__NSOperationInternal _start:] + 770
7  Foundation                     0x31c5c995 __NSOQSchedule_f + 60
8  libdispatch.dylib              0x3bbb368f _dispatch_async_redirect_invoke$VARIANT$mp + 110
9  libdispatch.dylib              0x3bbb4d71 _dispatch_root_queue_drain + 220
10 libdispatch.dylib              0x3bbb4f59 _dispatch_worker_thread2 + 56
11 libsystem_pthread.dylib        0x3bcefdbf _pthread_wqthread + 298
12 libsystem_pthread.dylib        0x3bcefc84 start_wqthread + 8

I think this happens in the startSearchWithCompletionHandler routine of PHBridgeSearching.
The MAC and/or IP address are probably not nil-checked?

The Lights API specifies a range of 0-255 for brightness and saturation. The comments in the PHLightState.h header file only allow 254 as a maximum value.

PHLight.reachable always returns false.

//example code
PHBridgeResourcesCache *cache = [PHBridgeResourcesReader readBridgeResourcesCache];

for (PHLight *light in cache.lights.allValues) {

    if (light.reachable) {
        NSLog(@"REACHABLE: %@ (%@)", light.name, light.identifier);
    } else {
        NSLog(@"UNREACHABLE: %@ (%@)", light.name, light.identifier);
    }

If I switch on or off the power supply of lights the reachable flags do not trigger LIGHTS_CACHE_UPDATED_NOTIFICATION. If I check directly on the bridge through the debug/clip.html interface the bridge already knows the correct state.

Add support for TouchLinking (like the Lampstealer App)

I'm trying to send a command to the lights to create a schedule for it to turn on at a date and time. However, it keeps crashing every time I do bridgeSendAPI's createSchedule:completionHandler. I double check and know that the date I set is in the correct format (2013-05-06T03:55:37) and not nil in the schedule object that I'm sending. Please help.

This is what printed out:
Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** setObjectForKey: object cannot be nil (key: time)'

The SDK generates invalid parameter value if recurringDays is set to anything other than RecurringNone.

Easily reproducible with the SampleApp. Under [PHScheduleAddingViewController addButton:], add a line schedule.recurringDays = RecurringMonday;

This is the payload generated:

{
  "name" : "",
  "time" : "W64\/T18:49:42",
  "description" : "Test schedule",
  "command" : {
    "method" : "PUT",
    "address" : "\/api\/upRpraPygY53zvgP\/groups\/0\/action",
    "body" : {
      "alert" : "lselect"
    }
  }
}

which results in

[{
    "error": {
        "type": 7,
        "address": "/schedules/time",
        "description": "invalid value, W64\/T18:49:42, for parameter, time"
    }
}]

If I manually remove the extra \ from time, the following curl works:

{
  "name" : "",
  "time" : "W64/T18:49:42",
  "description" : "Test schedule",
  "command" : {
    "method" : "PUT",
    "address" : "\/api\/upRpraPygY53zvgP\/groups\/0\/action",
    "body" : {
      "alert" : "lselect"
    }
  }
}

Please supply the contents of /api/XXX/config/whitelist in PHBridgeConfiguration

When lights are dimmed with a bigger ramp than 60s, lights suddenly turns off around 55s.
It dims correctly until suddenly it shuts itself off.

Because the source is closed, it is hard to say what causes this exception, however it is probably memory related.
It looks like that in AsyncUdpSocket doReceive and doReceiveTimeout something is accessed that is not allocated (or is deallocated).

I got two different stacktraces.

• [PHBridgeSearching startPortalSearch] PHBridgeSearching.m line 347
• [AsyncUdpSocket doReceive:] AsyncUdpSocket.m line 2167

Crashed: com.apple.main-thread
EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x0000001b

0  libobjc.A.dylib                0x39b6eac2 cache_getImp + 1
1  libobjc.A.dylib                0x39b76745 lookUpImpOrForward + 32
2  libobjc.A.dylib                0x39b7670b lookUpImpOrNil + 18
3  libobjc.A.dylib                0x39b6fc89 class_respondsToSelector + 36
4  CoreFoundation                 0x2f4a419f ___forwarding___ + 662
5  CoreFoundation                 0x2f3f34d8 _CF_forwarding_prep_0 + 24
6  App                            0x0010ace7 -[PHBridgeSearching startPortalSearch] (PHBridgeSearching.m:347)
7  App                            0x001071f5 -[AsyncUdpSocket failCurrentReceive:] (AsyncUdpSocket.m:2224)
8  App                            0x001072cf -[AsyncUdpSocket doReceiveTimeout:] (AsyncUdpSocket.m:2245)
9  Foundation                     0x2fe86d2d __NSFireTimer + 64
10 CoreFoundation                 0x2f46d0df __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 14
11 CoreFoundation                 0x2f46ccf7 __CFRunLoopDoTimer + 782
12 CoreFoundation                 0x2f46b093 __CFRunLoopRun + 1210
13 CoreFoundation                 0x2f3d5c27 CFRunLoopRunSpecific + 522
14 CoreFoundation                 0x2f3d5a0b CFRunLoopRunInMode + 106
15 GraphicsServices               0x340a9283 GSEventRunModal + 138
16 UIKit                          0x31c79049 UIApplicationMain + 1136
17 App                            0x00101017 main (main.m:16)

and

Crashed: com.apple.main-thread
EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x5000000c

Thread : Crashed: com.apple.main-thread
0  libobjc.A.dylib                0x3897db66 objc_msgSend + 5
1  App                            0x000f4043 -[AsyncUdpSocket doReceive:] (AsyncUdpSocket.m:2167)
2  App                            0x000f4359 -[AsyncUdpSocket doCFSocketCallback:forSocket:withAddress:withData:] (AsyncUdpSocket.m:2268)
3  App                            0x000f00db MyCFSocketCallback (AsyncUdpSocket.m:2292)
4  CoreFoundation                 0x2e5f30fd __CFSocketPerformV0 + 580
5  CoreFoundation                 0x2e5f0f1f __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 14
6  CoreFoundation                 0x2e5f046d __CFRunLoopDoSources0 + 340
7  CoreFoundation                 0x2e5eebd7 __CFRunLoopRun + 630
8  CoreFoundation                 0x2e559471 CFRunLoopRunSpecific + 524
9  CoreFoundation                 0x2e559253 CFRunLoopRunInMode + 106
10 GraphicsServices               0x332932eb GSEventRunModal + 138
11 UIKit                          0x30e0e845 UIApplicationMain + 1136
12 App                            0x000edfef main (main.m:16)

Would be nice to support the NSCopying for PHLight, PHLightState, etc.

If you have found any bugs in the SDK or have feature requests or suggestions for changes. Please add them here

Hey Guys,
I have been using DPHue for a while now to do cocoa development for the HUE system. I would like to switch over to the official HueSDK framework however it depends on UIKit. Can you point me to a version of the framework which does not have iOS dependencies or to the framework source?

Using iOS-OSX-1.1.2beta SDK and SmartBridge firmware 01008227 results in a few unexpected Group behaviors:

1. No access to group's PHLightState from PHGroup object. I see that each group is returning distinct light attributes when querying via a curl command. Is each group supposed to have a dedicated PHLightState stored in the SmartBridge? The only keys returned from the getGroupAsDictionary call are lightidentifiers, name, and identifier.
2. The light state of a given group changes to unpredictable values. Should a group be retaining any light state at all or should the application keep track of brightness, hue, etc. Regardless of the colormode sent to the SmartBridge, querying it always returns "xy" colormode.
3. Creating a group with more than 25 lights causes large delays on the SmartBridge. In this case 22 lights get created quickly, but the rest get added very slowly or not at all. Trying to create a group with more than 40 lights consistently drops some of the lights.

PHLightState seems to use NSNumber for every single property, is is kinda confusing since you don't know what is holds it could be an int, float, double or boolean. A better way to do this is to use BOOL, int and float as properties. This makes accessing the property's much easier and keeps the lines short.

Also for booleans there is an naming convention where the getter of that property starts with "is". So [[[PHLight lightState] on] boolValue] would than be [[PHLight lightState] isOn].

PHError should have a property with the original JSON error data and/or already parsed attributes like address, type, description

The SDK framework uses JSONKit and other frameworks may use it as well or maybe the project uses a newer JSONKit version. Linking the framework in that case will hit "duplicate symbol error".

I think either JK (JSONKit) prefix is changed in the classes used in the framework or JSONKit dependency is moved outside de framework. In my case the other framework already including JSONKit is more important for the project and we will have to dump HUE support if we can't solve this problem

If you unplug my SmartBridge it still get's found using the http://www.meethue.com/api/nupnp method. So the API should check the results got from http://www.meethue.com/api/nupnp for reachability before reporting them as found bridges.

I still see the same issues as in Issue #33 with 1.1.2beta. If I have a reachable lamp and remove it's power I can see that is not reachable anymore about a minute later in the debug interface. The application does not get a LIGHTS_CACHE_UPDATED_NOTIFICATION about this.

In addition, the 'reachable' flag seems to be incorrect at the start of the SDK. I have a reachability flag of NO for all my lamps until I trigger an update.

PHLightState and some other classes use typdef enumerations for easier use, however the naming of these enumerations is hard to understand and don't use the cocoa/iOS naming convention of including the type.
Example:
One accessoryType of an UITableViewCell is "UITableViewCellAccessoryCheckmark"

For PHLightAlertMode this is "ALERT_UNKNOWN" but should be "PHLightAlertModeUnknown".

This makes using the SDK a lot easier and requires less switching to to documentation (which don't seem to state the enumerations at all)

As it is possible to read /api/test/config without a valid username to get the name and swversion of the SmartBridge the searchBridge function should also report these.

It would be nice the have the a shorter period for the heartbeat pulls of the cache.

Maybe it is even possible to have something like a push-mechanism, where the HTTP connection to the bridge stays open and it get's notified by the bridge if something changes.
I guess therefor something in the bridge firmware has to be changed, but it still might be a good idea :)

The SDK at the moment is a compiled framework put on Github. This makes not much sense since the purpose of Github is to see the code inside it. This way other use could help improve the SDK by forking it and modifying the code or maybe even sending a pull request to send there modified code back into the official SDK.

If you want to keep some parts of the API or SDK secret I would recommend releasing at least some code in gists (like UIColor to XY and XY to UIColor code), this way people can make there own SDK's for OS X, Android, Windows, Windows Phone and other platforms.

No matter what I passed to createSchedule:, I got a crash. I don't see address anywhere in the headers so I assume it's the SDK's private variable.

I'm using v1.1.2 beta

*** First throw call stack:
(
    0   CoreFoundation                      0x042c35e4 __exceptionPreprocess + 180
    1   libobjc.A.dylib                     0x03a6e8b6 objc_exception_throw + 44
    2   CoreFoundation                      0x0434d578 -[__NSDictionaryM setObject:forKey:] + 888
    3   Wink                                0x0027c368 -[PHBridgeSendAPI2 createSchedule:completionHandler:] + 682

Please write the changes which were sent to and acknoledge by the bridge directly into the BridgeResourcesCache and sent an update notification.

Because the groups API is not functioning yet we have to send 1 request per lamp to change the brightness for a whole group. When sending a lot of requests the bridge seems to give back an internal error. This can be fixed by having a 0.10 second delay between the request but this is not in the SDK and requires extra checks in your code. It would be easier if the SDK did the delay for us when sending the request or maybe even something better.

As the bridge seem to have some rate limiter (which we don't know), it would be nice to have an action queue we we can submit light change requests and the queue sends them as fast as possible to the bridge.

It could then merge light requests (e.g. an switch-on request and a seperate color change request) and also delete requests which are superseded by new ons (e.g. the first color-change request by a new color-change request).

I would expect that when I call disableLocalConnection the NO_LOCAL_CONNECTION_NOTIFICATION notification should get triggered, as we don't have a local connection anymore afterwards.

Provide a method to cancel PushLinking process

When I search for new bulbs and the connection gets lost, no notification is issued. The logs says more or less the same as when this happens during 'normal' operation.

2013-04-12 18:48:42.963 hueplus[6230:c07] HTTPConnection failed (code=0): The request timed out. http://192.168.23.29/api/2e9cdd977d832f5e25a293ee90200c81/lights/new
2013-04-12 18:48:43.962 hueplus[6230:c07] HTTPConnection failed (code=0): The request timed out. http://192.168.23.29/api/2e9cdd977d832f5e25a293ee90200c81/lights/new
2013-04-12 18:48:44.962 hueplus[6230:c07] HTTPConnection failed (code=0): The request timed out. http://192.168.23.29/api/2e9cdd977d832f5e25a293ee90200c81/lights/new
2013-04-12 18:48:45.961 hueplus[6230:c07] HTTPConnection failed (code=0): The request timed out. http://192.168.23.29/api/2e9cdd977d832f5e25a293ee90200c81/lights/new
2013-04-12 18:48:46.524 hueplus[6230:c07] HTTPConnection failed (code=0): The request timed out. http://192.168.23.29/api/2e9cdd977d832f5e25a293ee90200c81
2013-04-12 18:48:46.524 hueplus[6230:c07] Error occured while fetching full bridge: Error Domain=com.philips.hue.sdk Code=21 "The request timed out." UserInfo=0x758e450 {NSErrorFailingURLStringKey=http://192.168.23.29/api/2e9cdd977d832f5e25a293ee90200c81, NSErrorFailingURLKey=http://192.168.23.29/api/2e9cdd977d832f5e25a293ee90200c81, NSLocalizedDescription=The request timed out., NSUnderlyingError=0x7249ea0 "The request timed out."}

The PHHueSDK documentation mentions phHeartbeat and phAuthentication properties with the corresponding types.

But the documentation misses them, and there are also no Header Files defining them.

As Issue #4 was closed and refered to the application note, which only provides the xy values of primaries for original hue bulb, LivingColors Bloom, Aura, and Iris, please provide the values for the all the other bulbs of the family. In particular the GU 10 lamp, BR 30 lamp and the LightStrip

In PHAppDelegate.m line 264

self.bridgeSearch = [[PHBridgeSearching alloc] initWithUpnpSearch:YES andPortalSearch:YES];

Gives a deprecated warning

When there is a schedule in the Hue with a transition time, the transitionTime property of the PHLightState in the state property of the PHSchedule retrieved from the schedule in PHBridgeResourcesCache is always nil.
The JSON response from the Hue returns:

{
   "lights": ...,
   "groups": ...,
   "config": ...,
   "schedules":{
      "1":{
         "name":"Schedule name",
         "description":"",
         "command":{
            "address":"/api/<identifier>/lights/1/state",
            "body":{
               "bri":254,
               "transitiontime":3000,
               "on":true
            },
            "method":"PUT"
         },
         "time":"W060/T06:20:00",
         "created":"2014-01-19T11:57:00"
      },
   "scenes": ...
}

However, in that case:
PHBridgeResourcesCache *cache = [PHBridgeResourcesReader readBridgeResourcesCache];
cache.schedules[@"1"].state.transitionTime is nil, while it should be 3000 (NSNumber)

In PHLightState.h there are 3 enums defined (PHLightColormode, PHLightAlertMode, PHLightEffectMode) but the corresponding properties don't use them.

Also it might be an idea to use the native types defined by the Lights API for the other properties instead of putting them into NSNumber objects.