Thanks for the clarification. So are you saying that the ack is really only required for you to know whether to re-send? And so by disabling the re-send parameter, we avoid waiting for the ack at all? This would make sense to me.
I think this is probably the best long-term solution, if multi-threading is not available, this would hopefully be more simultaneous and still allow for the re-send reliability if necessary. Per this link (LAN protocol group support - #6 by pdf - Developing with LIFX - LIFX Developer Zone) LIFX themselves expect up to 3 failed messages. As a side note, I picked up a Harmony hub this weekend which is able to do LIFX local control and control Harmony-defined LIFX groups with as-good sync as the LIFX app. So, it should be possible (but they may be using multi-threading).
@Townsmcp Appreciate the feedback on your setup. I would obviously prefer the reliability but the popcorning is just annoying enough that I'd be willing to try that until a more robust solution is available like the one Rob describes. I am going to try the code edit tonight (I don't see a new version on github yet so I will follow the guidance in post 231) and will report back with results for groups.
Changing the boolean definitely speeds things up for me. I noticed worse performance using HE Groups, so I am instead calling on multiple bulbs directly. This leads to a noticable performance gain. I wouldn't say they're perfectly in sync, but they are much closer. I have a high-traffic hallway using a LIFX bulb, so I'll report back if it misses a beat.
I tried changing the boolean and it "sometimes" led to a speed increase. I haven't tried sending to each bulb individually though. Will give that a shot.
Finally got around to trying out the code with the ackRequired set false. It does seem slightly faster but I can't say I notice a huge difference. When operating a group of lights via HE group OR by triggering each individually via RM from Virtual Switch, I still am seeing popcorning (presumably because even when specified individually within a rule, the actions are being processed sequentially).
I am assuming all I needed to do was edit the line in the LIFX Master app and save - no reboot required?
Agree on turning off being more simultaneous. Also have noticed changing color temps and level is fairly synchronized too. Turning on seems to be most popcorny - second only to activating scenes (but that probably an order of operations issue, maybe better implemented in RM where I can control the order of commands sent).
Thanks Rob!!! When toggling on/off via RM, it is much more simultaneous! Groups are still a bit more delayed but I can just operate a virtual switch thru RM rather than use the HE group directly.
What are the timing considerations. It seems that sending a status request after I turn a light on and off returns Host Unreachable. Is that a problem with the driver or the Hubitat?
LIFX recommends around a 50ms delay I believe (ie no more than 20 calls to one device per second).
I can only assume that the device is too busy to respond to the status request, although I don't think I've ever seen a host unreachable during development or usage.
Does the driver maintain the status? When I request the current status of all Hubitat devices does the driver poll again or does it return the last status discovered?
(I'll omit the grumble about device implementers that cant manage request queues).
It may not be about LIFX but simply a slow Hubitat when I have over 100 devices. It's much faster when I don't ask for all the info. I have 66 lifx devices connected to Hubitat.
WIthout the "all" it takes under 2 seconds. With /all it took 164. (Should I also post this on the Maker thread?)
I"m using Rob Heyes drivers though haven't been updating them. I'll try to do some more experimenting at some point though now that I've worked around it it's not a crisis -- just an inconvenience.
EDIT:
Think I fixed it. Went into LIFX master app and did a rediscovery. All bulbs available again when going into property pages. Only issue encountered was motion lighting rules lost bulbs. Added the bulbs back to each ML and previous settings restored when bulb added
I was away for the weekend, so I've only just seen this. Went to Bletchley Park yesterday which was fascinating.
That's very weird though, I can't think what might have caused it.
This is why I strongly recommend using Hubitat groups in all the rules etc. and then pointing the groups at the actual devices, and not just LIFX ones. I also makes it much easier to swap devices around if you do that.