On the status of the Wiz wifi API: I know the OpenHab people have a working driver too, but I haven't seen anything that indicates the wifi API has changed. At some point a while ago, Wiz did add a switch in their app that lets you enable/disable local control, but that's about it.
Seems like they built a working minimal feature set for wifi, and most of their new work goes into their cloud API.
Thanks for the API -- now another opportunity for my own bugs ( 
).
It works.
One refinement would to be display the address. And a bonus for allowing me to provide and fetch the MAC address But it's useful as is and I'll move towards making production use of it rather than static addresses.
Thanks.
The IP address should be displayed under "State Variables" at the bottom of the devices page once you've set it via the API. Refresh the page in your browser if it doesn't show up by itself.
I was thinking a getMacAddress api would be useful too -- I'll post when I've got it in, most likely tomorrow.
Just as I feared -- I couldn't resist implementing it. I now convert the mac into wiz_xxxxxx DNS names, look it up to get the IP and then update if changed! Works very smoothly and is very quick.
My goal is to try to update the settings in as few places as I can and then use software to synchronize. Too bad there isn't (as far as I know) an API to create the Hubitat device. Then, perhaps, I can see a new Wiz device appear and automatically bring it into the fold.
I'm now adopting the convention of using the "name" field for the stable identifier. For Wiz this is wiz_xxxxxx. It's essentially the MAC address assuming they don't change the high order bits. But, just as important, it's the DNS name. I can then use the label as the binding identifier for apps.
(I'll also fix my software to sound a klaxon when it finds leading or trailing spaces).
Working well but have to remember each time to set the ip flag, put in a fake address and then have to remember to enabel it in the Maker API. Need to see how much of this we can combine to avoid forgetting a step.
I've merged it back into the main branch -- testing now. The new features will be on by default (you won't have to enable it for each device, but can still turn them off), plus I've added a "macAddress" attribute to the device information returned by Maker API.
If all goes well, I'll update it in the main repository early this evening.
Great!
It would be nice to get some of these capabilities mainstream into standard drivers.
When I get the settings via the Maker API, I don't see the IP address. Is it supposed to be there? I do see it for the Shelly driver.
It's not there at the moment -- it's stored in the driver's persistent state database entry, which isn't visible to the Maker API.
The bulb itself doesn't report it, but I can add it easily enough by sneaking a look at the packet headers if it's useful.
For now, I use the wiz_ name to look up the DNS entry but, in the future, knowing the MAC could be useful and it is in the header. My attitude is that the more information is available the more ways I can make things work.
I do want to better understand the bulbs themselves but that's another topic outside the habitat context. For example, Their smart vs. sticky modes.
@zranger1 Thanks so much for providing this driver for Wiz lights!
There's a lot I like about the Wiz bulbs (mainly the price), I have them in my kitchen controlled with a Zooz ZEN21 switch (disabled local control, only using z-wave control, set up some scene controls based on button taps). I did have to comment out line #325 in your v1.2.3 release as it always set the level to 10 when I turned the lights back on (instead of last level) -- other than than, everything works great!
I wish there was a way to control the dimming speed but I guess that's a limitation of the Wiz bulbs, as you can't do it in the app either -- you can only set the on/off duration, not dimming duration. I even tried setting up a "repeat" automation in Rule Machine that would simulate dimming by increasing/decreasing the dimming level +1 by a set time amount, but couldn't get it working properly (and probably putting too much stress on the CPU).
Anyway great work and I'll be following this thread, thanks again!
Oh -- so that's why it went to 10 when I tested. Ooops.
Just added another wiz. Named it wiz_xxxxxx so I could look up the name in my local DNS and also, though not critical, use it to compute the MAC address. I remember to click "allow IP", set the initial IP to 0.0.0.0 and then go to the maker API to allow it. I'm now practiced at the process.
I've just updated the main branch of the driver -- HPM users should get the update next time they check, and it's available here for everybody else.
As we've been discussing in this thread, this version includes tools for dynamic managment of IP addresses in large installations. The new features are enabled by default, but can be disabled from the device page UI.
The setIPAddress command allows an external program to set the bulb's IP address. Once set, the new address overrides the user-entered address, and will persist through reboots. (Addresses set with this command will now replace the user-entered IP address -- you may have to refresh the Devices page to see it.)
Also, the macAddress and ipAddress attributes are now available to the Maker API as part of the bulb's device information.
To use the new command, send the setIPAddress command via Maker API in the following format:
devices/<device number>/setIPAddress/192.168.1.xxx
An explanation of switch/dimmer behavior in the current driver, just so everybody's on the same page for possible bug reporting:
The dimmer model I envisioned for this is the old school slider, with an on/off detente at the bottom.
If you dim all the way (in this case, below 10%, since it's the lowest level the bulb supports), the bulb is turned off. If you then move the slider above 10%, the bulb turns on and its brighness will reflect the current slider setting.
If the slider is set below 10% (off), and you turn the bulb on with another (on/off) switch, it will come on at the minimum 10% brightness. If the slider is set at 10% or above, turning the bulb on and off with a switch will not affect the brightness or the slider setting.
Because some parts of the bulb's status are polled at a relatively low frequency, there may occasionally be a small amount of visible "bounce" in the dashboard slider, but it should wind up in the right spot very quickly.
It would be nice to have a convention for all drivers of having the import URL as a comment at the very top of the file. It would then facilitate importing updates. Even better if it could be recognized by the "import" command itself.
Easy enough -- I'll put a copy up there next update.
It lives in the metadata now because the Hubitat Package Manager uses it. Lately, most of the people I've talked to, especially the newer ones, are pushing pretty hard towards the HPM for installations and updates. Personally, I can take or leave it, but I have to admit that it makes it easier to track driver updates, even if you don't want to install the new one right away.
Download the Hubitat app
