lifx / lifx-protocol-docs Goto Github PK

Mea Cupla

How do we get/set group information in this version of the protocol?

Is there documentation available on how to interpret the HSBK values in relation to say the iOS app?

For example, when in colour mode, when I set the wheel to 50% in the iOS app, the B value is coming back as 100% (0xFFFF). Increasing the wheel to 75% leaves the B value at 100% and decreases the saturation value. I was just wondering if there is an algorithm documented as to how the iOS app decides how to interpret the wheel values and what HSBK values to set?

One of the major problems for clients implementing the current LAN protocol is that keeping local state for devices up to date in an environment where multiple clients may make changes is rather sloppy. The only way to do so currently is to poll all devices on some interval, which can be quite expensive, and adds significant delays to state detection.

I'd propose a Subscribe/Unsubscribe message that takes no additional data, and causes the device to send unsolicited State* messages upon completion of any state change to the origin of the Subscribe message.

To support this feature there should also probably be Ping/Pong keep-alive messages, so that devices can time out subscribers that are no longer available. This controls unbounded growth in case subscribers are transient or change address frequently. With this in mind, perhaps the Subscribe message would take a timeout interval for the health check, however I think it would be quite acceptable to simply have a fixed (and quite protracted) check interval. Perhaps 2 failed consecutive checks would invalidate a subscription.

Implementing this proposal would have some overhead - the device would need to store a small amount of data - the IP/port/identifier and failure count (and possibly interval) for each subscription (probably this needs to be bounded, and subscribe should return error on OOM), and to run a scheduler for keep-alives. There would also obviously be n-1 additional datagrams per state change, where n is the number of subscribers (no need to notify the originator of the state update, since they can just request ACK). I don't know what sort of hardware we're dealing with, but I suspect this wouldn't be too onerous a burden.

The overhead for packet processing/transmission probably actually reduces as clients implement this feature (depending on the health probe interval, though those packets will be considerably smaller than full state updates), as it removes the need for constant state probes against all devices, as state updates are only transmitted by devices when a change occurs.

This doesn't solve detection of new devices appearing on the network (or devices being powered on/off at the wall). The former can probably be solved by a broadcast upon joining the network, the latter not so much - open to ideas, though a long poll by the client is probably not the worst thing here.

/brain-dump

There are at least 7 messages that are not covered by the current documentation. Using the latest firmware my lights are broadcasting messages with the following undocumented IDs:
50
53
56
111
The official android app broadcasts messages with the following undocumented IDs:
48
51
54

Hello!

There are a lot of reserved fields in the message header, and all of these fields are documented as "must be set to zero". However, in practice I very often see that my bulbs are sending packets with non-zero reserved fields.

So I am thinking that when a field is documented as "reserved, must be zero" this actually means that when I (as a 3rd-party developer) construct message packets, I must set all reserved fields to zero, but 1st-party apps/bulbs might be using the reserved fields for undocumented purposes.

Is this right?

Thanks

The documentation states:

The power level can be either standby (0) or enabled (65535).

I note that when I brighten or dim a lamp over say 10 seconds and query the lamp every second (via a Get - 101) that the Power Level is coming back as a slowly increasing (or decreasing) value.

The documentation states:

There are a duplicate set of device power related messages, Device::GetPower, Device::StatePower and Device::SetPower, which are extended for lights by adding a duration field to Light::SetPower.

This implies there have been changes in this area. Passing back a variable value for Power Level is actually quite useful - is the documentation out of date or is this an unsupported feature?

Currently the only way to onboard a LIFX bulb is to use an Android or iPhone.
Please document the onboarding APIs, so more platforms can onboard your bulbs (Windows, home automation controllers, Linux, macos, etc etc).

Every time I get a new bulb or have reset a bulb, I have to have a friend with an iPhone or android phone to come by just to use my bulbs again.

It aims to be an open industry standard IPv6 based secure IoT protocol. (Somewhat related to issue #6)
http://threadgroup.org/

Hi,

please be aware that at least with some compilers (e.g. MSVC Community 2019 and its bundled toolchain), the C header declaration included as part of the LIFX Protocol V2 Message headers documentation is incorrect in that it doesn't lead to the intended/required packing of the header, specifically the following part of the frame typedef...

uint16_t   protocol : 12;
uint8_t   addressable : 1;
uint8_t   tagged : 1;
uint8_t   origin : 2;

...which instead should be all of the same type uint16_t in order not to confuse the compiler...

uint16_t   protocol : 12;
uint16_t   addressable : 1;
uint16_t   tagged : 1;
uint16_t   origin : 2;

Thanks for making the LAN protocol option available; keep up the good work!

BR//KHH (@xoblite)

It would be awesome if you could add messages that solely set either hue, brightness, kelvin or saturation. It would mean a more efficient way in a lot of scenarios to communicate with the bulb. Ie if you just want to dim the bulb, you need to first query it's current hue, saturation and temperature, just so you can set the brightness without changing the other values. It makes commands slower and more brittle, rather than just sending for instance a "SetBrightness" message.

Hello,

I was about to dig this older thread up: Adding bulb to multiple groups.

I'm looking at the new group API, thanks to Mark's help.

I'm wondering if we could document the group API entirely and clarify the fact that bulbs can't be in more than one group?

Thank you.

The current protocol appears to rely on UDP4 broadcast, UDP6 multicast should be an alternative. Obviously the firmware would need to implement IPv6 autoconf/dhcpv6 and configure a multicast address.

Designing for IPv4-only these days is short-sighted.

We currently need to use this on a larger campus network and due to the lack of multicast support on campus, the initial config fails. To successfully set up a bulb, we take the bulb off-site and configure it with the SSID and password same as the campus network. Does anyone have a solution? If this is not the place for this question I would appreciate some direction. Thanks!