I only have 4 Lifx+ but they are pretty happy with Hubitat when using the app and driver on this post.
Great thank you - I shall get a Hubitat ordered.
1 Like
I recently installed this for my Hubitat that I just bought, but I am having trouble getting the "duration" setting to work. First I will mention that most everything else seems to work good and I am very thankful this 'plugin' exists!
Next, I am using this with the latest firmware on the latest version of the z-strips, 2.77 I believe it is. So they support the newer "extended zone control," which I think is apart of the code for this project anyways, but I'm not entirely sure yet if this is relevant. However I noticed that the 'SetColorZones' command is what seems to always be used when I send commands and not the 'SetExtendedColorZones' which looks to be more efficient at first glance on the LIFX website; regardless both support the 'duration' field.
If I change the driver I am using from "LIFX Multizone" to "LIFX White," the duration setting there works okay. However, of the different things I've tried for the "LIFX Multizone," it hasn't worked once. I've found where it's located in the code, but despite manually setting it in the driver code or setting it in the 'device control panel,' it doesn't seem to include it in the code sent to the z-strip. I'm including a couple pictures for illustration. If anyone has any helpful ideas, I'm all ears. If it's something simple I'm missing, I apologize; I don't code for a living yet.
Also for a side note, on line 269 in "LIFX Multizone" I modified the 'level' variable to include '.toInteger()' because decimals do not work when entered otherwise, and when this driver is used in conjunction with webCOrE, webCOrE always post the brightness level in decimal format.
I can't seem to upload pictures or a link, so I suppose copy, paste, and remove the "{dot}" from the 'link' below to see the screenshots on Imgur.
imgur {dot} com/a/rL4KpJT
Regarding "duration" in the MZ driver, there is a PR open to address this - conversion from seconds to milliseconds was missing.
For the extended multizone packets, the driver is intended to intelligently identity whether the device supports it, based on the firmware version >= 2.77. Do you see a firmware value in the "state variables on your Device page?
Great! Thank you for the help, that's exactly what the issue was; I'm not sure how I didn't recognize that, but I wasn't looking for the time conversion, so that's probably why.
Also it turns out that the 'events' page doesn't show the "duration" information either way, so that wasn't helpful.
As far as the Extended Multizone packets go, at this point it may be using them and I'm just not able to tell. I thought the info on the events page was more accurate, but maybe it's just generalized information.
-I know that my firmware is 2.77, however if I use the initialize button to get it, it returns "firmware : null" on the right side of the screen. However if I scroll down to the bottom of the "state variables" section, it does show 2.77.
I have the debug logs enabled, but I'm not quite sure where to find them. If I click "logs" on the left side of the page, I see only a couple entries concerning that device driver and they don't seem to be helpful. I'll include a picture. If I click the "debug" button, in-line, it just takes me to the device.
imgur {dot} com/a/e4DktMU
Ha -- yeah, some of the debug logs are essentially the raw byte array of the packets being sent. The one ending 255, 1, 0, 0 is the GET_EXTENDED_MULTIZONE / packet id 511, in little endian -- so the driver has recognized your strip as capable of the extended MZ
Thanks for your help!
I've merged that pull request now.
Are your LIFX bulbs working yet?
I am in a similar situation.
Hub not arrived yet, still in transit
Hub arrived and setup OK - LIFX integration setup fine - 1 issue, if I add a bulb to the dashboard and click on the tile I can't close the popup. Any ideas anyone ?
No ideas -- happens to me here and there, I usually end up just refreshing the dashboard manually to make it go away
Yea refresh get rid of it - bit of a pain tho 
For those with the new Candle White bulb, its a straight forward white bulb, so using the LIFX White driver will work.
Just alter the LIFX Master app, line 1581 states:
case 10:
Add a new line below that and add:
case 96:
The new bulbs have an ID of 96.
So it should look like:
case 10:
case 96:
return [
name : 'White 800 (Low Voltage)',
deviceName: 'LIFX White',
Rediscover and it will work.
3 Likes
Heads up if you use the MZ driver with child devices per zone: seems the code that updates children is broken by the latest HE Update (2.2.4)
I don't have any zones set up in LIFX (and haven't noticed any problems with the bulb I rarely use in the first place), but I just wrote a minimal driver where I did something like this:
device.updateDataValue("testVal", "123")
and later
def x = device.getDataValue("testVal") as Integer
and then log.debug x printed 123 as expected. Additionally, I did a call to a method that I know not to exist:
blaaarrfff(x) -- a trick I learned to ascertain the class of an object since there are few other good ways to do this in Hubitat's sandbox -- and it logged out:
[error] groovy.lang.MissingMethodException: No signature of method: user_driver_XYX_012.blaaarrfff() is applicable for argument types: (java.lang.Integer) values: [123] on line...
...as expected, confirming both that the object is an Integer and has the expected value.
So, something else must be going on here. Does the data value exist on this device, and it it something that can be converted to an integer? My guess is that something is going on with LIFX rather than a platform change (I don't remember hearing anything about one that would affect this, though anything is possible). If you're interested in testing whether it's really 2.2.4 that is the culprit, you could try downgrading to 2.2.3 (use the diagnostic tool), seeing if the problem goes away, and seeing if it comes back if you re-upgrade to 2.2.4. Otherwise, maybe the LIFX author may see something elsewhere as these particular methods seem OK to me.
Sorry that this isn't super helpful--just wanted to show that the methods work as expected for me in a minimal example for the sake of having more data about the issue. Hopefully something gets worked out, whatever the cause!
Hmm thanks for the feedback - I'll play with it some more tomorrow... I actually wrote the child device code for multizone myself - and only ever "set" the data value to indicate the zone number during child device creation -- not using updateDataValue. Maybe I was exploiting a corner case that wasn't officially supported?
Another possibility, of course, is that a power blip this morning corrupted something on my hub - but it seems to have occurred with all 3 of my multizone strips... Seems like an odd coincidence. Anyways, I'll update once I know more!
Hmm, I've never tried setting the data value during creation, but if it works to actually create the value (as it appears to from your screenshot), I'm not sure why the rest wouldn't work. I can say that the device and driver docs both say that updateDataValue() will create the value if it doesn't exist, and that's what I used in my testing, so I'm not sure if something might be different with having created it that way off the bat (or maybe with it getting confused if "0" is returned, even though a string with that value is pretty unremarkable?).
FYI -- HE staff confirmed the bug affects child devices (probably why your test didn't see an issue):
1 Like
