Thanks Daniel! Do you have any advice on the best practices for populating the source field? I’ll admit, I don’t totally follow your description in the other thread, but it sounds like you’re referring to the 32-bit “source” field in the frame header, and I can set it to any arbitrary value (though probably should be the same value for every message that goes out, right?).
Are you implying the old LIFXKit would work, provided I find the right one-line change to always make those outgoing 32-bits non-zero, or are there other fundamental flaws with that old framework that mean this would call for a larger refactoring? (Are the responses different in a way such that the old LIFXKit wouldn’t recognize them?)
I’ve been talking with the developer of OnSwitch as well, and we’re all evaluating our options going forward. It seems most iOS developers are patching the old LIFXKit rather than the significant investment in starting from scratch.
I ask because it seems if I just naively set
protocol.source = 12345; (for example) in LFXMessage’s messageDataRepresentation method, I never get any responses from bulbs (original or 3rd gen). Sorry if that sounds completely obtuse, I rarely have the occasion to dig down into UDP/networking code.
Yup, I’m referring to the 32 bit
source field in the frame header. I suggest you randomise a number when your application starts up and use that for every packet your application sends.
Unfortunately I don’t know too much about LIFXKit, so I can’t say for sure how big of a change it is, however I can describe what the difference will be:
source field is zero the bulb sends the response as a broadcast with a destination port of 56700.
source field is non-zero the bulb will send the response packet directly to the host that sent it, with the destination port set the the source port of the request packet.
So if you were using the same socket that was listening on 56700 to send packets then populating the
source field should just work, as the unicode packets will return to the same socket, and the switch between broadcast and unicast will be transparent. If however the application had one socket for sending and one for receiving then you’ll need to re-architect it to use a single socket instead.
Why not bring the discussion to a thread here? Then LIFX Employees can occasionally jump in and give advice when required, like we do on the lightsd thread. I’m also sure there are a few people here that would be interested.