[Release] Philips Wiz Color Light Driver

I haven't played with the Maker API yet, so I don't know what would cause it to generate a notification or not, but I've got a project on my list that requires it, so I'll start looking!

BTW, when I screw bulb in while listening I see

{"method":"firstBeat","id":0,"env":"pro","params":{"mac":"a8bb50c1f6e3","homeId":704603,"fwVersion":"1.17.1"}}

I'm now thinking about using the lights in production. Does Hubitat give a way to get an IP address from a MAC address so you can use a stable identifier?

Also I noticed two places to set the IP address. Which is "correct" and what is the difference?

The "IP Address" field in the device preferences is the correct one. The Zigbee Id field should be left blank, though it doesn't affect this driver's operation in any way.

As far as I know, the Hubitat doesn't have a direct way to get IP from MAC address, and if it has a way to automatically track a LAN device through IP address changes, I haven't seen it. (I'd love to be proved wrong on this though. It'd be super handy!)

I keep LAN addresses stable by installing the device, noting its MAC, and making a reservation for the device on my DHCP server. This is a little tedious if you're installing lots of devices at once, but it gives you stability and control. For security, I also use the MACs to build a whitelist for my IoT subnet at the same time.

As an FYI - i didn't see the device setting initially so used the Zigbee ID and it worked. I didn't look but does your code fall back to it?

I try to avoid static addresses when I can -- scaling issues and all that. I suggested the Maker API allow me to change such fields but got push back from some people. Is it feasible for you to add such a capability so my app can update the address using an API? Perhaps as a virtual capability? Conversely it would be nice to find out the IP (or MAC) address when I list devices so I can automatically sync it with my database.

