[EDIT TO DELETE OF BUNCH OF STUPID TROUBLESHOOTING I CLEARLY DIDN'T DO]
Skip to here:
Is there anything in the device driver settings that imposes an upper limit?
Not that I can see...and it works fine if I set it to 85% using Rule Machine.
I personally prefer using RM to the Button Controller app since RM can do so much more! I just preface the Rule name with “Button - “ so they are all together.
Something to try in case it works better for you. 
In case you are not aware, here is how you activate the Button Controller functionality within RM:
And follow the instructions...
It's weird that RM would work when BC doesn't; otherwise, my first question would be what other apps are using these devices and if anything could be interfering (and because you're using Hub Mesh, you'll need to check the "In use by" section for the device page on both hubs to figure this out). I just created a test BC instance with a virtual dimmer that dims to 85% on button 1 pushed of a virtual button, and it worked as expected, so I'd still strongly suspect there's something going on with the device. But then there's the issue of why RM or the device page seems to work and BC doesn't. That being said, RM with a "Button Device" trigger, as suggested above, isn't a bad way to do things, either, and gives you a bit more power. (And nearly the same interface.)
1 Like
In the next release there will be some further evolution of this Button Controller thing.
As to the case in point here, the code used in Button Controller 3.1 and Rule-4.1, including the 'Button device' use thereof, are virtually identical. The only difference is the option in the latter to insert a variable for the level or rate to be set, a feature not available in the former.
So I daresay there is some other cause of this problem, not the app. You can see the setting for the level in the Settings section of the App Status page.
Methinks you mistake the cause of this "quickly drops" thing. Something other than Button Controller is doing this. Have you looked at the device events from the device page?
1 Like
Forgive...apparently my testing skills were non-existent yesterday but at 6am this morning much better.
So now in my testing...I see that the FIRST setting of this light does not work. Aka the setLevel 85 turns on the light and sets to 50%...if I set it a SECOND time I get 85%.
This however is repeatable even on the device page. Meaning if the light is off and I'm on the device page and put in 85% for the level and hit setlevel the light turns on and level is set to 50%. A subsequent hitting of setlevel will then set the light to 85%. This is regardless of hub mesh and happes on the hub directly connected to the lights and is very repeatable.
This light:
This driver: Generic ZigBee RGBW Light
Few questions.
What driver did Hubitat pick when the device was first included.
If it wasn't generic zigbee rgbw light, did you click configure after changing it?
Are you sure the actual strip level is 50% the first time you set it to 85%?, meaning do you see a level change when you send the second set level command?
generic zigbee rgbw light
Nope...and you sir are correct. It was really hard to tell with this particular light but after the FIRST time of setlevel it does seem to go to what it's set at. If I hit "refresh" after the command it then updates the level. So to summarize. If the light is off and current level is 10. If I issues a setlevel with 85. The light turns on and the current state "level" shows as 50. Then if it hit "refresh" the current state of level goes to 85.
Although the light really does seem to do some kind of ramp up and back down when it first turns on...very hard to explain.
Also if I issue a setlevel 85 with a duration of say 30. It is no different than without the duration. It just turns on the light and sets it. I've tried different amounts of seconds and always it behaves the exact same. This is right from the device page.
Do you have a way to update the firmware? These strips, like all Sylvania lights, come with the original three year old firmware for no extra charge 
I can’t say that will fix the issue, but I haven’t noticed this problem with mine.
Ok, there seems to be some funk in the way this device reports, anyway, you can try the Advanced Zigbee RGBW Bulb, maybe it will work better with this device.
Be sure to click configure after changing it, this driver runs a test routine, give it 5 or 10 seconds to finish before testing it.
I do not. Do you? I thought the lightify gateway was gone? And I no longer have a ST hub. 
100% yes!! Thank you! So far works as expected with that driver.
I can now properly see what I'm drinking again. 
(yeah it was THAT important)
2 Likes
Yes, I still have both. I haven’t used the Lightify gateway in a while, but thought it was still up until later this year. I wouldn’t buy any more Sylvania lights without a way to update them. The original firmware had issues. My favorite was the bulbs would reset when dimming up if they were already at 100%. That was a real pain when dimming a group of bulbs.
So if I could find a gateway then I'd still be able to update them?
I’m out of town so can’t double check to make sure. @danabw or @adamkempenich Do you know if the Lightify gateway is still working for updates?
Hold off on the gateway purchase, 2.2.7 will include zigbee ota updates, and we have all the Osram and Sylvania firmware files that they have made available.
I cant guarantee there is an update for this specific device though.
8 Likes
Christmas in July?!!?
Thanks!
1 Like
If it’s Ledvance, then all devices are using the same firmware last I checked.
This is freaking amazing 
3 Likes
This one is Ledvance. I have two others. The first one for sure is the older Osram. This newer Ledvance one does work for me on the Advanced Zigbee RGBW Bulb. The older Osram worked fine with the Generic one. I tested all of them to see.
If my whiskey barrel lights were worth anything it's to find out zigbee OTA updates are coming
