LifxNet
LifxNet copied to clipboard
dotMorten
Some lights are not found
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?
@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?)
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,
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
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.
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.
I have the same issue, Attempting to create the bulbs manually but which port/service would I need to target?
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
I tried to use port 56700 when manually creating the devices but that sadly doesn't work.
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.
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?
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.
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 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
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.
See here where it increases: https://github.com/dotMorten/LifxNet/blob/772d14eb79643869dfcc4164c0ba07370ca0dfa5/src/LifxNet/LifxClient.Discovery.cs#L19-L23
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
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.
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.
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.
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.
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'.
@ladeak if your fix works, I'd definitely like to see a pr for that, library would at least work again.
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
Both PR-s out there. Both finds and returns all lights now.
@dotMorten please review when you have a chance :)
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?
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