(I don't want to ask for to much but my sense is that you can leverage existing features).

Right off the top of my head, there are a couple of ways to do something like this:
1. In the device handler:
It doesn't take that long to send a datagram to each address on a subnet. Given the MAC, it would be pretty easy to just have the driver send a "getPilot" request to every address and try to match the MAC against the returned packet, if any. Initially, I'd set this up as a command in the driver, rather than trying to do it automatically. You wouldn't want the thing constantly scanning ip addresses if somebody just happened to physically turn off the light.
2. On a Raspberry Pi/Other Linux box
You could periodically call nmap to get a list of Ip/MAC addresses on the subnet, and set up a tiny web server or app to allow the device handler to http GET the ip address for a given MAC. This approach is less work for the Hubitat and allows other devices and applications to query the Ip/MAC list too, but it does require that always-on Linux box. (Doesn't everybody already have one?)

Give me a couple of days to clear my project list and think about this. It'd be an interesting experiment. I'm curious about how many people would use a tool like this for LAN IoT devices - I've always just gone the static ip route.

As I shift from my /23 to a /16 (or /20) enumerating can take a while. I'm guessing that the Wiz app uses a broadcast register to find all the bulbs but I'd have to experiment. It could rely on just tracking them when they appear which isn't great.

My current approach is to query my Ubiquiti database and map MAC to IP. I don't like it but after a lot of experimenting I settled on it for the moment. If would use the MakerAPI to update the IP address that would work well-enough.

For my LIFX I rely on their far-from-perfect broadcast call to keep an updated MAC=>IP mapping.

Did a quick test -- sent registration to 192.55.227.255 (broadcard address) and got response from both bulb. And when I added a new bulb it simply showed up

Ok, here's a super experimental driver/python program combo that might do the trick. Given
the bulb's MAC address, this driver will periodically http GET the current ip from the python program's tiny web service. Details are in the readme.md -- take a look and let me know if the concept is useful!

https://github.com/zranger1/HubitatWizLightDriverX

Thanks. I have my corresponding version in TypeScript. It would be nice if I could use the Maker API to automatically update the IP address field. Even better if I could add and rename but I know that's asking for too much.

Funny... I was just thinking we're making it awfully complicated to change light bulbs should one burn out. None of mine have died yet -- hope they really do last a decade or so.

Since I'm stuck at home, I'll see if I can get the maker api working. If you've found any really good documentation for it from the driver writer's perspective, that'd be very helpful.

Yes, managing the bindings is a big issue in general. Fortunately the bulbs have long lives but when you scale to 200 or more devices (as I have) it is real challenge. I try using names (the label field, arbitrary choice but since Hubitat sorts on Label I chose that) for binding but it still means that one has to update Alexa and Google bindings too so I've given up on using Alexa for home control. I'm writing about this but it's a deep CS topic.

Have you seen the Wiz pro website? It's one of the things I found interesting about these bulbs. They've put some work into real scalability - up to 10,000 bulbs! (I'm still not a fan of the cloud though. I'd prefer to run their management software on my own server.)

https://www.wizconnected.com/en-US/pro/

I thought I had a lot of devices - 60 or so, spread over a couple of subnets. 200 is... many! I can see needing a standard for scalable IoT directory services in the very near future.

Interesting but I'm wary given the lack of protocol documentation and the emphasis on the cloud and Bluetooth. I've reach 220 WiFi devices plus additional 30 wired ones. I went back to using the Shelly bulb which has documented protocols and the CoAP notification seems to work quite well though there is also MQTT for those who want it.

A bonus is that the Shellys each have a web interface and can be told what state to come up in including "last". The use of http means I can control them directly from a browser app (if I turn off CORS checking).

I haven't followed the Hubitat Shelly support since it was so easy to do my own drivers in JavaScript. (Easy for Wiz too but wary about the lack of documentation).

I experimented and each bulb has an mDns name so I should be able to use wiz_c1f6e3 instead of the IP address. I tried to lookup the dni rules in the documentation. The documentation just says "local address" but if I use the name it doesn't work. Yet, for the MakeAPI I can use a DNS name for notifications.

I looked the documentation but it never says what an address is nor how to use a DNS name in a driver. Am I missing something? (This is a general question so if I don't see a response I may ask it as a new question).

I'm in the middle of organizing my working-at-home setup, so I can't readily test this 'till probably tomorrow. Just off the top of my head though, if your dns server will resolve the names, you should be able to use them from the HE device handler. Do you have a local domain name? If not, maybe try "wiz_c1f6e3." (with the terminal period). I've had to do that in the past when using dnsmasq for local dns.

On another topic, I've been meaning to ask you -- what ubiquity hw are you using? I'm using pfsense and ddwrt on various ancient hardware and have been thinking about upgrading.

I did try using the WIz_xxxx name and Wiz_xxxxx.domain forms and neither worked. That's why asked about how Hubitat handles names and whether you need a separate step to map the DNS name to the IP address.

As to hardware -- USG (Ubiquiti Security [sic] Gateway) and their CloudKey to run Unifi. You cna run Unifi as an app on other platforms but I want to keep things simple. Set the DNS to USG (x.x.x.1) to be able to use your domain prefix. I use their Pro-APs connected via Ethernet though they could mesh. I also their switches and manage them using Unifi. This is more mechanism than I'd like but, for now, it is needed.

I just purchased two of the Wiz recessed lights from Home Depot (adjustable white). I am so pleased with how easy these were to physically install (as compared to the Hue retrofit light) and to get working with Hubitat. They are much brighter and dim much lower than SengLed bulbs. I assigned static IPs for each bulb and firewalled off these things from talking to the cloud based on guidance from other threads here.
Thanks to zranger1 for creating this driver! Any way to send funds for your contribution? Are there plans to add this driver part of the Hubitat Package Manager?
I hope to add more of these lights soon to other recessed can areas ($14 apiece is an amazing deal!). Still trying to understand how often I should (or have a notification to) check the firmware on these things.

I'm glad you can use it! And thanks is more than enough - no contribution needed. I'll add package manager support next time I update.

I like the spots for recessed cans too. Mine have been running since last January, and they've been painless and trouble free. I've done a firmware check maybe twice during that period and had no problems.

I noticed after adding a Wiz light that it gave me two options in a dropdown (RGB or CT), if I set it to RGB, then it has dimmer level, hue and saturation. How do we know what color is what #
On their website it says the Wiz can do millions of colors, not sure if that is true.

Similar thing with the white, simple, dynamic, progressive and celebration themes, they appear to be controlled by two buttons, next / previous effects.

Or maybe I did not set this up correctly.