lifx / lifxkit Goto Github PK

Does this project include support for the firmware2.0 update? (no mesh)

It would be great to know what model of hardware we are dealing with, since I would like to adjust my brightness slider to accommodate the differences between the 1000 lumen bulb and the 600 lumen downlight. I use model information from Philips to determine a custom icon for the light list in my app, and it would be nice to do the same for LIFX. It looks like you call this "product code" on your spec sheet, and it looks like BUL-11-A21E26-W-EN or BUL-11-GU10-W-EN

When running "Analyze" in Xcode, it seems unhappy with LFXWiFiObserver's freshNetworkInfo.

Pods/LIFXKit/LIFXKit/Classes-Common/LXProtocolMessages.h:17:48: Auto property synthesis will not synthesize property 'payload'; it will be implemented by its superclass, use @dynamic to acknowledge intention

I had to go through my own code as well after upgrading, to fix a few cases of this issue. Basically, any time a subclass redeclares a property with a different type (a common pattern I used as well) you'll get a compiler warning now.

Hi when I use in my pods too CocoaAsyncSocket
Then I have problem with class with same name.

I was try refactoring but don't help me.

This is content of my Pod file:
source 'https://github.com/CocoaPods/Specs.git'
pod "XBChatModule"
pod 'LIFXKit'

This is my error:
....
Products/Debug-iphonesimulator/libPods-CocoaAsyncSocket.a(GCDAsyncUdpSocket.o)
/Users/jantimar/Library/Developer/Xcode/DerivedData/TEST_LIFX-cpzysiaiyvlqahetcsmbxdwnbrhv/Build/Products/Debug-iphonesimulator/libPods-LIFXKit.a(GCDAsyncUdpSocket.o)
duplicate symbol OBJC_CLASS$_GCDAsyncUdpSocket in:
/Users/jantimar/Library/Developer/Xcode/DerivedData/TEST_LIFX-cpzysiaiyvlqahetcsmbxdwnbrhv/Build/Products/Debug-iphonesimulator/libPods-CocoaAsyncSocket.a(GCDAsyncUdpSocket.o)
/Users/jantimar/Library/Developer/Xcode/DerivedData/TEST_LIFX-cpzysiaiyvlqahetcsmbxdwnbrhv/Build/Products/Debug-iphonesimulator/libPods-LIFXKit.a(GCDAsyncUdpSocket.o)
duplicate symbol OBJC_METACLASS$_GCDAsyncUdpSocket in:
/Users/jantimar/Library/Developer/Xcode/DerivedData/TEST_LIFX-cpzysiaiyvlqahetcsmbxdwnbrhv/Build/Products/Debug-iphonesimulator/libPods-CocoaAsyncSocket.a(GCDAsyncUdpSocket.o)
/Users/jantimar/Library/Developer/Xcode/DerivedData/TEST_LIFX-cpzysiaiyvlqahetcsmbxdwnbrhv/Build/Products/Debug-iphonesimulator/libPods-LIFXKit.a(GCDAsyncUdpSocket.o)
ld: 131 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Hi

I'm currently also trying to get a strobe effect and for that I tried different rates.
Changing the color every 0.2 sec looks good, but it's still a bit slow for me.
If I try a higher rate (e.g. 0.1 sec), then the bulb doesn't react at all or does get only a few commands.
Is there a way to get the best rate (maybe depending on the WiFi network) or is there a way to improve this rate?

Thank you for any inputs

Linard

Since Nick no longer works for LIFX (thanks for all the great work, Nick!) you should probably change the author field in the podspec

s.author       = { "Nick Forge" => "[email protected]" }

I'm seeing frequent logs reporting unknown message types 50, 53, 56, and 59, which don't have entries in LXProtocolTypes.h. I only have original LIFX bulbs on the network (no LIFX White 800 lights) so it must be something else that the bulbs are sending out that's new. Hopefully we'll get a LIFXKit update soon? It doesn't crash my app (at least in this case) but at times it really fills up the logs.

ERROR: unknown message type '50'. The appropriate class may need to be registered in +[LFXMessage messageWithMessageData:]

