@rob Just thought I'd check in and see if there has been any progress on popcorning?
Once the devices have been discovered, is the "LIFX Master" app still needed? I'm asking because it's generating a ton of hub activity. By far #1 utilizer of hub processing time.
I'm using the latest version via HPM.
If it were just a couple of files then that might be okay, or it could possibly be automated I suppose.
There's no line to delete to disable the warning since they come from the HubAction. I have a local version uses the flag to turn it into an internal error, which then increments an error count, but I'm not really happy with the way it's handled at the moment.
Yes, all the shared code is in LIFX Master, every LIFX device driver uses it. And every LIFX device is a child device of LIFX Master. The more devices the busier it will be.
On my C3 hub it's about 2.5% of the activity at the moment, with an average time of 23ms (totalling 8000 seconds) over nearly 4 days. The C4 hub (my development hub) it accounts for nearly 100% (totalling 22,000 seconds) over 17 days, but there's not much else running on that. I'm not sure why the dev hub should be that busy though.
My new LIFX groups (which currently only supports on and off at present), seemed to be promising, but after turning a group on and off about ten times the popcorning is even worse than without the group code. It's very puzzling.
What if I never wanted LIFX Master or LIFX Color to log anything ever again?
There has to be a way to suppress these log entries or fix the issue.
UDP is stateless; why are you even getting a "SocketTimeoutException?"
Just wondering if you made any progress on being able to add and set IP addresses manually. Is there anything I can do to help?
That's probably a question for the Hubitat team, I suspect it's just so that there's some explanation for a device failing to respond. By default it occurs about 30 seconds of no response - I think the timeout can be changed, but can't remember why.
I've not had much time to work on the LIFX drivers since I've been back in the office I'm afraid.
I do have some ideas about not needing to - e.g. auto rescanning if a device fails to respond.
Just bought a Sengled Zigbee bulb on Amazon for $22. I'm done with LIFX.
PM me if you want to buy my lone LIFX LHA19E26UC10. I believe I still have the original box/tube.
A negative side-effect of the vaccine (do I really need to mark this as warped humor?)
LOL. And no you don't, at least not for me.
I only have 4 devices. Three of them are z-strips and one is a color bulb.
On my production hub, LIFX Master represents 38.1% of the hub busy time and 6% of total time -- not sure which your 2.5% represents. My average time is 86ms. In an hour of logging, LIFX Master showed 19 mins of hub time processing the app code.
I'm on the latest version of everything via HPM. And the 4 devices all have reserved IP addresses. I have one wild theory -- curious what you think. Last year sometime-ish, I tried creating child devices on one of the LED strips. Just messing around with the device driver. Once I realized it created something like 36 child devices, I clicked "Delete Child Devices". I now notice that, although the children all disappeared, the device details page still shows a crapload of state variables -- almost as if the driver is tracking shadow children (wish I could do that with my actual children sometimes, by I digress....).
Could this account for the slowdown? Do you have any other ideas on places to look?
The MultiZone driver (and associated actions in MasterApp) are by far the most expensive items in processing. The state of each zone is still tracked in the main driver, even if you do not have Child Devices created -- this was the case even before Child Devices for Zones.
My hub stats (I have 3 Z strips, each with 24 zones, 2 Lifx+ Color, and 2 Color bulbs):
Yes, it consumes a lot of cycles, building packets, parsing responses, etc -- but the good news is that each method call is short-lived -- in my case, an avg of 15ms. This is on a C4 hub.
Out of curiosity, what firmware version are your Z strips on? I'd expect that if they are < 2.77, and therefore using the legacy MultiZone packets, it may be slightly less performant?
Interesting and super thankful, thank you. My z strips are on v2.77 on the firmware. I may just have to splurge to buy another hub (ick) to spread out processing if there's no answer. My avg method call is 86ms versus your 15ms. Still suspicious. Maybe I'll delete the app and start over.
Edit for anyone facing the same problem: Ended up deleting devices and app, and starting over. Performance is now as expected. As @rob says, the lightstrips still take a far amount of processing, but it's not killing my hub any longer.
Those update automatically when Package Manager is used to update LIFX local control app, correct?
They should do, yes.
1 Like
Hi @rob, wanted to let you know I'm getting an error when updating lifx local control via HPM to 1.05 from 1.04.
Did a repair and looks like it updated.
Very weird.
