The polling cycle each minute shows 1 UDP timeout - we can't directly correlate it to which packet the device did not respond to, but it would make sense if it is the GET_EXTENDED_COLOR_ZONES.
In your LIFX app on your phone, you can pull up the device details/settings - this will show you the firmware version and device type - we can start there, and compare to GitHub - LIFX/products: A JSON representation of the LIFX products to see if the extended MZ is supported on your device.
Okies thanks for this
From the LIFX app I can see the following -
I see a LIFX Z in the list as well.
For now I have reverted to the LIFX GoG driver for the Z bulb.
v1.22 - Does it say that your firmware is up to date? The products.json file indicates that 2.77 is required for extended multizone. I'll look at integrating the original MZ packets into the driver/app
The bulbs in our home that throw the most UDP timeouts have firmware v1.22. A while back I reached out to LIFX support to alert them that some of the bulbs were stuck on firmware 1.22. Their response:
"Your lights on v1.22 are Generation 2 products. The latest firmware available for that generation of products is 1.22. We have stopped making/selling Generation 2 products for a while now."
Always a bit sad when some products get left behind.
On the whole, your v1.22 bulbs should work fine - the UDP timeouts are because of the hubitat driver sending a message that the firmware doesn't understand. I've made some progress on integrating the original MZ protocol, but hit a few snags - namely trying to synthesize multiple responses into a composite MZ status, since the original protocol reports only 8 zones at a time
has anyone got a lifx z strip working on lan with standard hub motion lighting rules? i have been using groups to get it working.
The motion lighting app simply doesn' turn the light on when using the local lan device (multizone). If you turn it on it will turn on but if you use "setlevel" in the lighting app it doesn't work.
Testing this if light is off and you click set level in the lan device it doesn't turn it on - the light must actually be turned on via the device control.
Good point, this behavior is inconsistent with the other bulb types... Will look at fixing this - the same applies to all of the other methods that apply attributes across all zones.
thank you. happy to test (I have 3 z strips - love them!)
PR: MZ Fixes by dkilgore90 · Pull Request #87 · robheyes/lifxcode · GitHub
Tested on my Z strips and appears to work as you described now. LMK if anything seems off.
Note this also includes a fix for an issue where multiple zone changes within a single polling cycle (1 minute) would overwrite the previous change, even if that zone was not specified in the last change
thanks. I updated both the lifx app and the mutlizone.
however now my GU10 lifx lights are no longer responding to motion lighting.
Originally i had trouble with them and after discussing it with hubitat team found I had to do this:
However now they don't respond with these settings enabled or disabled.
Also the lifx z strip is not turning on or off with this new code either - its working directly tho within the app but not via motion lighting.
i'll keep playing with it.
EDIT: well it was some other issue with Gu10s. they just randomly dropped (just a few of them).
anyway lifx z strip is not working with this setup. so it worked on your tests with motion lighting @dkilgore90? thanks for the quick reply on the change tho. much appreciated.
@joel_dj I tested from the hubitat device page, which was working, as you saw. I don't have any motion lighting rules in my setup, so maybe there is something different about the trigger/action there that needs to be accounted for. Any logs from the device or app? Otherwise if you could share a rule or 2 from motion lighting, I can plug something similar into my hub.
curious what do you use for lighting? just rule engine?
here's the one that was not working when used with the z strip
Same results on several motion lighting rules.
I removed the code but will re add it with your go ahead and provide logs then
yeah, primarily Rule Machine to tie different devices together - compared to most folks here, I probably have "Home Automation Lite" - or as my wife puts it, I don't just "automate for the sake of automation".
I did push a small fix to set the duration in the LIGHT.SET_POWER packet correctly - but I don't think this would have impacted Motion Lighting. I then retested with Motion Lighting - and it appeared to set the level (and/or color) and turn on correctly per the current mode. I'll note that my hub is currently on 2.2.1.113 - haven't updated to 116. Enable debug logging on your Z Strips for the test, then we will be able to see the byte arrays for the packets sent by HE in the logs.
ok cool. should I re grab drivers again from here: MZ Fixes by dkilgore90 · Pull Request #87 · robheyes/lifxcode · GitHub @dkilgore90
I ask as I'm not seeing any changes to the code except comments
Yep - same link. Last commit was 3 days ago, but didn't get to test until last night.
if you enable debug logs on the multizone - where do they appear? under the events list on the item.
I may have spoken soon as one of them didn't turn on just now. but it did work once.. which is odd
makes sense.
so they have been running well since. not sure what happened with one of them but it was a once off. thank you again
Download the Hubitat app