I noticed that in Objective-C you would do the following:

self.lifxNetworkContext = [LFXClient sharedClient].localNetworkContext;
[self.lifxNetworkContext addNetworkContextObserver:self];
[self.lifxNetworkContext.allLightsCollection addLightCollectionObserver:self];

I've tried to do the same using Swift, but client.addNetworkContextObserver() complains about the observer:

var localNetworkContext = LFXNetworkContext()
let client = LFXClient.sharedClient().localNetworkContext
client.addNetworkContextObserver(self)
client.allLightsCollection.addLightCollectionObserver(self)

Error:

Cannot invoke 'addNetworkContextObserver' with an argument list of type '(DeviceListViewController)'

If I print out client then I see:

<LFXLocalNetworkContext: 0x7f99fd49d850 (name = Local, isEnabled = Yes, connectionState = Not Connected)>

Then I tried the following only to notice that the lights don't turn on:

var localNetworkContext = LFXNetworkContext()
var client = LFXClient.sharedClient().localNetworkContext
client.allLightsCollection.setPowerState(LFXPowerState.On)

As far as I can tell there there is no API to refresh for more lights, it is just expected the API will continue to work.

I have noticed that in practice it loses lights after long periods of time. My OSX menu bar app starts with the computer and then sits there all day and night. Eventually I've noticed it will think there are 0 lights available and sending the -allLightCollection a set power ON or OFF message does nothing.

However, opening the iOS LIFX app on my phone causes a fresh to occur and everything to suddenly be seen again. The app also has a refresh button in the left side panel at the bottom. I presume this button is calling -[LFXNetworkContext scanNetworkForLightStates] which is marked as private.

That method, or simply a stub -refresh method that just calls that method as an internal implementation detail if you wish to abstract it, needs to be made public so that 3rd party apps are capable of providing the user with a 'refresh' button if the application falls out of sync with reality.

There seems to be no way to determine there are no LIFX bulbs available in the network. Obviously this can't be done without a timeout, but would be nice if you could provide such functionality with your library as you'd probably choose a better minimum timeout than I would. Also it's a bit weird that the LIFX Browser demo app suffers from this behaviour (is stuck in "searching" forever).

When building for iOS 8 on Xcode 6, I get the following build warnings:

Pods/LIFXKit/LIFXKit/CocoaAsyncSocket/GCD/GCDAsyncSocket.m:5852:50: 'kCFStreamSSLAllowsAnyRoot' is deprecated: first deprecated in iOS 4.0
Pods/LIFXKit/LIFXKit/CocoaAsyncSocket/GCD/GCDAsyncSocket.m:5856:50: 'kCFStreamSSLAllowsExpiredRoots' is deprecated: first deprecated in iOS 4.0
Pods/LIFXKit/LIFXKit/CocoaAsyncSocket/GCD/GCDAsyncSocket.m:5864:50: 'kCFStreamSSLAllowsExpiredCertificates' is deprecated: first deprecated in iOS 4.0
Pods/LIFXKit/LIFXKit/CocoaAsyncSocket/GCD/GCDAsyncSocket.m:6216:48: 'kCFStreamSSLAllowsAnyRoot' is deprecated: first deprecated in iOS 4.0
Pods/LIFXKit/LIFXKit/CocoaAsyncSocket/GCD/GCDAsyncSocket.m:6237:48: 'kCFStreamSSLAllowsExpiredRoots' is deprecated: first deprecated in iOS 4.0
Pods/LIFXKit/LIFXKit/CocoaAsyncSocket/GCD/GCDAsyncSocket.m:6279:48: 'kCFStreamSSLAllowsExpiredCertificates' is deprecated: first deprecated in iOS 4.0

Hi, Thank you for this awesone library thet let us control lifx
I have small issue, how i can know for example if setPowerState or setColor fails ?

Thank you

You can change a light's color over a specified period of time, but the power state payload does not take a duration. It would be great to have a duration parameter for setPowerState just like for setColor.

