I’ll take a look at the api and update.
Can I ask why you are using z wave switches to control a bulb that is already smart?
Usually smart bulbs are installed on dumb switches and left in the on position. Then controlled through automation rules. Installing a smart bulb that’s connected to a z-wave switch seems redundant. Just curious with reasoning there.
Sure. The smart bulbs are connected to smart switches that are wired hot. In other words, no matter what off/on state of the switches, the bulbs still get power 24/7. Then the switches are programmed (as above) to send commands to the bulbs. So this gives you smart bulbs with the same physical control on the wall as you would have if you had smart switches. So that explains why smart switches … but why smart bulbs? For colors, mainly - and also granular control if, for example, you want to have only a few bulbs from a certain room on.
I have a test branch with the “fast” feature included. It can be disabled via the settings of the device. So far no issues for me, but I’ve only been testing for about 30 minutes.
What’s the “fast” feature?
Sorry, I should have explained.
The API is designed to ensure consistent transitions for devices from one state to another. For many operations, this involves having an accurate view of the current state of the device before taking any action, so we need to ask it for its state first. Other transitions, in order to be smooth, require intermediate state changes; for example, to switch on and set to blue a light that is off and set to red, we first switch it to blue, wait for that to succeed, then switch it on, to avoid jarring transitions.
As this involves various network hops to the device, this process is slower than many traditional web APIs. There are use-cases where this is unnecessary, for example those in which the client has a pretty good idea of the current state and just wants to send one state change message to the device.
To speed things up for such use-cases, when setting
fast=true
, we do none of checks described above, and just send the targets the end-state messages. Because we don’t wait around for a reply from the device in fast mode, you’ll just get202 Accepted
with no body if your request was valid.
So far I haven’t had any issues and things seem to be a bit faster. That said my LIFX performance has always been good (since upgrading my wifi over a year ago). Right now I have the fast setting turned on for almost all actions:
on/off
set level
set color
set color temperature
set hue
set saturation
all transitions
Not sure if this is an issue for everyone.
Fast has been fine on my end since my last comment. Though I’ve only done on/off and dim. I don’t think the speed is related to WiFi. I think it’s more related to response time on their end, but I couldn’t say for sure.
No, not related to wifi. Basically how it works is that they don’t check the status of the bulbs before sending the command. They also sometimes send back a 202 response now (instead of always 200) meaning the command has been receive but may not have finished processing. I need to test a bit more and update my response handler as part of this.
Anybody have any idea why i’m constantly getting this in Alexa’s ST logs regarding LGoG lights?
1:39:26 AM: warn percent value of 237 is outside range of 0 to 100
I don’t get those messages. What version of the DH are you using and what tells you it is LGOG?
I’m using Version 1.3.7 and if i remove LGoG lights from alexa the message disappear from the logs…
@whoismoses Eric sorry to bother you and sorry to post on the wrong thread if this isn’t the area to be in. I’m trying to find more info on the Better LIFX handlers and wondering what’s the difference between Better LIFX Bulb and Better LIFX Bulb Plus.
https://github.com/ericvitale/ST-Better-LIFX-BULB/tree/master/devicetypes/ericvitale
I’m stumped on this one. Have LIFX bulbs and noticed last night they got different handlers so I put them all the same using the Better LIFX Bulb handler. I’d already had some set to that handler and worked fine. Noticed this morning the one bulb that was still using LIFX Color Bulb handler wasn’t coming on via routines or app control but still worked via Alexa and LIFX app. I put the handler back to LIFX Color Bulb handler and it suddenly works. You’d think maybe there was an issue with handler or something, but it’s working fine for other LIFX bulbs I’ve got.
@cyberrage - Not sure what to tell you. The device can’t have a level greater than 100. I have Alexa and no such messages on my side.
The only difference between the Better LIFX Bulb and the Better LIFX Bulb Plus is that the “Plus” version is for the LIFX Plus Bulb that supports the IR settings.
Are you LIFX bulbs integrated with Alexa via SmartThings or the standard LIFX integration with LIFX + Alexa?
They are integrated both ways - integrated into SmartThings plus Alexa picks them up. I don’t have the LIFX skill enabled but she still sees they’re LIFX bulbs. I don’t have the IR bulbs. Just thought it’s weird this one bulb won’t allow me to use the better handler you created but others work fine with it.
It should work for any bulb LIFX buld. Are you sure you are setting the name exactly in the properties?
What do you mean setting the name exactly in the properties? I’m not sure how your handler works but does it tie into LIFX API or something? Because I do have a different name for bulb in LIFX app compared to what’s in SmartThings app. I changed it in SmartThings app not long ago but never changed in LIFX app. My question would be then why does LIFX Color Bulb handler still work? Thanks for your help.