Some lights are not found

[ladeak]

I have four lights, all functioning, all in the same room, same network.
2 of them are found and 2 of them are never found by the library. (it is always the same two)

What could be the reason for that?

[dotMorten]

@ladeak Do you have any issues with those devices in any other apps that support lifx local access? Are they all 4 on the same subnet? (ie is the same first 3 parts of their IP number the same?)

[ladeak]

Yes, they are even same frequency band. Although I notice 2 has name LIFX-Mini-xxxxx and two has the name LIFX-Color-xxxxx.
I wonder if that is the reason. I had a good year in-between buying the first 2 and last 2.
They are all color lights though,

[dotMorten]

Yes, they are even same frequency band

That's not what I asked.

LIFX-Mini-xxxxx

Are those the ones that doesn't work? I don't have any of those so could be they just aren't supported / tested. Your best bet is to download the source code, and step through the sample app and see if they send messages, but we just don't do anything about them. Perhaps check if this get hit for all of them: https://github.com/dotMorten/LifxNet/blob/master/src/LifxNet/LifxClient.Discovery.cs#L54

[ladeak]

Sorry, no issues with the devices in any other apps.

Cool, thanks for the pointers, I will check the code in the next few days.

[ladeak]

HandleIncomingMessages does not even hit from their IP addresses LIFX-Mini-xxxxx, which is weird given they are on the same network, same IP range etc. I don't see a reason for them not to work.
No option in the app to enable/disable LAN protocol. Maybe a device reset could help?

Update: device reset did not help.
Targeting messages directly to the lights seem to work.

[mavanmanen]

I have the same issue, Attempting to create the bulbs manually but which port/service would I need to target?

[ladeak]

Port: 56700. I don't think 'Service' property does anything today in the library. I think you should be able to even skip the mac address if you manually create the device.
Ref: https://lan.developer.lifx.com/docs/communicating-with-device

[mavanmanen]

I tried to use port 56700 when manually creating the devices but that sadly doesn't work.

[ladeak]

As a quick update, discovery operation works with https://github.com/node-lifx/lifx-lan-client
I am comparing the messages sent out and, I see that byte 4-7 is different in the Frame headers https://lan.developer.lifx.com/docs/packet-contents#frame-header

This library sends out 1,0,0,0 and the linked js library sends out some values. This is the Identifier field's value in the library.

[dotMorten]

Nice find

[ladeak]

Solution seems really simple

The source identifier allows each client to provide a unique value, which will be included in the corresponding field in Acknowledgement (45) and State packets the device sends back to you.

Due to the behavior of some older versions of firmware you should set this value to anything other than zero or one. In some versions of the firmware a source value of 1 will be ignored. If you set source to 0 then the device may broadcast the reply on port 56700 which can be received by all clients on the same subnet and may not be the port on which your client is listening for replies.

https://lan.developer.lifx.com/docs/packet-contents#frame-header

I changed the initial value from 1 to 2, and I see all devices.

public partial class LifxClient : IDisposable
{
   private static uint identifier = 2;

Do you see any issues with this, or I may open a PR?

[dotMorten]

This library sends out 1,0,0,0 and the linked js library sends out some values. This is the Identifier field's value in the library.

That number should increase on each request when you're using requests that needs to wait for a response:
https://github.com/dotMorten/LifxNet/blob/master/src/LifxNet/LifxClient.DeviceOperations.cs#L37

It is used to know that a response is in response to the request we made.
Otherwise, it is 0.

[dotMorten]

I changed the initial value from 1 to 2, and I see all devices.

That's rather surprising. That number should keep increasing though.

[mavanmanen]

I changed the initial value from 1 to 2, and I see all devices.

That's rather surprising. That number should keep increasing though.

I think you are confusing this with the 'sequence' field from Frame Address

[dotMorten]

I think you are confusing this with the 'sequence' field from Frame Address

It's been a while since I looked at all this code (and I'm already cringing at my lack of tab/space consistency - what was I thinking?!? :) ), but It seems to me the entire implementation made that mistake. Back when this was written, the protocol doc was all based on reverse engineering.