I really need to get the Tile and Beam/Strip support sorted
2 Likes
Hey @rob. Have you upgraded to the latest HE firmware (2.0.9.133)? I’m seeing errors in the log for LIFX Master:
I can't reproduce that here, any idea what commands that might relate to?
No sure to be honest. I’m triggering lights from webcore at the moment (in the middle of rewriting RM 3 rules for lights). The log entries aren’t relating to light triggers going on so it’s a bit weird
The line number it mentions (745) doesn't seem to tie in with the latest version of the code, may be worth updating to the latest version?
I thought to same about update - the screen shot in the post above was taken after I updated to the latest code for app and all drivers. This is the screenshot of that line section:
Is app 979 the Lifx Master app? I'm wondering if the error is being generated from webCore. I don't see a reference to "lifxCommand" in Rob's code.
Edit: I do see the sort order debugs in the code so it's obviously the Lifx Master App but I'm still curious as to where the "lifxCommand" reference came from.
lifxCommand is the method a few lines above the screenshotted one.
Yup..something broken in my brain. I searched the raw code for it but must have mis-spelled it. 
1 Like
The fact that you're getting those errors makes me think that you may not be receiving acknowledgments from the bulbs in a timely fashion - this can sometimes happen when sending a SET_COLOR command followed by a SET_POWER (which should only happen when the bulb is not already turned on).
To test whether this is the case we could try disabling acknowledgements by using this version of the lifxCommand code.
void lifxCommand(com.hubitat.app.DeviceWrapper device, String deviceAndType, Map payload, Byte index, Closure<List> sender) {
sendCommand device, deviceAndType, payload, false, false, index, sender
}
i.e. changing the second boolean from true to false.
I would expect that to eliminate the error from the logs, but it may mean that some commands get missed, although I think that is unlikely.
1 Like
Lol sorry @rob.
So far no log items for Lifx Master so I guess it’s worked. If anything, I’m noticing a big increase in speed for lights turning on and also less weirdness during mode change and less brightness - before changing to false, on mode change if a light was 100% brightness and then in the new mode 10% brightness the lights would throw a wobbler - brightness would change up, down, up about 5 times before finally settling on new brightness. With the setting change it’s only happening twice lol
It's one of those situations where you try to make a change that improves performance that actually makes things worse.
I have a few choices:
- Remove the code that tries to resend
- Delay commands a bit longer to give the devices a chance to respond before attempting to send the next command
- Use a somewhat more sophisticated way of ensuring that all commands are sent and acknowledged.
I'm leaning towards #3, but testing it is a bit tricky
I would say definitely no for point 2 otherwise local processing seems less of a point when it operates the same speed as GOG driver.
3 seems the best overall option but I’m guessing will involve a LOT of dev work which in the grand scheme might not be as useful as it seems especially if more people test option 1 and no one reports failed on/off commands or a very low failure rate to turn on/off bulbs.
Option 1 so far seems the best happy medium. I now have no popcorn effect for rooms that have 2 bulbs (HE built in groups I just found a bit useless really so each call for light is always a direct per bulb call) - all lights are instant at the same time now with option 1.
Just done another mode/brightness test. Now the bulbs are behaving as expected and no party strobe flashing lol
1 Like
That's good news. I was probably just over-engineering things without any need.
I'll stick with option 1 for now, which probably means that I don't need to bother implementing groups, which is a major win for me 
1 Like
With the performance I’m seeing groups definitely aren’t needed as it is effectively working that way now just having to call each bulb in a rule/motion etc. I’m getting the same response speed I get from Apple Home (which is definitely local processing). I’m also getting a faster response from HE control than the Lifx app! Well done!
1 Like
@rob @Townsmcp how are you controlling groups of lights via dashboard or Alexa? I get a slight delay plus significant popcorning when using HE groups via virtual switch, but toggling individual light is nearly instant. Groups looks to me like it is sequentially requesting each bulb to turn on. Is there another way I can set up groups and/or scenes more reliably (virtual switch tied to RM rule? a separate custom driver?)?
I'm curious to understand the above in post #231/#235. Is HE blocking until it receives an ack from the LIFX device, and so if turned on in a group it truly is sending broadcast to light 1, wait for ack, send to light 2, wait, etc?
Why does disabling the "resending" piece result in quicker performance? If that's what's causing delay, presumably we needed the resend in the first place and shouldn't disable it? I'm sure I'm missing something here!
Haven't worked with UDP before but I am happy to get my hands dirty. Just curious to understand the current state of affairs.
EDIT: Post numbers were wrong, corrected.
I'm considering adding a driver for groups that will prebuild the queue of packets for all the bulbs in the group and then blast them out in one go (possibly reordering them so that if there are multiple packets for the same IP they will be a bit more spread out over time - if that makes any sense?).
I'm not sure the ACK is really required, unless you have a very congested network. I could probably make the mechanism a bit more sophisticated by using a delay to check whether a given packet has been acknowledged.
I'm not expressing myself terribly well here, but it's the end of a long, hot work day. 
@anthony I don’t use groups. HE or otherwise. Because I changed the Boolean from the earlier post it seems like no check is made to make sure the designated light is on. Check would just be fore reliability to make sure the on signal is sent, receivers and related back. If you can handle a light might not come on when it’s told to, then changing the value is well recommended for performance. In turn this makes the whole process so much quicker as it doesn’t have to wait for a reply to confirm the light is on. I call a group of bulbs in a rule individually. With the new value I am getting instant on from a range of bulbs all at the same time
