There is a custom setScene command, but of course it currently uses scene names. I can make it accept numbers between 1 and 32 if that's the ask.
In a way that is the ask. So we can increment through the scenes instead of bing so specific.
FYI - Disabling the integration, once it's been enabled, does not work.
It says it's disabled, but it continues to run detection and create stub devices, and then is very unreliable - creates all kinds of odd conditions in the hub, including non-responsiveness.
lots of these in the logs:
@gopher.ny does the wiz integration utilize local functionality. Maybe that'll allow them to turn on and off immediately as a group?
Is anyone having performance issues? It seems that when I have a list of commands issued, it takes a very long time to get through. If I set a bulb to "on", then set the color, then the brightness, it could be up to 8 seconds (for a pair of bulbs in the same fixture.
Are the commands sent sequentially? Are they blocking?
That's the exact issue I'm having on HE. Takes several seconds for them to turn on and off. Not the case in ST, Alexa, and GH which immediately turn them off too. A second at most. I've tried grouping them and still an issue...
Going to test out my lifx and kasa bulbs. 
See if they have the pop corn effect. Really want to make it workout and move over.
Did you have the same issue with the community driver? Mine performed faster with the community driver, but are more reliable with the built-in driver.
Lifx is expensive, if I remember right. If I go to replace mine, it'll likely be for sengled (zigbee). The ones I have I really like. The only issues I run into with them is that I might need to power cycle them after my hub was rebooted. Ikea has also been working well for me (just the bulbs though, not the buttons or motion sensors).
Yes.
This is to be addressed in the next 2.3.3 update. Found a place where commands were unintentionally queued up.
3 Likes
Sounds promising. I look forward to testing it out.
Please try 2.3.3.126, just released.
All of my bulbs were correctly identified (the stub devices were corrected).
The performance seems normal now too.
Thanks for working on it so quickly.
2 Likes
Just downloaded the new firmware and it looks like 127 does not include a method to increment through the scenes. I am not sure if that was intended to be in but thought I would bring that back up.
Yes, 126 build had an issue and was very quickly superceded by 127.
Scene setting method is on the list, just didn't make it into this build.
1 Like
New fw x.127 broke the connection for wiz lights in webcore, motion lighting app, and room lighting app. Motion sensor events weren't triggering the bulbs any longer once I updated. I ended up removing all the devices one by one, and disabling integration (disabling it doesn't remove the devices), removing the app, rebooting, and then reinstalling app and running discovery.
It still doesn't actively pull in the correct device type upon discovery. Just leaves it as a STUB, and oddly not all the lights are STUB. Only half of them. The other half pulled RGBW. Some of my bulbs aren't' even being discovered. I'm missing 3 so far from discovery. Should I downgrade for the time being?
Also wiz integration doesn't pull in the label that's set in wiz. Not sure if you mentioned you were going to look into it setting the name on discovery.
I'm not sure I fully understand. Did the device get replaced? I've previously started putting all of my bulbs in variables to make them easier to swap. It worked really well for swapping from the community driver to the built-in driver.
Can you pick two (one of each) and see what the moduleName field is under "Device Details"? I'd wonder if slight differences in the bulb's firmware might cause that.
Hmm, just found one that I can no longer control with Hubitat. It seems to work within the native app. I can ping the bulb from my PC.
I deleted it and re-discovered it, and it went back to being a stub. After doing what I did before (just changed it to a WIZ RGBW bulb), it looks to be in the same uncontrollable state. Interesting. I might change this one back to the community driver and see if it works there, or try to get the python app working.
Update: works with the community driver.
What is the moduleName value on devices that are left as stubs?
Can you PM me the hub id? I'll check the engineering logs.
Noted. I haven't seen the name being returned in usual responses, but I'll check for other ways to pull it.
Can you PM me your hub's id and the device that lost control? Same thing, I'll check engineering logs. Still fine tuning the integration.
I saw an update was available this morning. After running the update, it looks like the lights are working.
1 Like
So I jumped headfirst in migrating to use this driver after the update to increment through scenes.
It apperas that this really doesn't play nice to a device that restarts after the integration has been established. I had a heck of a time getting two devices to start working I ended up doing about 3 restarts of my main hub but eventually everything came online. I had one more bulb to put out for holiday stuff so installed it and moved a bulb. The bulb I moved will not come back online. How should this integration work with a device that goes offline due to a power loss and then reconnects.
Can you PM me your hub's id? I haven't experienced this, but looking through the engineering logs on your hub may help find the source of the problem.
