Even if the app says that local communication is enabled, try disabling it for 30 seconds or so, and then turn it back on. New bulbs may not have gotten the message. Just to be sure we're on the same page about this setting, it's the one on this page:
On your hub, make sure the IP address is really getting saved. I've forgotten to do this a time or two -- after entering the address, you have to press the "Save Preferences" button, which depending on screen size, you may have to scroll down a bit to see.
To check if the device is visible to the hub, open a terminal (or command) window on your computer and ping the bulb's IP and the hub's IP.
(ping 192.168.xxx.xxx if you haven't done this before.)
You should get a response from both devices.
Thank you so much, it was the pinging that did it!
Turns out the bulb was connected to some secondary router connection helpfully called the save as the main connection. My bulb is now fully working - makes me wonder if those 'Wiz Connected'. bulbs would have worked after all!!
Thanks again!
@simon.ord, good detective work figuring this out! Glad you got it working -- I'd read elsewhere on the net that IoT devices sometimes have trouble dealing with multiple wifi networks with the same SSID, but it's not exactly the first thing a person would think of.
As an FYI, I reached out to Wiz to get the API and after getting it passed on to the technical people they say
We have received a reply in regards to your API request from our technical team. They have confirmed that at this point of time, we do not share API information as it conflicts with company interest.
They too suggest on reaching out via the Contact US option available on the Wiz website so your concern can be addressed much better or considered further.
Perhaps if others contacted support@wiz.world it would help. Or if there are better contacts.
This in sharp contrast with 小米 米家 (xiaomi mijia - Yeelight) which does document protocols.
I had the impression that a big part of their business model was selling their control software and cloud services to business customers. So it makes some sense that they don't want 3rd party vendors undercutting them there.
I'm just glad they do provide the UDP interface even if it's not well documented, because we've already seen quite a few cloud-based IoT companies with similar business models shutting down, charging for cloud service, or getting acquired by one of the data slurping giants. And personally, I much prefer the local network control option anyway.
We could have a separate conversation about business models. I just find it very risky to be at the mercy of a company who sees the empowered user as a threat. The protocol is out there in the wild but if they see openness as a threat then can do a Google and close the option.
Hi there, love this driver as it has worked for me for all my auto on/off rules.
however, i'm struggeling to manage to create a wake up routine - the effect nr is 9 but how to I trigger the bulps to that effect via rule machine? any ideas?
@ottomarwin, there's probably some arcane way to get rule machine to give a "Set Effect" command, but I've yet to figure it out. In this case though, you can cheat a little by using the mechanism I built into the driver to let the scenes app control effects. Just have rule machine set the color temperature to 6000 plus the number of the effect you want to run -- in this case that'd be 6009.
I'm new to Wiz devices, but I have used Rules Machine to handle non-standard things on my Lifx Z-Strip and it may be applicable. I think you can probably sub "setEffect" for "zonesLoad". Here's a link. Lifx Custom Solution.
On separate note, what is the reason that folks firewall their Wiz devices from internet access? I have a single device and don't expect to get anymore, it was an inexpensive candalabra format bulb.
I'm having problems getting start dimming/ stop dimming to work in rule machine, I'm doing it the same way with hue bulbs. I'm running v1.2.6 of the wiz driver. I have been trying everything I can think of. And I also can't seem to get set ip to work either... But everything else works perfectly.
EDIT: As noted below by the author set dimming isn't available for WiZ lights. I deleted the screenshot so no one tries to copy me by mistake.
Yeah, that's the issue: the "Start raising/lowering..." actions in Rule Machine run the startLevelChange() command on the device, which is not implemented in this driver (you should see an error in "Logs" hinting at this) and may also not be possible with what's been reverse-engineered of the bulbs' API.
The Wiz bulbs don't support the startLevelChange() command via either the local or cloud API as far as I've been able to discover, and I'm not willing to try to build it into the driver -- it would involve sending several commands per second to each bulb, which would bring the hub to a standstill if you had more than a couple of bulbs.
One thought on a way to implement it in the driver, would be to say dim/raise by 20-25% (or a variable amount) every half second(or full second) instead of trying to do a smooth transition. If you are only dimming a couple bulbs at a time, that wouldn't be too much for the hub to handle would it? But this method above had an added benefit of turning the light on if it's off. And how many dimming levels do you really need? So really this works perfectly.
I'm kinda new to hubitat obviously, at what point (traffic per second) does the hub bog down?
To get rule machine to setEffect (or speed, pulse, saturation, etc) you want to "run a custom action" , it's grouped with set mode and set variable. The other method the author designed is to set temperature to 6001 for effect 1, 6002 for #2, etc. Since the bulbs don't actually go above 6000k
@zranger1 I was thinking of adding address support to the Lifx drivers (or getting it added ), could you do a short write up on what you did to support address setting?
One issue I have is that messages get lost and/or bulbs fail to get IP addresses. It would be nice to mark the bulb state as "unknown" until you can poll to find out if the messages was processed. Perhaps you can do a shorter interface poll after sending a command to confirm the status. That the algorithm I use in my apps.
Dealing with temporarily disconnected or otherwise unavailable bulbs is an interesting issue. Even in my relatively small installation, people occasionally manage to flip the wrong physical switch and turn bulbs off, rendering them unreachable.
When you successfully send a command to the bulbs via UDP, it sends back a more-or-less immediate acknowlegment. The driver just isn't doing anything with those ack packets at the moment.
Give me a day or two to figure out the "right" way to report a device as unavailable. I'm hesitant to put anything like "Unknown" in the bulb's switch state because it's defined as an ON/OFF enum, and adding additional undefined values to a driver is very likely to break the big 3rd party integrations like Alexa and Google voice. It's happened before.
Is there a way to set the CT/RGB values of Wiz bulbs en masse? As it is, I have 15+ bulbs that I love to set scenes with (CT values of 6000-6023), but doing so sets them one by one, which takes a few seconds and looks kind of silly. I suppose it's sending the commands individually to each IP address, which takes time, but it would be neat if it could finish the job faster somehow? It seems to take the same amount of time whether it's a RM setup, a Group of lights, or a Scene.
), could you do a short write up on what you did to support address setting?
