LIFX Local Control


Mine appears to match yours, character for character:

private void sendPacket(List buffer, boolean noResponseExpected = false) {
String stringBytes = hubitat.helper.HexUtils.byteArrayToHexString parent.asByteArray(buffer)
new hubitat.device.HubAction(
type : hubitat.device.HubAction.Type.LAN_TYPE_UDPCLIENT,
destinationAddress: myIp() + ":56700",
encoding : hubitat.device.HubAction.Encoding.HEX_STRING,
ignoreResponse : noResponseExpected


That certainly looks right - can't explain the log you posted, unless that was just the one before you updated the drivers.

If you're still getting lots of warnings then I'd have to suspect that there's an issue with your wifi signal strength, or some sort of interference


Ok Rob, thanks. One thing I noticed and will explore further; the reaction times of my LIFX lights gets noticeably longer the closer I get to that 7th day I referred to, when they no longer react. I am wondering if logging a whole bunch of those UDP warning messages somehow bogs down the system. I am going to start clearing the log files to see if that keeps me from having to do a soft reset every seven days. I’ll let you know what it looks like after a few weeks. Thanks again for your time!


I have done soft resets and I recognize now that this does not clear PAST LOGS. "Clear" only clears the current live logging view. I will try to PAUSE and see if that makes any changes to my issue.


Are you still getting multiple UDP timeouts a day? I've not had any here in the last 12 hours or so


Plenty! But concentrating on one device, I noticed all of the warnings on this device occurred with a time stamp that had 32 seconds as a common theme.

Maybe a clue...? I am going to look at the other devices singularly for something similar.


Each of the warning messages has a specific time in seconds. This color bulb log shows a few warnings through today and when it occurred, 18 seconds was the common time.

Hope this sheds some light...


Don't know if this will help, but here's a snippet of mine:

My bulbs have indeed been extremely sluggish today. I wasn't getting this flood a couple days ago. I'll keep watching it over the next few days to see what happens.

I've been fooling around all day today with Hubitat and RM4.0, so everything's gone through a lot of changes. I did however reboot my router at 11:24pm, right after the last UDP error occurred here, and I haven't gotten a single new one since.


I should also mention that the reason I rebooted my router was because I upgraded the firmware. I also went in and gave all my LIFX bulbs highest bandwidth priority in the router settings in an effort to help 'em out - don't know if that'll make any difference.


I updated. Imported the code for each. Did not delete anything and did not press "clear caches". Rebooted Hub and checked the logs - flooded with the same message, "Error occured with UDP message: SocketTimeoutException: Receive timed out".


That is definitely the poll() method which runs every minute, I would always expect that to run at the same second of the minute (+/- 1) unless the hub is really busy.


This is very puzzling - I assume that everyone with the UDP timeout issue is running some version of 2.1.3 firmware, and preferably the latest?


Oh, that's interesting! What model of router is it? And the same goes for the others with the same problem.


Running the Hubitat firmware,
I downloaded the latest of your LifxMaster.
I just rebooted my Netgear WNDR3700v3 with firmware V1.0.0.42_1.0.33
Didn't occur to me to reboot the router. Thanks for that idea, Kilowatts! I set the device that I showed in the first set of logs to the HIGHEST QoS priority.
So we'll let that run for a while and then look at the log later today.


Sorry folks, if we could be so lucky


More hints to the problem here:
I did the reboot of the Netgear router and I reexamined the HE log to hone in on the devices throwing the most warnings (two Z-strip devices, Coffee light, Stove light). I prioritized them to the highest QoS on my router.
Then I went back to one of my Rule Machine 3.0 triggered rules and realized I called those two Z-strips to turn RED in the event of a break-in. Then I remembered, Rob, that the Z-strips can only be turned on and off, no colors. I edited that triggered rule accordingly.
Been running the log a couple hours now and have substantially reduced (but not eliminated) the warnings on the system in general. I'll evaluate in a few more hours.

Next step?:I thought about saving this set-up, then doing another HE soft reset, add just one Lifx light to HE, add just one contact device (Pantry door), add just one lighting rule (Turn on overhead light when pantry door contact opens) and then let HE run and log for a while. See what happens. I've got time...


Hmm, that's interesting - what types of bulb are dev:2697 and dev:2701?

My guess is that they are one of Tile or Beam/Strip OR LIFX+ (with infrared)

LIFX+ sends 3 messages when polling, and the other two devices send 2 messages.

If they are any of the other devices then it looks like they're being polled twice


Thanks for that Darrall - as I just posted in my earlier message, there are 3 device types that send more than one message when polling, It's possible that I'm not waiting long enough between those, I guess that may cause a problem since you're supposed to wait around 50ms before sending a new packet to a given address.

I probably won't be able to work on this until Tuesday though.


Correctamundo, they're strips. However, all of the rest (a19, d&d) throw the errors eventually as well - looks like most happened in the wee hours overnight.


I was wondering whether there was a time dependency on this, although I would have thought that it would be more likely to be when the WiFi was being used heavily. It doesn't coincide with the hub's backup time (around 3AM) by any chance does it?