String Encoding

What string encoding should be used for the various “String” fields in the LAN protocol? In one thread, @daniel_hall says “The bulbs do not try and parse or alter the label string in any way. They simply store and respond with the bytes you sent them.” but surely we should have a standard to ensure various apps reading/setting bulb and group names don’t end up with garbage. Does the main LIFX app use UTF8?

1 Like

The LIFX app and most other apps use a NULL character (\0) terminated UTF-8 string.

Thanks for the quick reply! That seems like the best bet and easy/safe to implement, although, it looks like the guidance on the LIFX Device Messages page now says “The label string is a fixed-length field, which is not null-terminated.” (emphasis theirs)

Is that just implying the field is always the same size for obvious protocol-designy reasons, so don’t just look for the null termination and expect the next field to start right away… but if your label is less than the maximum it should be be null-terminated?

So if a “String” field is (for example) allotted 10 bytes, the bulb name and corresponding bytes would look like:

“Hello” --> H e l l o \0 \0 \0 \0 \0
“TenLetters” --> T e n L e t t e r s (fills the field, so no null-termination needed)
“SpareSlot” --> S p a r e S l o t \0
“” (Empty name) --> \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
“NameThatIsTooLong” --> N a m e T h a t I s
“2byte::grinning:” --> 2 b y t e : \F09F \9883 \0 \0

(I’m also assuming anything after the first \0 is ignored but seems like a reasonable thing to pad it with, for outgoing packets)

Yes, the LIFX devices will not interpret the bytes you specify in these labels, they will just return them (all N-bytes of them, irrespective of the content). Various clients, including the LIFX app are likely to interpret these bytes as NULL terminated UTF-8 strings, so they’ll ignore everything after the first \0 they see (and render Hello in your first example).

1 Like