Device::StateVersion Field Values

Hello,

I’m currently working on writing a library that implements the LAN protocol. One feature I plan on trying to build, is the ability to imitate a device on the network. Not only would this help me with testing, but I think it could help others to have a sandbox “device” that you can inspect the state of very easily.

As part of this process, I’ll need to implement a response to the Device::GetVersion message. What values should I provide for these fields:

My initial thought would be to create my own vendor and product values, and then pack the semantic version of the library in to the high 3 bits of the version field. However, I’d like to use values that will absolutely not conflict with ones provided by actual devices. Are there any values reserved for non-standard use?

I appreciate any insight.

Cheers!
-Tim

We currently don’t support people writing their own emulator. You might be able to emulate a device to your own app, or other developers apps built using the public API but we haven’t released enough information to convince our official apps that your emulator is a real device.

That said I can see the value in creating a namespace separate from our official vendor ids for people to play in. I’ll follow this up with management and the firmware team and report back when I have further information.

Temporarily though, we are assigning numbers starting at the lower end of the range and moving upwards, so if you pick very high values that will mean if there is a clash it will happen in a very long time.

We currently don’t support people writing their own emulator. You might be able to emulate a device to your own app, or other developers apps built using the public API but we haven’t released enough information to convince our official apps that your emulator is a real device.

That makes sense to me. I did not have the intent to be able to convince the official apps that my software is a true device. It was only for individuals to be able to write their own software without having to be on the same network as a true LIFX device.

This came from me wanting to work on my project while on a plane, but then realizing I didn’t have a device to test my code against.