I was just wondering how often the LIFX app on iOS is polling bulbs to get the latest state. Via Wireshark I noticed that it is polling the devices every 5 seconds via broadcast UDP, but since I can not capture unicast traffic on my switch (without doing some annoying port replication), I was wondering how fast it is done. Updates to the UI are almost instant, so it must be a pretty high frequency. Knowing the 20 messages/second limit, is there an implicit assumption that only the LIFX app is active on the network, not taking into account traffic that might be generated by third-party clients?
The iOS app actually mostly uses a trick that involves a connection to the LIFX Cloud, so that it doesn’t need to poll the bulb very often. unfortunately this is not something that we can open up to the wider dev community at this time. Basically the bulb sends a copy of all responses that it is sending via the cloud, and internally to the cloud we route these messages to any connected phones.
This sounds like a terribly poor design decision - sorry to say that. What I liked about LIFX so far is that it is nicely usable locally, even if the Internet connection is down or unavailable. Having state events pushed only through the cloud now does not really make sense.
I should state that this only applies when the bulb is controlled by another device. If yours is the controlling device then acks and state message replies from the actions allow the screen to update as-it-happens. Almost all of the time a LIFX bulb is only being controlled by a single device at a time. Most times when two devices are trying to control a bulb its our cloud and one of our apps.
So without internet access you can still control the devices fine, it just means that if another device controls the bulb your device might not reflect that state in its UI immediately. Given most LIFX bulbs are connected to the cloud most of the time Myself and the other LIFX engineers feel this is an appropriate tradeoff.
The other option would be to have the bulb broadcast every single state message. This is what we tried in version 1.0 of the application/firmware. If you used that firmware and app you might remember bulbs being really slow to update, or not responding sometimes. This is because broadcasts are particularly unreliable compared to unicast traffic on a local LAN.
To answer @rhubley’s question, we still poll every 5 seconds as you saw. Most applications now set the source field in the protocol so the responses will be unicast, so we cant see the state message when another device is controlling the bulb.
This is only true as long as you consider LIFX to be a fancy gadget for tekkies who want to show off with their smartphone…
Once you go into serious home automation, you will find bulbs being switched by motion detectors and their state being displayed on wall-mounted tablets, where users expect to see an immediate state change.
See above. Although it seems to be a trend in the industry that everything connects to the cloud, I personally think this is the wrong approach on the long run. It disqualifies the bulbs for e.g. installer businesses and thus it will never be a true replacement for a real lighting installation and rather stays a geeky toy.
Well, there are other alternatives to broadcast, e.g. multicasts or subscriptions like UPnP GENA, CoAP or AllJoyn. Btw, since the latest LIFX bulbs support AllJoyn: Doesn’t it anyhow already support local event push through AllJoyn?
For the most part this is correct, but in more automated environments users tend to use UIs less and depend more on the automation. However these are the decisions we made for our own application given the constraints we were faced with. If someone wants to display state on a wall mounted screen they can poll faster, up to the maximum recommended message rate of 20 per second. The newer devices can go higher than this but the operating environment needs to be considered (how many other clients might be polling, wifi reliability, etc).
This only our implementation in our application, we do not enforce an update method for other applications. Other apps are free to use our documented LIFX protocol, and/or Alljoyn however they like. Users are also free to leave their bulbs unclaimed (where they wont attempt to connect to the cloud), or on networks entirely isolated from the cloud. We often test our own application in Faraday cages without any sort of external connectivity.
For most of our consumers multicast wireless traffic is treated the exact same way as wireless broadcast traffic, and is just as unreliable. This is because the range of wireless routers we need to support extends from ones given by ISPs free to consumers, to high grade enterprise equipment. This rules out multicast, UPnP GENA, and CoAP with the default settings. CoAP does allow transports via other methods, but the processor in the bulb is limited in the number of TCP transports it can handle at once. We don’t yet use Alljoyn in our Android or iOS applications, but we do in the Windows 10 application. It does support a event notification system.
I’ll raise this topic with our app developers for reevaluation.
WRT to AllJoyn emitting change signals, I’ve inspected the LIFX800 bulb and its introspection XML, and for instance the on/off property is not emitting the change signal. I don’t know why that is, but I really wish you would add that to your bulbs - seems like a mistake to skip the EmitsChangedSignal attribute on the settable properties of the bulb. You could even be clever and throttle the emitting, so when you’re sliding the brightness up and down continuously, it’ll only broadcast the change signal now and then (ie every 5 seconds for instance).
It’s just so beautiful when you can monitor devices and their state for logging purposes, or use it to create rules all powered by AllJoyn (for instance when Bulb A turns on, turn on X as well").