Once the bulb has valid data for all its modes, I'd bet it'll stay connected.
The "Time between light status checks" is the polling interval. 6 seconds is fine - I only used 10 seconds because that's where mine are set. In a future version, I'll make this dynamic -- when you change a control, the interval will shorten temporarily so you can see immediate response, if you leave the lights alone for a while, it'll lengthen to reduce network traffic.
Good morning all!
I am new to hubitat and slowly changing items over from straight wifi to HE (once complete of most items I have previously bought ill be get zwave or zigbee), I have setup IFTTT, and added HPM along with KASA switches. I have added zranger1 to the repository and installed the driver but for the life of me can not get it to see the light. Tried to add the driver manually, HPM checked for updates and matched. I know im missing something simple Im just not there yet to know what it is. Any help would be appreciated. If I need removed this and start a new thread please let me know.
Two quick things to check:
Thank you!!!! I don't know how many times I have looked through the settings screen and it never occurred to me to check that. Amazing driver and great work to all. Thank you for your help!
I'm not sure I understand the 6 sec polling duration or if it's working at all. Here's the scenario I just tested:
It doesn't seem to register changing level from an off state. I realized this issue when I started using the motion sensing app. I set it to turn on the lights at different dimmer levels depending on the time of day (e.g. it'll be set to 50 in the evening and 10 at night to act just as a night light). However I noticed that it only ever turns on to what the last dimming level was set to.
Maybe the update that you mentioned will help with this issue or maybe the lights just need to set themselves twice from an off state.
Another quick test I just did to see if the refresh button help at all:
I've just posted an updated version.
This was an internal message timing issue -- the bulb was getting dimmer level set messages while it was still off, which resulted in some or all them being ignored. Should be fixed now!
Just updated and it works splendidly now! Thanks again for being responsive and for the quick updates. 
One thing i have noticed is that the duration option on setlevel comand doesn't appear to work. Is that expected. I am also using an app that seems to use the Philips Hue color scale is there any reason these would not match? Seems like they just don't match up at all. IE the program submits a Hue,Saturation,level command and the color output isn't what would be expected. The writer of the program has just simply said he matched it to Hue and that is what he is using. lol
The Wiz bulbs don't support duration. I could make the Hubitat do the work, but that would require the hub to crank out multiple messages per second per bulb for smooth fades. For installations with a couple of bulbs, no big deal. But the amount of traffic gets out of hand pretty quickly as the number of bulbs go up.
Color space matching is a problem for all LED bulbs. There's no effective standard. No two are alike (unless they're the same bulb under different OEM brands). And imposing the Hubitat's color light model on top of that further reduces accuracy. If you want matching colors between bulb types and brands, you pretty much have to do that by hand.
I have Hue bulbs as well as Wiz and several others. Regular Hue bulbs are crazy expensive, but in return for that, you're getting a really good bulb. They represent color very well, they carefully match color output across the Hue product line, and they use a very accurate internal color representation, rather than RGB or HSV.
Wiz bulbs are a lot less expensive, and do a great job for what they are. But they're made to compete with less expensive bulbs. Next to a Hue bulb, to my eye, the RGB/HSV colors are not as sharp and distinct, and don't seem to have as much fine control of color, even when using the Wiz app. Personally, I use "real" Hue bulbs in places where a few great bulbs make a difference, and Wiz or Shelly or a SmartLife powered bulbs everywhere else.
Is it possible to use the night light effect (6014) in another app (e.g. the motion app or the scenes app)? When I try to just set the color temperature to 6014 these apps also want a dimmer value, so I set it to something (let's say 100).
What ends up happening is that night light turns of briefly then warm white comes on at 100.
Is there any way to keep the night light effect active in these kinds of apps?
As far as I can tell, the Nightlight effect really is just a fairly low (2500-ish) color temperature setting, coupled with a low brightness. Though it starts out dim, nothing in the bulb's internal code restricts how bright it is. You can change the level to anything you want.
To keep the Nightlight dim, if an app is asking for a level, just tell it 10% - the lowest brightness the bulb supports. (That way, you can also use any color or effect you want as a nightlight -- I've been using the Fireplace effect. It just seems warmer and interferes less with my night vision than the "regular" nightlight when I stumble downstairs in the dark.)
Ah yes, setting the bulb to 2500 and 10% brightness seems to replicate the same effect as the Wiz app's night light mode. Thank you, I'll be using this going forward!
It's so similar, in fact, that it even replicates the bulb turning red first and then going to 2500K (this exact thing happens when turning on night light from the Wiz app).
The reason I wanted to use the built in night light mode is because I noticed it turned on quicker then other color temperatures (e.g. warm white) when you set it to the lowest brightness (10%). There always seemed to be this delay as if they were warming up or something. I'm pretty sure it's just a shortcoming of the bulbs.
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.
Still a lot of experimenting and learning.
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
The timing seems pretty good.
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.
I've just posted a test version that allows the maker API to set the bulb's IP address here: HubitatWizLightDriverX/HubitatWizColorDriverX.groovy at master · zranger1/HubitatWizLightDriverX · GitHub
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.
Download the Hubitat app