• (void)setColor:(LFXHSBKColor *)color overDuration:(NSTimeInterval)duration;
• (void)setPowerState:(LFXPowerState)powerState;

Not sure if this is a liftkit question exactly but can you guys put your Unity plugin on github or on your developer portal

I get the following error whilst attempting to compile the OS X Static Library:

.../LIFXKit/Classes-OSX/LFXWiFiObserverOSX.m:36:50: Use of undeclared identifier 'CWServiceDidChangeNotification'

Looks like LIFX has a new bulb that is cheaper and color-temperature-only. Similar to my other open issue requesting LFXLight be able to report its model number (or capabilities), how does a developer distinguish between these (now) two different bulb types?

http://www.lifx.com/products/white-800

I have a user reporting a crash that happens every time, shortly after launch, only if a LIFX White 800 is on their network. It looks like it is happening on the main thread, and entirely within LIFXKit. My LIFX White 800 bulbs are still in transit with FedEx, so I haven't verified this yet in-person, but I hope I'm wrong and this problem isn't widespread. Posting here in case any other developers can confirm or deny reproducibility. LIFXKit is seven months old, but the main LIFX app is clearly using a newer version of this code.

-[LFXMessageRateManager connect]: unrecognized selector sent to instance 0x15ed5ab0

Here's the offending chunk of code:

        LFXGatewayConnection *newConnection = [LFXGatewayConnection gatewayConnectionWithGatewayDescriptor:gateway messageRateManager:self.networkContext.messageRateManager delegate:self];
        self.gatewayConnections[gateway] = newConnection;
        [newConnection connect];

where newConnection isn't actually a LFXGatewayConnection, but somehow a LFXMessageRateManager. Looking at the code, that doesn't seem possible, so I wonder if it's a memory management issue and it's messaging garbage?

5   Lightbow                             0x001622c3 -[LFXLocalTransportManager gatewayDiscoveryController:didUpdateEntry:entryIsNew:] (LFXLocalTransportManager.m:351)
6   Lightbow                             0x0015c68b -[LFXGatewayDiscoveryController handleStatePANGatewayMessage:] (LFXGatewayDiscoveryController.m:98)
7   Lightbow                             0x0015bf6f __94+[LFXGatewayDiscoveryController gatewayDiscoveryControllerWithLocalTransportManager:delegate:]_block_invoke (LFXGatewayDiscoveryController.m:39)
8   Lightbow                             0x0016f16b -[LFXTransportManager sendObserverCallbacksForMessage:] (LFXTransportManager.m:126)
9   Lightbow                             0x0016201b -[LFXLocalTransportManager gatewayConnection:didReceiveMessage:fromHost:] (LFXLocalTransportManager.m:313)
10  Lightbow                             0x00170a83 -[LFXUDPGatewayConnection udpSocket:didReceiveData:fromAddress:withFilterContext:] (LFXUDPGatewayConnection.m:266)
11  Lightbow                             0x0014c86b __72-[GCDAsyncUdpSocket notifyDidReceiveData:fromAddress:withFilterContext:]_block_invoke (GCDAsyncUdpSocket.m:978)
12  libdispatch.dylib                    0x31c052e3 _dispatch_call_block_and_release + 8
13  libdispatch.dylib                    0x31c052cf _dispatch_client_callout + 20
14  libdispatch.dylib                    0x31c08d2f _dispatch_main_queue_callback_4CF + 1328
15  CoreFoundation                       0x230ec609 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 6
16  CoreFoundation                       0x230ead09 __CFRunLoopRun + 1510
17  CoreFoundation                       0x23037201 CFRunLoopRunSpecific + 474
18  CoreFoundation                       0x23037013 CFRunLoopRunInMode + 104
19  GraphicsServices                     0x2a8d0201 GSEventRunModal + 134
20  UIKit                                0x267dba59 UIApplicationMain + 1438
21  Lightbow                             0x001fc46b main (main.m:16)
22  libdyld.dylib                        0x31c26aaf start + 0

