Announcement

Collapse
No announcement yet.

Resolution to Lifx Z disconnects, but fix won't work with UltraLighting

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Resolution to Lifx Z disconnects, but fix won't work with UltraLighting

    I recently purchased a few Lifx Z strips after looking not only them over, but also this plug-in (with the intent of integrating everything, as I usually try to plan out). Apparently I didn't look deep enough, and I've now discovered the never ending, extremely irritating Wi-Fi disconnect issue that Lifx Z seems to have far more often than not (this is not the fault of UltraLighting, but read on). After hours of research, I found a fix that works for me, and has worked for many...joining the Lifx Z strips to a separate SSID/separate subnet on my network. I know this is ridiculous, but apparently Lifx still hasn't resolved this issue despite many firmware updates. However, this means a separate subnet on my network. Although Google Wi-Fi started out very limited in advanced networking options, I was able to make this work by using the Guest network option provided, then allowing communication from the Guest network to my Homeseer server (and a few other devices just to be safe, such as my phone for Lifx config).

    This worked great, and I haven't had a disconnect issue in several hours now (it never got past 5-10 minutes before). This also saved me from having to use a separate Wi-Fi access point and trying to bridge them together using different networks/SSID's, a process I wasn't looking forward to since I wasn't 100% sure that would work either.

    However, although the UltraLighting plug-in seemed to work initially, now it doesn't (it won't even find the Lifx Z strip anymore, after repeated disabling/re-enabling, until I went back to the old way and joined the strip to my main Wi-Fi network again). I'm assuming it's only searching the subnet that Homeseer is on, and this is the issue. I even tried to pry into a copy of the HS database, and that turned out to be a dead end after realizing the object_data is all in binary...or it appears to be in hex, too complicated for my patience right now. I only landed here after finding the IP in the device record/UltraLighting tab, and that it's not editable. Many plans of attack to fix this, all failed.

    Since this is a well known Lifx issue, and the fix seems to be what I described above...

    Ultrajones--Could you please add an option to search other subnets? I recall you having this ability in UltraMon (which is another one of a few of your plug-ins that I've purchased), so maybe you could do it in a similar way? I think this would help you sell your plug-in a lot more as well, since anybody who knows of the Lifx issue and finds out about the fix, and that it won't currently with with UltraLighting, is probably going to let the trial expire and bail (like I'm forced to do now unless this gets fixed). Working Lifx Z strip overrides added automation for a strip that I have to continuously unplug/re-plugin, or add automated switches to do the job and wait the extra 5 seconds to turn the lights on.

    Thanks for the consideration, and please let me know what you decide. I believe I've got about 25 days left in my trial, so I'll need to see it working for several days before that ends, in order to decide to purchase it.

  • #2
    I have several LIFX Z's and I am not experiencing the issues you are reporting. My LFIX Z's stay connected to WiFi after installing a LIFX firmware update several months ago. I have 22 LFIX lights and none of them drop off the WiFi network.

    The LIFX LAN API requires discovery via a UDP broadcast packet which by definition only works on the local subnet. There really isn't a way to programmatically detect LIFX devices on a separate network using the LFIX LAN API.

    The LIFX HTTP API may work to find the bulbs, but I it does not expose the IP on the local network so I wouldn't be able to make a UDP connection to them.

    Regards,
    Ultrajones
    Plug-ins: UltraMon, UltraM1G, UltraCID, Ultra1Wire, UltraLog, UltraWeatherBug, UltraPioneerAVR, UltraGCIR

    Comment

    Working...
    X