I mean with other types of lighting devices if you have any.
Presumably you can control the lights correctly from their own device page?
I have the same issues with log error messages. All devices show up on my router (Amplifi mesh, which is the same subnet my Hubitat is connected to), can be turned on and off via the Lifx app, and work fine when being controlled by Webcore or directly from a Hubitat dashboard.
I've assigned all my devices (13 of them, I believe) to static IPs with long TTLs.
Maybe, instead of a 1 minute ping, could you aggregate a failure count and ping every 40 seconds, and only show an error once the threshold has been reached? That could lead into notifying users when a bulb goes offline as well instead of scratching your head about an automation that doesn't trigger for days.
On a side note, since moving from ST to Hubitat (a couple months ago), I've also noticed that, occasionally, Hubitat (and correspondingly, Alexa, Webcore, and anything else) will think a light is off when it absolutely isn't. Power cycling a bulb does nothing. I have to manually turn it off and back on for it to properly recognize state. This happens quite often with Z strips, but I've had one bulb that's exhibited the same behavior. It's almost like the local ping doesn't update the status (if changed) when controlled by an API. But it seems 100% arbitrary.
Hi, does anyone know how to turn off logging for LIFX Master? My Hub's database is growing out of control and I believe this is one of the contributors.
I've double checked that the logging is disabled on all my lights yet I keep getting spammed:
@rob I understand that you provided the below workaround in the past but I couldn't find that code on line 64 so I was wondering if you could tell me where I can find it please?
The code shown is for LIFXColor.groovy - which should be in Drivers Code - all the LIFX groovy files have similar.
For LIFX Z Strips try playing with the orientation of the controller, I gather that has an impact on WiFi reception, particularly with the first version.
If I remember correctly you can't turn off that warning with the current code as it doesn't come from the drivers directly, but rather from sendHubCommand.
However, you could try editing each of the drivers and looking for the sendPacket() function and changing it to:
private void sendPacket(List buffer, boolean noResponseExpected = false) {
String stringBytes = hubitat.helper.HexUtils.byteArrayToHexString parent.asByteArray(buffer)
sendHubCommand(
new hubitat.device.HubAction(
stringBytes,
hubitat.device.Protocol.LAN,
[
type : hubitat.device.HubAction.Type.LAN_TYPE_UDPCLIENT,
destinationAddress: myIp() + ":56700",
encoding : hubitat.device.HubAction.Encoding.HEX_STRING,
ignoreResponse : noResponseExpected,
parseWarning : true
]
)
)
}
ie add the parseWarning: true line
This should stop the warning being logged automatically.
You'll probably also need to edit LIFXMasterApp.groovy, and either remove the default branch of the switch statement or add the following case before the default statement:
case 'error':
return []
1 Like
Is there a way to set a transition time (for fading on/off) with LIFX Z strips?
When trying to test this in the Device page by setting a level and a duration, I get the following error:
groovy.lang.MissingMethodException: No signature of method: static java.lang.Float.parseFloat() is applicable for argument types: (java.math.BigDecimal) values: [2.77]
Possible solutions: parseFloat(java.lang.String) on line 218 (method setLevel)
(EDIT) I'm using the LIFXMultiZone.groovy driver
Interesting... This error is actually coming from the firmware check to determine whether the strip supports extended multizone packets or not (fallback to packets that set 8 zones at a time).
Just checked this on my hub, and I don't get this error. One thing I'll note is I've been lazy on updating my hub software, still on 2.2.7 - not sure if the typing in the state map has changed in recent releases, causing this error? It expects that the state.firmware entry is a string, and tries to convert it to a float for comparison.
To be compatible with either a String (which it seems to be on my hub) or BigDecimal (on your hub), line 218 can be changed to:
Float curr = new Float(state.firmware ?: 2.77)
Submitted a PR for this change: https://github.com/robheyes/lifxcode/pull/117
Thanks!
I am on hub version 2.2.9.129
I've tried your pull request and it does indeed fix the error. However, I still can't get it to set a level. It seems like any setLevel commands I issue act as a simple switch on/off. If I set level to 0, it switches off. Any other level above 0 it switches on. But it doesn't actually set the brightness/dimming level. On top of that, if I use a transition time, it does nothing.
For reference, this is what I get in the logs if I try to set the level to 50 with a duration of 5 seconds:
2021-10-09 10:51:21.464 pm debugSending buffer [42, 0, 0, 52, 68, 76, 69, 72, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 117, 0, 0, 0, 255, 255, 64, 75, 76, 0]
2021-10-09 10:51:21.419 pm debugSending buffer [188, 2, 0, 52, 68, 76, 69, 72, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 254, 1, 0, 0, 136, 19, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]`
2021-10-09 10:51:21.311 pm debugSending [colors:[:], index:0, apply:1, duration:5000, colors_count:null, zone_count:null]Hmm, seeing that the zone_count is null, it seems that the multizone polling has not successfully saved the state yet - so we don't know how many zones to set. I need to go back and review the LAN protocol to see what better options there may be, but this will impact any command you try to send, whether hue, saturation, brightness, or kelvin.
1 Like
Thanks for your help. Seeing your reply made me rhink maybe the device was not configured properly after the initial discovery.
I tried removing and resetting the device and starting over. The multizone state would still not be set, but then tried clicking “initialize” in the device page in Hubitat and that seemed to set the multizone state.
All commands are working now.
Not sure if there is a more robust way to handle the initial multizone polling, but wanted to report back that everything is working for me now.
Thanks again!
I'm getting this error for my multizone light strip when trying to set it. Is this the same error being discussed above?
Looks a bit different... can't put my finger on it just now, will dig around the code a bit and try to make sense of it. Can you confirm the version of the App/Driver's you are using when the issue is reproduced?
FYI...The built in Lifx integration is now available in the latest version. Check out the release notes here:
4 Likes
Just curious - can anyone share some insight on how the new built-in differs from @rob's integration? Additional capabilities, better performance?
Holy frijole!
1 Like
yeah would like to know the difference. rob's works great.
@rob has been part of our beta group and he may be able to explain better the difference, next time he is around.
3 Likes
It's definitely a lot faster than mine, with far less popcorning.
And that's with the LIFX integration running on my dev hub, using Hub Mesh to access the devices on my main hub, so it's likely that with everything on the one hub it'll be even faster.
4 Likes
