LIFX Local Control

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.

1 Like

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.

1 Like

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?

Yeah, that's all that's required.

I'm seeing much the same as you describe, although it seems less obvious when turning lights off.

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).

Okay, I've made a number of changes that should reduce popcorning.

  1. No longer requiring acknowledgments
  2. I noticed that I was updating both the device's name and label when parsing the state - I'm no longer doing this.

You should only need to update the LIFXMaster app.

3 Likes

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.

Thanks for your continued efforts on this!

1 Like

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 should maintain the status, how are you querying it?

Just doing a

http://{host}/apps/api/34/devices/all?access_token={access_token}

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 have 232 device ATM and it doesn't take that long for me, maybe 8-10 seconds tops.

Like I said, it sounds like way too many attributes or something else bogging down the system.

Best advise is to start disabling apps and devices and see if you can isolate the potential cause of the slow down.

Also, please provide a link to the lifx driver you are using, as we don't have built in support for them.

You can also isolate the potential problem by creating a handful of virtual switches and see if maker API is slow to load those.

Also, anything in Past logs that might indicate any errors?

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.

The drivers and app can be found here GitHub - robheyes/lifxcode

@rob hey Rob. I updated to the latest drivers just after they were released but when going into any Lifx device page Iā€™m getting the following page


Any suggestions?

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.

Bletchley Park, truly fascinating. Have you read Cryptonomicon?

Oh, another thing. I noticed errors when I switched on logging, and I think I found the bug..

In the LIFX Color driver, line 51 should read "state", not "statue".

@SuppressWarnings("unused")
def updated() {
state.transitionTime = defaultTransition
state.useActivityLog = useActivityLogFlag
statue.useActivityLogDebug = useDebugActivityLogFlag
initialize()
}

1 Like