Thanks for the drivers -- I'm starting to make more use of Wiz bulbs which means I'm running into the edge cases. I notice that if I turn on the bulb using the driver it can take a while and comes on part way. If I use Wiz it can be instant (though sometimes I find the timing goes to five-second for off). Is this a known problem?
Also, is it feasible to have a setIPAddress function via MakerAPI so that I can do my own assurance that the IP address is correct. It gets difficult to coordinate all the settings. Of course, I'd prefer to use a DNS name instead (which is equivalent to the MAC Address). I'm still puzzled by the lack of DNS support.
BTW, I run my own app outside Hubitat to watch for changes. I presume that's still not feasible on Hubitat.
I'm working around the issues and want to help make the implementation better.
@Bob.ma, let me play with this a bit tomorrow. I've been wondering for a while if there was a way to do "fake" DNS resolution -- the biggest challenge is that there's no straightforward way to build a persistent UDP listener thread in the driver. It might be possible from an app though.
On the timing issues, how many bulbs are you running now? How many wifi devices total on your hub? I've got maybe 50 devices total, 20 of which are wifi, and I don't see the on/off delay, although my hub generally seems a little slower of late. I'm curious about datagram rate limits on the hub. Does the problem become worse if you try to operate a group or scene full of bulbs?
Also, I'm sure you know, but the driver is now available through the Hubitat Package Manager. Make sure you've got the latest version. I've recently made several updates having to do with the many and various ways in which people use dimmers and physical switches with these bulbs.
I've got over 220 Wi-Fi devices in my house but most are not on the Hubitat. Only a small number of Wiz bulbs at this point. I've operated Lifx and Shelly directly in my software. Lifx speed varies because the broadcast protocol seems to be not-all-that reliable. I hope Wiz is better. But with 70 Lifx bulbs I run into scaling issues and might with Wiz too.
The timing issue I was referring to is the long ramp time. I presume those settings are in the bulb. I'm surprised, in the Wiz app, that some seemed to change to 5 seconds for off.
As to fake DNS -- I can update the values myself if there's a setIP. Best to put the effort into getting platform-wide DNS support. I'm surprised it's not there already but, perhaps, the original SmartThings design point is a factor since it ran in yonder cloud.
It's late so I can't do full testing. Speed of response seems fine but I'm very concerned about missing some of the status messages. I'm not in the room with the lights so can't see exactly what is happening. More tomorrow.
BTW, do you know if there has been an update to Dammitly.net: Cheap, Hackable IOT Light Bulbs (or, Philips Bulbs Have No Security)? I worry about his complaining about security issues is risky because the tendency is to remove all access rather than provide an effective model. They already did this with their app that doens't all you to use your own email address -- even though the app itself is on top of the open API.
Speaking of APIs, I wonder how much other information you can get. In particular, the name of the bulb should be stored in the bulb so it can be shared with the app. This bring up the confusion between label and name in Hubitat. I use the label for linking because it's the sorting key. (Putting aside the brouhaha about making leading and trailing spaces significant).
Just did a little testing. It took some setup since the getting the Wiz app to pair with a bulb can be a challenge. Testing with three bulbs. I had to manually go into the app for each one to set ramping to zero. (This is an issue with Hubitat -- performaning operations across multiple devices without having to setup a group for each).
1/11/2021, 09:58:11 EST Homer Received WizA19b (H265) is on
1/11/2021, 09:58:11 EST Homer Received WizA19c (H266) is on
1/11/2021, 09:58:11 EST Homer Received WizA19a (H260) is off
1/11/2021, 09:58:11 EST Homer Received WizA19c (H266) is off
1/11/2021, 09:58:11 EST Homer Received WizA19b (H265) is off
To explain - those timings include sending a message from my node app to a C# on my PC to Hubitat and then listening for the response from the bulbs over IP and sending a status message to the main app which then relays it to clients listening for the update. Good thing it's a million times faster than X10.
To use it, enable the "Allow Maker API to set IP address" item in Preferences. Then you can change IP address at any time by sending a command string to the device in the form: devices/<device number>/setIPAddress/192.168.1.xxx
The new address is stored in state and should be persistent through reboots. It will not change the value of the user-entered "IP Address" field on the device page though -- those things are immutable from the driver's perspective.
Try it out when you have a chance and let me know if it does what you need. If so, I'll run it a few more days to make certain it doesn't change basic operation for anybody not using the maker API, then I'll merge the feature into the main branch.
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.
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.
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.
).
