When you refer to "LIFX" are you referring to the Groovy implementation? The wire protocol itself treats each bulb independently so the concept of threats doesn't apply.
As far as I know the only Groovy implementation is mine. I'm wondering whether the LIFX app talks to the bulbs using multiple threads.
Threads aren't quite the right paradigm. In my JavaScript implementation, there is a single thread but it's asynchronous in that the code doesn't wait on the messages and it responds to events. Is that how your code works?
I'm limited by the way that sendHubCommand() works. I think it's asynchronous, but there may be some overhead.
Although the most recent version of the Hubitat code has an ignoreResponse flag that I've not played with yet, no idea whether it will help until I try it.
This is one reason I'm using node as an environment. It complements Hubitat for me.
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
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
My bulbs have been suuuuuper slow to respond today, after updating HE firmware. Trying to narrow the sluggishness down - anyone seeing similar?
1 Like
@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.
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.
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!
Noob question:
Where does one find the "ignoreResponse" selection?
Sorry...
I'll try to get the update sorted this evening, although I have no idea why they'd stop responding after 7 days
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?
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.
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.
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?
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?
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.
