Lightify Firmware Updates?

WB, it was on… would you mind giving me a brief synopsis of what im benefiting from turning it off?
thank you sir

Device health has been known to make some devices unavailable when turned on. Don’t know the reasons why, but there are miles of posts about it causing conflict in some people’s environments and after turning it off, those devices become responsive again.

Here’s the full blown on the Device Health feature. It isn’t going to hurt you to turn it off and then back on at some point. You can perform it as a test to see if your devices come back to life.

thank you… Ultimately it did make the devices at least respond again :slight_smile:so thats good.

However, the bigger of the issues I think is that my 13 outdoor lights dont all respond together when a script is kicked off with webcore.

So i have two scripts

  1. blue and white christmas lights (alternate blue and white)
  2. xmas lights (alternate red and green)

telling google to go back and forth often allows 10 or 11, maybe 12 or 13 of the lights to work. but most often at least 1 or 2 of them simply dont change colors. so while i can then manually change it in the app (often) a holiday display doesnt quite look good when one light is off…

One problem at a time. So did that fix everything with all the Lightify bulbs? If so, then leave Device Health off for now. They are continuing to make improvements to it. Also, if a new ST app update comes out, make sure that device health remains off. We think that the mobile app updates have been defaulting the device health to be turned on by default.

So for your other issues with webCoRE and Pistons, I’m not going to go there. I don’t have any of these issues with my Pistons. Are all of the lights that you are trying to control through WebCoRE able to be turned on/off independently from Things in your ST app? If so, then you will need to figure out what is going on with your Pistons / Routines / Scripts.

You did perform the Zigbee heal earlier (full power down) and that could take up to 24 hours to fully heal, so you might want to just wait until tomorrow night to run the Xmas lights. If all lights are responding, then that’s a good thing so leave it alone for the night and see if tomorrow the heal allows all the lights to respond and flip colors the way you expect them to.

well, im not 100% sure it solved the issues of unresponsive bulbs. It did solve the unavailable stuff, but thats naturally what the health is going to do. Even with some bulbs being unavailable previously, they could sometimes be controlled in ST manually.

The pistons are extremely simple in that when i say “turn on the christmas lights” it runs 2 lines.

  1. If IFTTT runs christmas lights.
  2. then change bulb 1, 3, 5, 7, 9, 11 to blue
  3. change 2, 34, 6, 8 , 10, 12 to white.

thats literally it… Its just so bizarre that the lights furthest from the hub, seemingly have fewer issues than lights closer to the hub, so i dont think its a range issue.
Again, i cant be sure of any of this, but it appears that way.

I absolutely appreciate you taking the time to assist me. it means a lot. thanks

editL the zigbee heal was done a couple days ago…

Why are you doing this through IFTTT?

simply for the voice activation of a group of bulbs.

If i can get half the bulbs to turn on to 40%, blue, etc without calling it via IFTTT than im all ears. I can get a single bulb to react with google home but not a series of them… unless of course im missing something.

Ok so give me a full run down of everything that you have set up so I can understand what you are doing from a to z, in the order that everything happens so I can follow what the ended intention is, then I and others can recommend a different approach minus IFTTT.

Ok… here you go.

  1. set up the bulbs and updated firmware (which was hard enough). 12/13 FINALLY got it… one that didnt is not hooked up.

  2. ST finds them without a hitch.

  3. Added those things to webcore smart app.

  4. created the piston here

  5. Created the following applet in IFTTT

  6. “ok google, blue and white christmas lights” triggers the webcore to run the piston which essentially turns half of the lights blue, and half white.

Really simple piston of course.
Anything else you need to know?

I have Alexa, so it’s much easier to go about integrating Routines from SmartThings and executing them. But if I had Google, I would go about this slightly different in that I wouldn’t use a web hook with a web request.

This is how I would go about it:

  1. Create two virtual Devices in SmartThings
  • One called Blue Lights
  • One called Red Lights
  1. So now for the IFTTT Applets instead of a web request as my action service, I would turn on one of the two virtual switches in SmartThings.

  2. I would then modify my Pistons to run IF the Blue switch turns on, removing IFTTT. I would then add an additional THEN DO that turns off Red Light Switch, and then the rest of Piston does what it does with setting the colors to blue/white. I would then modify the other Piston for when Red Virtual Switch is turned on and THEN DO turn off blue switch, and then set the bulb colors to the red / white combo.

  3. I would then create two Applets with the same thing “turn off Xmas lights” and one turns off blue switch and one turns off Red switch.

Yes, you are still using IFTTT but you are using it as the front end piece to simply turn on the virtual switch, and then your Pistons are firing against SmartThings device state changing. I’m not saying that is going to resolve any issues, but from a timing perspective, this logic works better for me. This is my personal approach and it may or may not help improve response time.

Others might have other suggestions or recommendations for you or chime in that they have experienced something similar with that number of bulbs being set at the same time. If you don’t use my recommendation, play around with your existing setup and do like 6 lights in your setup based on the closest lights first and testing them to see if they all come on and change to the correct colors and then perform the same test with the bulbs furthest from the hub. Testing and trying combinations of things to troubleshoot and figuring out a combo that works for you. :slight_smile:

never created a virtual switch before, so ill have to muddle my way through that… ill see what i can do.

There are a ton of threads about how to do it. @JDRoberts might have a very specific thread to use that makes it even easier for you.

i think i can use simulated RGBW bulb. ill test that :slight_smile: thanks WB

1 Like

I might. :wink: ( This is a clickable link.)

1 Like

So instead of a virtual switch… i wanted to test as you said.

  1. Create the piston to turn on 5 bulbs only. closest to hub.

so first try all 5
second try 4/5
third 5/5
fourth 5/5

so still not perfect. im really hoping the lightify gateway fixes the issues, but we will see i suppose. really dont want to send back 25 bulbs haha.

1 Like

Ok… after screwing with these things for 3 hours my consensus is

  1. The osram bulbs are garbage.
  2. The range on the gateway is garbage
  3. The Overall integration with smart things is garbage.

There is not one redeeming quality about these bulbs except the price tag.
At this point im considering sending every single piece and part back, which includes the gateway and 13 bulbs. Just not worth the frustration.

@Ryan_LaBarre I have orsam bulbs and there great had a few random issues untill I updated firmware but after that great! If you want lots of lights to work together you need trendsetter it’s perfect for that.

Take a look

just finished working with that. didnt fix the issue at all . still horribly inconsistent when bulb grouping in any way :frowning:

Reach out to support as this isn’t a common issue, you may have a issue with RF and need to move to a new channel.

support is non existent for these bulbs… ive tried… id rather spend 2x as much money per bulbs and have something that works, and has support vs zero support and a flaky bulb… but thanks for your help on it