Some lights are not found about lifxnet HOT 29 OPEN

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?

from lifxnet.

No response to the pull request... How would everyone like to handle the fork? I'm happy to create and maintain a new Nuget if that would help?

from lifxnet.

New Nuget finds additional devices and combines work from both @dotMorten and @isaaclevin to offer LAN or Cloud control here:

• https://github.com/panoramicdata/Lifx.Api
• https://www.nuget.org/packages/Lifx.Api

from lifxnet.

@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?)

from lifxnet.

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,

from lifxnet.

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

from lifxnet.

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.

from lifxnet.

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.

from lifxnet.

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

from lifxnet.

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

from lifxnet.

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

from lifxnet.

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.

from lifxnet.

Nice find

from lifxnet.

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.

from lifxnet.

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

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

from lifxnet.

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

from lifxnet.

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.

from lifxnet.

See here where it increases:

from lifxnet.

This is where it is written in the FrameHeader:

//BinaryWriter bw = new BinaryWriter(ms);
#region Frame
//size uint16
dw.Write((UInt16)((payload != null ? payload.Length : 0) + 36)); //length
// origin (2 bits, must be 0), reserved (1 bit, must be 0), addressable (1 bit, must be 1), protocol 12 bits must be 0x400) = 0x1400
dw.Write((UInt16)0x3400); //protocol
dw.Write((UInt32)header.Identifier); //source identifier - unique value set by the client, used by responses. If 0, responses are broadcasted instead
#endregion Frame

from lifxnet.

This seems to be an important thing in the docs 'We recommend that your program has one source value and keeps incrementing sequence per device for each message you send.'

Seems to be the original identifier used for the discovery should not be incremented but always the same but incremented for the other messages.

from lifxnet.

I think there's some major rewriting that needs to happen. That line you quoted should probably be a constant instead.
And each device needs a Sequence value it increments for all the requests that returns a Task to confirm acknowledgement.

from lifxnet.

This seems to be an important thing in the docs 'We recommend that your program has one source value and keeps incrementing sequence per device for each message you send.'

Seems to be the original identifier used for the discovery should not be incremented but always the same but incremented for the other messages.

Actually, that was what I also noticed. js library keeps the same values for those bytes.

from lifxnet.

from lifxnet.

Great find! I do think the fix is a bit significant though. I have stopped using my LIFX bulbs though (I've moved to Zigbee lights which I find work better with more things), so it's limited how much time I can dedicate to this.

from lifxnet.

I think the fix might be even simpler. Sequence value should be incremented, and the Identifier shouldn't. All the code is already there, just the logic needs to be 'echanged'.

from lifxnet.

@ladeak if your fix works, I'd definitely like to see a pr for that, library would at least work again.

from lifxnet.

If you make a PR, I'd be happy to accept it, but please try and keep changes to a minimum, so code reviews will be faster. Avoid major refactoring (would need discussion first if required), and fixing all those tabs etc (yuck - sorry!) should be a different PR

from lifxnet.

Both PR-s out there. Both finds and returns all lights now.

@dotMorten please review when you have a chance :)

from lifxnet.

@dotMorten any chance to review the PR-s?

from lifxnet.