LIFX Local Control

📢 Feedback Feature Requests
282

It's nothing to worry about - just a change to the way that HE handles UDP messages.

There is a parameter than can be used to tell HE not to expect a response, and therefore not to give the warning (e.g. when sending commands to change state), and also one to not display a warning when a response might be expected (e.g. during discovery), but I'm not sure which version of the firmware will support the ignoreWarning parameter.

I may release a new version this weekend if I get around to working on the code.

1 Like
283

I've just checked my messages and version 2.1.3 will have the ignoreWarnings option, I'd guess that will arrive sometime this week.

2 Likes
284

My bulbs have been suuuuuper slow to respond today, after updating HE firmware. Trying to narrow the sluggishness down - anyone seeing similar?

1 Like
285

@kilowatts
I can second that. My lights are gone super slow. Both via Dash and via Alexa.
Gone from less than a Sec to 2-3 seconds and delay in actioning the groups as one on/off.
They turn off one at a time.

286

I haven't seen that here - anything in the log?

I just realised that I'm running an experimental version here that sets the ignoreResponse field to true in the HubAction that I'm using. However, if I change to not setting it to true I still don't see a slow down. The only difference is the warning that is logged around 10 seconds after the commands are sent.

287

YESSSS! Please, someone help with the UDP warning! I get that for 7 days on 17 bulbs, then they stop responding (Lifx minis) and the HE requires a soft reset (tried restoring data base, no joy, many attempts)
It is very predictable as far as every 7 days goes.
I will try to find where I can tell HE not to expect a response. VERY INTERESTED in not having to soft reset once per week.

BTW, all: thanks for the super support. HUGE fan of HE!

288

Noob question:

Where does one find the "ignoreResponse" selection?

Sorry...

289

I'll try to get the update sorted this evening, although I have no idea why they'd stop responding after 7 days

290

Mine have never stopped responding, but they have gone through some sluggish periods. I wonder - what sorts of things could cause sluggishness? Can the router sometimes be a suspect?

291

I've updated the repository with a version that handles the UDP warnings better - uses ignoreResponse for any command that makes a change to the state of a device, and for the LIFX Discovery device it uses ignoreWarning to reduce the warnings in the logs that it would get for IP addresses that don't have a LIFX device on them.

Let me know if there are any issues ASAP and I'll try to get them sorted this evening.

292

image
image.png1366×768 138 KB

Using the code you created today, Rob, this is my log before I loaded and after I loaded it.

The long string of errors and "null on line 67" is what happens on the 7th day.

293

I only see one log there from early yesterday morning.

poll() looks like this:

def poll() {
    parent.lifxQuery(device, 'LIGHT.GET_STATE') { List buffer -> sendPacket buffer }
}

The IllegalArgumentException seems odd, and would imply that the drivers have lost the current device

Can you confirm what the sendPacket() method of LIFXColor.groovy looks like?

294

I'm yet to update due to the upgrade process of having to re-discover all 76 bulbs, given the issues I had previously with discovery. Am I correct in thinking the Master App must be deleted first, then the code updated for each bulb model?

295

Don't delete the Master App since that will force you to do a full rediscover which is a nightmare; just update the master apper and the device code for each bulb type (plus the discovery device).

Note that you should be able to just use the import button for each of these rather than pasting the code in. It should know the correct URL unless you haven't updated in a long time.

I would however strongly recommend that you set up a group for each bulb or group of bulbs - see the ADVICE section of the discovery page.

296

Log%20DPRIDE1
Log DPRIDE1.jpg1366×768 122 KB

Here is the screenshot I think you're asking for.

297

Can you show me what the sendPacket() method of LIFXColor.groovy looks like?

298

Sorry to waste your time, Rob. I guess I don't know what you're looking for or where to get it. Too much of a noob. Thought that info was in my last screen shot.

299

I'm still getting the SocketTimeoutException warnings, albeit not nearly as much. I'll leave my logs open all night to see, but if I had to guess they're throwing the error maybe once or twice per day.

300

This is the one I have

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

That pretty much matches what I'm seeing here, given that every LIFX device is being polled once every minute that's not too bad.