The title says it all. It would be great to take out all the warning strings I have in my app about alarms and timers unable to be stored on LIFX hardware and allow feature parity with Philips hue on this front. Ideally, you guys would expose both Alarms and Timers, but Alarms is the more highly requested feature from my LIFX users.

Every 15 seconds or so I'm getting a pair of logs:

2014-07-08 18:11:25:141 Lightbow[19704:907] Service TCP/10.0.1.3:0 unavailable (port == 0), ignoring
2014-07-08 18:11:25:141 Lightbow[19704:907] Service TCP/10.0.1.3:0 unavailable (port == 0), ignoring

In this case 10.0.1.3 represents a LIFX bulb that appears otherwise to be functioning perfectly. (I can send it color change commands and things behave as expected). The logs appear to be coming from LFXLANTransportManager.m line 225 (using the latest LIFX SDK) inside the method - (void)gatewayDiscoveryController:(LFXGatewayDiscoveryController *)table didUpdateEntry:(LFXGatewayDiscoveryTableEntry *)tableEntry entryIsNew:(BOOL)entryIsNew.

Reproduces by building the sample LIFX Browser project on Xcode 6.0.1 / iOS 8 Simulator / Yosemite, though the warning says first deprecated in iOS 4.0 according to CFSocketStream.h:
CFN_EXPORT const CFStringRef kCFStreamPropertySSLPeerCertificates CF_DEPRECATED(10_4, 10_6, 2_0, 4_0);

Build warning:
LIFXKit-master/LIFXKit/Classes-Common/LFXTCPGatewayConnection.m:284:57: 'kCFStreamPropertySSLPeerCertificates' is deprecated: first deprecated in iOS 4.0

Your code:

• (void)socketDidSecure:(GCDAsyncSocket *)sock
  • • •
  // Create SecTrustRef from Stream
  CFTypeRef ref = CFReadStreamCopyProperty(readStream, kCFStreamPropertySSLPeerCertificates);

Both Philips hue and LIFX have enough latency and required spacing for commands that a "strobe light" effect isn't available in the official API. The philips bridge however unofficially allows you to push "point symbol" effects to bulbs that you can later activate to get rapid changes in the bulb state, from simple strobing to color flashes. It would nice to at least get some API to initiate a strobe for X seconds, or in a dream world, the ability to assign a raw pointsymbol sequence for custom effects.

I'm trying to create a new workspace and use a Podfile. This is on the Mavericks beta, so not sure if that's part of the problem.

Two issues.

1), If I have a podfile with just

pod 'LIFXKit'    

I get the following error when doing pod install:

[!] An error occurred while performing `git pull` on repo `master`.
[!] /usr/bin/git pull --ff-only

fatal: Not possible to fast-forward, aborting.

2. For some reason, the Readme.md that I pulled instructs me to have the following in the Podfile:
   ruby pod 'LIFXKit'

I'm pretty sure that "ruby" shouldn't be in there.

But the first issue is the real blocker for me - any idea why that might not be working?

If a light is off, and I want to turn it on to a specific color, I have to send two separate commands:

[target setPowerState:LFXPowerStateOn];
[target setColor:color overDuration:transitionTime];

If the light was previously blue (for example) before it was turned off, and I want to make it turn on and go to red (for example), it seems to start fading up blue before switching to red. Ideally there would be no interim blue state.

Do you have a timeline for OSX support? If you've started a local osx dev branch, I'd appreciate it if you could push it to github. Thanks

Issue :
The latest version of LIFXKit (0.6.1) won't compile in an iOS App extension, using Xcode 6.2 and iOS 8.2 SDK.

Cause :
Usage of +[UIApplication sharedApplication] in :

• LFXWiFiObserverIOS.m, line 30
• LFXLocalTransportManager.m, line 86

sharedApplication is declared as NS_EXTENSION_UNAVAILABLE_IOS("Use view controller based solutions where appropriate instead."); in UIApplication.h line 215.

Possible solution :
Make the user define a preprocessor macro (such as #LIFXKIT_APP_EXTENSIONS) to disable codes that calls unavailable APIs when compiling an app extension. That's what AFNetworking does (see issue #2119.