Something interesting I found was that if I change the settings in the WiZ app, the next time I send any signal from HA it reverts back to its “favorite” setting that it initializes with, which in my case is Circadian Rhythm. To clarify, it isn’t the first preset, its just the setting that is enabled when I turn it on from any source.
My WiZ G25 Filament bulbs get the following response:
{"method":"getSystemConfig","env":"pro","result":{"mac":"xxxx","homeId":xxx,"roomId":xxx,"homeLock":false,"pairingLock":false,"typeId":0,"moduleName":"ESP56_SHTW3_01","fwVersion":"1.16.0","groupId":0,"drvConf":[20,1]}}
They report back the following from the state inspection tool in Home Assistant:
min_mireds: 153
max_mireds: 400
effect_list:
- ...
friendly_name: Hall
supported_features: 55
This color_temp range is actually wrong (correlates to about 2500-4500K), but so is the range available in the WiZ app which allows you to select 2000-5500K. The light’s actual limits are 2000-4500K, so I had to manually customise each light entity in Home Assistant.
You don’t have to manually install pywizlight as it is listed as a dependency in the wiz_light custom component’s manifest.json file. Once you’ve added the custom component, restart your Home Assistant and it will install pywizlight automatically.
Found this documented here: Integration Manifest | Home Assistant Developer Docs
Even better, it should handle updates to pywizlight for you (and wiz_light updates may be managed by HACS in the future).
1 Like
Hi, thanks for info. I did try to restart HA but it was complaining about missing components and did not restart, I did not try to pull the plug out. Do I have to reinstall it the “correct way” to get automatic updates?
No problem - figured it might help a few people with installation.
Yes, I think it required a reboot.
I’ve submitted a pull request ( https://github.com/sbidy/wiz_light/pull/2 ) which will allow everyone to install via http://hacs.xyz and handle updates better.
Hi Stephan - finally got around integrating your custom component in my HA install and works great!
I have the Phillips Wiz bulb(s) and they work great with this component in HA. Great job!!
all good except when changing the scenes found some issues in some latter ones - the enum values seem incorrect… please find below corrected ones:
28:"Halloween",
<s>30</s> 29:"Candlelight",
<s>31</s> 30:"Golden white",
<s>32</s> 31:"Pulse",
<s>33</s> 32:"Steampunk"
above results in error for last one as it exceeds the value the f/w for wiz accepts…
1 Like
I’m wondering if anyone has any thoughts for how we could replicate the “timed fade” functionality that’s present in the Wiz app. I don’t see anything in these UDP messages to the bulb that makes it clear to me how they’re doing that. Anyone got any smart thoughts?
1 Like
It looks like the light itself implements the transition based on the “On fade-in” & “Off fade-out” you set, and as those setting names imply it only works when turning on & off the light.
I’ve contacted Wiz requesting the ability to transition between two different On states, and they are considering implementing this in the future. Perhaps if they get enough requests they’ll implement a solution?
In the meantime I’m simply making slow transitions using timers to change the brightness & colour temperature by small steps every second. Would be very nice to have faster transitions though…
1 Like
Hi all,
sorry I was out of “home” for a couple of days 
…
Now I start to collect the issues with the implementation and try to fix some stuff. I got a pull for the HACS integration. Thanks for that.
To get a better handling about the issues, please create issues in the git.
As @danVnest mentioned the “state transition speed” is not part of the “UDP interface”. In addition the light entity in HA also doesn’t have this as supported features.
But big thank you all for the contributions, feedback and comments!! 
I’ll update the integration ASAP and also start preparing for a pull into the HA master branch as official integration.
@jannewadling The pywizlight is mention as dependency in the manifest file. If you copied the wiz_light into the custom components HA should install the dependency after a service restart. I’m also use HA in a container environment and it works for me.
1 Like
@Sbidy Thank you for the wonderful integration work.
I am here to report an issue. It works flawlessly, except when the lights are set to a “rhythm” from the wiz app. When the lights are set to a rhythm for that room, it is still possible to set color, scene, temperature, brightness etc to override the rhythm from the wiz app, as well as from google home and alexa apps. However from your component, setting of color, brightness, scene - nothing works when there is a rhythm turned on in that room (and hence activated on that light). It flickers to the color/brightness/scene set by HA and then goes back to the rhythm’s color/brightness instantly!
Here’s the output of getPilot from my light:
echo '{"method":"getPilot","params":{}}' | nc -u -w 1 192.168.1.7 38899
{"method":"getPilot","env":"pro","result":{"mac":"a8bb50a4f94d","rssi":-70,"src":"","state":true,"sceneId":12,"speed":100,"temp":4200,"dimming":24,"schdPsetId":9}}
I decided to stop trying to make the app’s “rhythm” feature work for me and implemented a slow transition using AppDaemon… I wanted to be able to have different rhythms based on more than just the time.
If there was an API to make smooth transitions it would be so much better.
However I’m guessing you might be able to use the “syncPilot” method so the app knows you’ve changed the light before it changes it again based on the rhythm?
Heads up for everyone. I used this custom component for a couple of days and then disabled it. When this component was enabled, my HA’s event loop used to get stuck every couple of minutes. Everything used to just get stuck - e.g. if I am opening the file editor, opening an automation, testing a template, checking for state, listening to events, loading history for an entity, anything and everything was affected. The action would fire from the UI and the result would come after 10+ seconds. I have the system monitor plugin and my Pi4 used to have 3.5 GB+ of free memory and the load average and cpu usage used to always be low. Automations used to get stuck. Incoming webhook calls from IFTTT or Google assistant used to time out! I kept scratching my head trying to figure what is wrong here. In the logs it kept giving warnings that every Tuya switch, google home, wiz light and every other switch/light was taking 30+ seconds to update. The wiz warnings kept showing UDP errors with python tracebacks showing UDP send timeouts to the lights. During this time, I would see that many of my chromecast devices, tuya switches, and even device_trackers would become “unavailable” 100s of times a day. Even the time sensor used to get delayed ticking the time!
The moment I disabled this component (commented out all the wiz lights from my config), my HA ( 0.106.6) runs flawlessly - does not get stuck at all, no update failures/timeouts in the logs, and all automations/webhooks are firing smoothly and on time.
I haven’t checked out the code yet, but @Sbidy is there any chance you are not properly using the asyncio on the event loop and that the UDP I/O is blocking hass.io’s core?
Glad to furnish any other details to help fix this.
Also do note that in my setup, there are some lights in the far corners of the house which are at a significant latency away from my router (e.g. the wiz app takes 2-3 seconds to turn them on/off), so that can explain how no one else noticed this problem with their HA core. Regardless, even some tuya switches and lights are farther away and they never cause the HA core to get stuck.
Hey @angadsingh
Thank you for the feedback - it is possible that the code doesn’t support the async feature wrong.
So I’ll try to reproduce the error. It can be a problem of the signal latency and the to short chosen timout for the UDP connection.
Can you please provide the error message or exception from the wiz_light integration?
Edit: Here the issue in GitHub https://github.com/sbidy/wiz_light/issues/6
1 Like
@Sbidy It is exactly the same error as you have put in your github issue. The problem is not that the exception is coming - it is good that you have short timeout in fact. The problem is that UDP I/O is blocking HA core. You need to do it asynchronously. Perhaps have a look at https://docs.python.org/3/howto/sockets.html#non-blocking-sockets
Also I see that in async_update (https://github.com/sbidy/wiz_light/blob/f31f229a395993e884d9e6fa56ba5ca3b75778d8/light.py#L179) you are calling update_state(), update_brightness(), etc. which are in turn calling self.getState() in https://github.com/sbidy/pywizlight/blob/d341b2b0d486d92b77037299b08cc019e251096d/pywizlight/bulb.py multiple times, which is sending the same UDP message getPilot. Why not just call it once? Why flood the lights with the same UDP message.
AHA!! Thank you so much for your comment, I could not get mine to work and it was because I had Circadian Rhythm on!
I took the liberty to fork’s @Sbidy’s generous effort and fix the issues.: https://github.com/sbidy/wiz_light/pull/9
https://github.com/sbidy/pywizlight/pull/2
Till the above PRs get merged, my component is also available for direct use at: https://github.com/angadsingh/wiz_light (this component does not need a dependency on pywizlight like @sbidy’s component)
Bug fixes:
- Fixes https://github.com/sbidy/wiz_light/issues/6: makes the whole component truly async using non-blocking UDP
- Light control now works even when lights are set to a rhythm.
Features:
- Now supports switching the light to rhythm mode! (rhythm is defined as a scene for HA)
- Implements a pattern of sending multiple command UDP datagrams until response is received
- Consolidates getPilot and setPilot calls using a PilotBuilder and PilotParser. Removes unnecessary UDP calls for each and every attribute (color, temperature, brightness, scene, etc.) and makes a combined getPilot/setPilot call
- enhanced debug logging for UDP
The problem with rhythm mode was that in @Sbidy’s component, he was making several different UDP calls in the turn_on method for setting brightness, color temperature, scene, etc, each of which were sending their own UDP setPilots, and then a final setPilot which had no params. Turns out, that if there is a rhythm defined in the room, it gets activated on the light by sending a setPilot with no params 
. I am using that to allow you to switch any light to a ‘Rhythm’ scene now (and it detects if its in a rhythm scene as well). It all works flawlessly now.
For async I/O I am using https://github.com/jsbronder/asyncio-dgram, which internally uses asyncio DatagramTransport, which allows completely non-blocking UDP transport:
https://github.com/angadsingh/wiz_light/blob/caa90cebd9f8ccb2d588c900e36fbf19277eda9c/wizlight.py#L293
Since UDP can loose packets, and your light might be a long distance away from the router, I am continuously sending the UDP command until there is a response from the light. This has in my tests worked way better than just sending once and just waiting for a timeout.
This is the result:
2020-03-18 11:49:56 DEBUG (MainThread) [custom_components.wiz_light.light] [wizlight 192.168.1.88] updating state
2020-03-18 11:49:56 DEBUG (MainThread) [custom_components.wiz_light.wizlight] [wizlight 192.168.1.88, connid 384b0e6912316c] connecting to UDP port
2020-03-18 11:49:56 DEBUG (MainThread) [custom_components.wiz_light.wizlight] [wizlight 192.168.1.7, connid 384b0e6911bdc4] listening for response datagram
2020-03-18 11:49:56 DEBUG (MainThread) [custom_components.wiz_light.wizlight] [wizlight 192.168.1.7, connid 384b0e6911bdc4] sending command datagram 0: {"method":"getPilot","params":{}}
2020-03-18 11:49:56 DEBUG (MainThread) [custom_components.wiz_light.wizlight] [wizlight 192.168.1.7, connid 384b0e6911bdc4] sending command datagram 1: {"method":"getPilot","params":{}}
2020-03-18 11:49:56 DEBUG (MainThread) [custom_components.wiz_light.wizlight] [wizlight 192.168.1.7, connid 384b0e6911bdc4] sending command datagram 2: {"method":"getPilot","params":{}}
2020-03-18 11:49:56 DEBUG (MainThread) [custom_components.wiz_light.wizlight] [wizlight 192.168.1.88, connid 384b0e6912316c] listening for response datagram
2020-03-18 11:49:56 DEBUG (MainThread) [custom_components.wiz_light.wizlight] [wizlight 192.168.1.88, connid 384b0e6912316c] sending command datagram 0: {"method":"getPilot","params":{}}
2020-03-18 11:49:56 DEBUG (MainThread) [custom_components.wiz_light.wizlight] [wizlight 192.168.1.7, connid 384b0e6911bdc4] response received: {'method': 'getPilot', 'env': 'pro', 'result': {'mac': 'a8bb50a4f94d', 'rssi': -64, 'src': '', 'state': True, 'sceneId': 0, 'temp': 3154, 'dimming': 58}}
2020-03-18 11:49:56 DEBUG (MainThread) [custom_components.wiz_light.light] [wizlight 192.168.1.7] updated state: True
2020-03-18 11:49:56 DEBUG (MainThread) [custom_components.wiz_light.wizlight] [wizlight 192.168.1.88, connid 384b0e6912316c] response received: {'method': 'getPilot', 'env': 'pro', 'result': {'mac': 'a8bb50a5806c', 'rssi': -53, 'src': '', 'state': True, 'sceneId': 13, 'speed': 100, 'temp': 6500, 'dimming': 100, 'schdPsetId': 11}}
2020-03-18 11:49:56 DEBUG (MainThread) [custom_components.wiz_light.light] [wizlight 192.168.1.88] updated state: True
3 Likes
Thanks to @angadsingh the implementation get more quality and resilience .
I’ve moved some stuff to the pywizlight packet. Now the integration should be worked with the pypip package to separate the logic form the integration.
The new version with all changes from @angadsingh are available in the testing branch.
Please test this new integration with your bulbs - it works with Philips Wiz Hue and the SLV Play.
For installing the testing branch version use git clone --branch testing https://github.com/sbidy/wiz_light.git in your custom components folder. Please restart the container or home assistant service and check the log file for INFO (SyncWorker_6) [homeassistant.util.package] Attempting install of pywizlight==0.3.0.
If no issues coming up I’ll merge the testing into the master.
Maybe I will add the configFlow feature also to the new master release (mmh … a versioning would be great 
… )
1 Like
Thank you all for the hard work on this. I’m new to HA, so this might be a simple answer.
I have one Wiz bulb in HA and would like to add it to the Living Room area. I don’t seem to be able to do it in the gui or the config.
Any idea?