WIZ/Philips wifi lights

I have 7 WIZ lights that I think I have configured correctly however a couple of the lights keep dropping in HA and indicated as not reachable. If I view them on the WIZ app there is no problem. For me to get them back and reachable through HA I have to restart HA I do not have to reset or power off the lights to have them reconnect to my wifi. restarting HA does the trick. Thats not a good sign. I’m wondering if anyone else is having a similar problem and could share their configuration to overcome this.
Thanks

Make sure you have signed static ip addresses. My experience with those, if the ip changes, it broke the integration. This has been a while but you may check.

1 Like

Thanks… When this happened for the first time the WIZ lights IP address did not change. Both the WIZ app and Alexa saw the lights online and their status just fine. It was just HA that had a problem and showed several of the lights offline. Once I restarted HA then it was fine HA saw them as online and their status.

I have 65 Wiz lights installed and wish to double that, but I’m not currently moving forward with that plan because multiple times a day there are short stretches of time where many (or all) lights are ‘unavailable’. Ocassionally, a single bulb will be Unavailable for hours - when that happens, I toggle the power off then back on for all bulbs connected to that light switch. That usually makes it available again in HA. During the times that the bulbs are Unavailable, they are still controllable by the Wiz app.

In these charts, anywhere there is a tiny gap of gray, that is where the light was Unavailable. Notice areas where the bar is red for a large section of time and the word “Off” appears multiple times in that section, that is what happens when its unavailable for a short length of time.


I have modified this line in wiz/init.py (by copying the whole wiz directory to my ‘custom_components’ directory and editing the file there):
update_interval=timedelta(seconds=30), // this used to be set to 15 seconds

This seems to have a positive effect, but I want it to be rock-solid, not just 98% stable. People in the house definitely notice and are annoyed when all lights can turn off in a room except one. I’ve created a card in Lovelace that allows me to turn off the power relay of a light switch so that I can easily toggle the power to the bulbs off and then back on to reset the bulbs. I use Z-wave switches (Zooz ZEN32 or ZEN71) to control the power to the bulbs, so I can also create an automation for a double tap on the switch to reset the power to the bulbs.

This is what the log lines look like when the bulbs become unavailable:
2022-04-04 16:11:15 ERROR (MainThread) [custom_components.wiz] Error fetching WiZ Tunable White 19EB83 data: Failed to update device at 192.108.2.30: The request to the bulb timed out

I have the Adaptive Lighting integration enable for all of the bulbs. I’m sure that causes more state changes to the bulbs than there would be ‘normal use’ of the bulbs.

I don’t think my WiFi network is part of the problem. My wifi network should be completely capable of handling the volume of traffic. I have two Netgear WAX 630 access points, each one can support up to 200 2.4GHz clients. The channel utilization hangs out around 33%-40% most of the time. The Wiz app (via WiFi) can connect to the lights, even when HA can’t. I think this all points to the fact that HA is the place having the problem. I have the IP address for each bulb reserved on my router.

@Sbidy @bdraco I’m curious if you’ve considered doing bulk queries to the the bulbs instead of individual queries for updates. Do you think that bulk queries would help? I’m happy to provide more information to help troubleshoot this. I have another 70+ bulbs that I’d like to install, but it seems like every time I install more, I get Unavailable bulbs more frequently. Is there any way we could load test this without real bulbs?

The bulbs push updates unless there is an error in the log saying the port is use (set pywizlight to debug level). Changing the polling interval should have no effect unless push updates are not working.

I enabled the logging and it looks like the push updates are working.

How does the bulb know where to push the data to? Is this referring to pushing data to HA or the app on my phone?

On my firewall, I notice that its blocking UDP traffic from the bulbs to my phone. Is that something that I should allow? The app on my phone seems to be up to date (on/off is correct for each bulb).

Now I’m thinking that maybe reducing the frequency of updates from Adaptive Lighting might be helpful in reducing the amount of time that bulbs are Unavailable. Does that sound reasonable? Or @bdraco do you have other ideas?

Now that I’m looking at the log file a bit closer, here’s what’s going on in the first 60 seconds of HA server startup, for a single bulb. This seems way more chatty than I’d expect, especially because this bulb is not controlled by Adaptive Lighting. In fact, the logbook shows that no changes were made to the light during this time frame. It looks like there are 16 push calls during this 60 second interval, which seems excessive for a bulb that isn’t having any changes. Could the number of pushes be reduced? With 65 bulbs on my network, this kind of network traffic adds up really quickly. Could this be part of the reason I get Unavailable bulbs?

2022-04-04 22:46:31 DEBUG (MainThread) [pywizlight.bulb] 192.108.0.92: >> b'{"method":"getSystemConfig","params":{}}' (1/6) backoff=0.0
2022-04-04 22:46:31 DEBUG (MainThread) [pywizlight.bulb] 192.108.0.92: << b'{"method":"getSystemConfig","env":"pro","result":{"mac":"a8bb50085466","homeId":4133998,"roomId":7880749,"rgn":"eu","moduleName":"ESP05_SHRGB_21","fwVersion":"1.25.0","groupId":0,"drvConf":[30,1],"ping":0}}'
2022-04-04 22:46:32 DEBUG (MainThread) [pywizlight.bulb] 192.108.0.92: >> b'{"method":"getModelConfig","params":{}}' (1/6) backoff=0.0
2022-04-04 22:46:32 DEBUG (MainThread) [pywizlight.bulb] 192.108.0.92: << b'{"method":"getModelConfig","env":"pro","result":{"ps":1,"pwmFreq":1000,"pwmRange":[5,100],"wcr":30,"nowc":1,"cctRange":[2200,2700,5000,6500],"renderFactor":[144,255,63,255,42,90,0,0,0,0]}}'
2022-04-04 22:46:33 DEBUG (MainThread) [pywizlight.bulb] 192.108.0.92: >> b'{"method":"getPilot","params":{}}' (1/6) backoff=0.0
2022-04-04 22:46:33 DEBUG (MainThread) [pywizlight.bulb] 192.108.0.92: << b'{"method":"getPilot","env":"pro","result":{"mac":"a8bb50085466","rssi":-76,"src":"","state":false,"sceneId":12,"temp":4200,"dimming":100}}'
2022-04-04 22:46:35 DEBUG (MainThread) [pywizlight.bulb] 192.108.0.92: >> b'{"params":{"phoneIp":"192.168.2.110","register":true,"phoneMac":"e34fde919042"},"method":"registration"}' (1/6) backoff=0.0
2022-04-04 22:46:35 DEBUG (MainThread) [pywizlight.bulb] 192.108.0.92: << b'{"method":"registration","env":"pro","result":{"mac":"a8bb50085466","success":true}}'
2022-04-04 22:46:35 DEBUG (MainThread) [pywizlight.push_manager] ('192.108.0.92', 49156): PUSH << b'{"method":"syncPilot","env":"pro","params":{"mac":"a8bb50085466","rssi":-77,"src":"udp","state":false,"sceneId":12,"temp":4200,"dimming":100}}'
2022-04-04 22:46:36 DEBUG (MainThread) [pywizlight.push_manager] ('192.108.0.92', 49156): PUSH << b'{"method":"syncPilot","env":"pro","params":{"mac":"a8bb50085466","rssi":-77,"src":"hb","mqttCd":0,"ts":1649130927,"state":false,"sceneId":12,"temp":4200,"dimming":100}}'
2022-04-04 22:46:41 DEBUG (MainThread) [pywizlight.push_manager] ('192.108.0.92', 49156): PUSH << b'{"method":"syncPilot","env":"pro","params":{"mac":"a8bb50085466","rssi":-76,"src":"hb","mqttCd":0,"ts":1649130927,"state":false,"sceneId":12,"temp":4200,"dimming":100}}'
2022-04-04 22:46:47 DEBUG (MainThread) [pywizlight.push_manager] ('192.108.0.92', 49156): PUSH << b'{"method":"syncPilot","env":"pro","params":{"mac":"a8bb50085466","rssi":-77,"src":"hb","mqttCd":0,"ts":1649130927,"state":false,"sceneId":12,"temp":4200,"dimming":100}}'
2022-04-04 22:46:51 DEBUG (MainThread) [pywizlight.push_manager] ('192.108.0.92', 49156): PUSH << b'{"method":"syncPilot","env":"pro","params":{"mac":"a8bb50085466","rssi":-76,"src":"hb","mqttCd":0,"ts":1649130927,"state":false,"sceneId":12,"temp":4200,"dimming":100}}'
2022-04-04 22:46:55 DEBUG (MainThread) [pywizlight.bulb] 192.108.0.92: >> b'{"params":{"phoneIp":"192.168.2.110","register":true,"phoneMac":"e34fde919042"},"method":"registration"}' (1/6) backoff=0.0
2022-04-04 22:46:55 DEBUG (MainThread) [pywizlight.bulb] 192.108.0.92: << b'{"method":"registration","env":"pro","result":{"mac":"a8bb50085466","success":true}}'
2022-04-04 22:46:55 DEBUG (MainThread) [pywizlight.push_manager] ('192.108.0.92', 49156): PUSH << b'{"method":"syncPilot","env":"pro","params":{"mac":"a8bb50085466","rssi":-76,"src":"udp","state":false,"sceneId":12,"temp":4200,"dimming":100}}'
2022-04-04 22:46:56 DEBUG (MainThread) [pywizlight.push_manager] ('192.108.0.92', 49156): PUSH << b'{"method":"syncPilot","env":"pro","params":{"mac":"a8bb50085466","rssi":-76,"src":"hb","mqttCd":0,"ts":1649130927,"state":false,"sceneId":12,"temp":4200,"dimming":100}}'
2022-04-04 22:47:01 DEBUG (MainThread) [pywizlight.push_manager] ('192.108.0.92', 49156): PUSH << b'{"method":"syncPilot","env":"pro","params":{"mac":"a8bb50085466","rssi":-76,"src":"hb","mqttCd":0,"ts":1649130927,"state":false,"sceneId":12,"temp":4200,"dimming":100}}'
2022-04-04 22:47:06 DEBUG (MainThread) [pywizlight.push_manager] ('192.108.0.92', 49156): PUSH << b'{"method":"syncPilot","env":"pro","params":{"mac":"a8bb50085466","rssi":-76,"src":"hb","mqttCd":0,"ts":1649130927,"state":false,"sceneId":12,"temp":4200,"dimming":100}}'
2022-04-04 22:47:11 DEBUG (MainThread) [pywizlight.push_manager] ('192.108.0.92', 49156): PUSH << b'{"method":"syncPilot","env":"pro","params":{"mac":"a8bb50085466","rssi":-76,"src":"hb","mqttCd":0,"ts":1649130927,"state":false,"sceneId":12,"temp":4200,"dimming":100}}'
2022-04-04 22:47:15 DEBUG (MainThread) [pywizlight.bulb] 192.108.0.92: >> b'{"params":{"phoneIp":"192.168.2.110","register":true,"phoneMac":"e34fde919042"},"method":"registration"}' (1/6) backoff=0.0
2022-04-04 22:47:15 DEBUG (MainThread) [pywizlight.bulb] 192.108.0.92: << b'{"method":"registration","env":"pro","result":{"mac":"a8bb50085466","success":true}}'
2022-04-04 22:47:15 DEBUG (MainThread) [pywizlight.push_manager] ('192.108.0.92', 49156): PUSH << b'{"method":"syncPilot","env":"pro","params":{"mac":"a8bb50085466","rssi":-76,"src":"udp","state":false,"sceneId":12,"temp":4200,"dimming":100}}'
2022-04-04 22:47:16 DEBUG (MainThread) [pywizlight.push_manager] ('192.108.0.92', 49156): PUSH << b'{"method":"syncPilot","env":"pro","params":{"mac":"a8bb50085466","rssi":-76,"src":"hb","mqttCd":0,"ts":1649130927,"state":false,"sceneId":12,"temp":4200,"dimming":100}}'
2022-04-04 22:47:21 DEBUG (MainThread) [pywizlight.push_manager] ('192.108.0.92', 49156): PUSH << b'{"method":"syncPilot","env":"pro","params":{"mac":"a8bb50085466","rssi":-76,"src":"hb","mqttCd":0,"ts":1649130927,"state":false,"sceneId":12,"temp":4200,"dimming":100}}'
2022-04-04 22:47:26 DEBUG (MainThread) [pywizlight.push_manager] ('192.108.0.92', 49156): PUSH << b'{"method":"syncPilot","env":"pro","params":{"mac":"a8bb50085466","rssi":-76,"src":"hb","mqttCd":0,"ts":1649130927,"state":false,"sceneId":12,"temp":4200,"dimming":100}}'
2022-04-04 22:47:31 DEBUG (MainThread) [pywizlight.push_manager] ('192.108.0.92', 49156): PUSH << b'{"method":"syncPilot","env":"pro","params":{"mac":"a8bb50085466","rssi":-76,"src":"hb","mqttCd":0,"ts":1649130927,"state":false,"sceneId":12,"temp":4200,"dimming":100}}'    

The push interval is controlled by the wiz firmware. We cannot reduce it.

The only way I keep my esp devices stable with my unifi network is that I limit to 50 2.4ghz devices per ap and lock the esp devices to a specific ap to ensure they don’t have to reach too far.

I don’t know if the net gear ones have a lock to ap functionality built in

@crazycurl’s picture of wiz history with slivers of brief unavailability across multiple bulbs caught my eye because mine looked like that too. I had been going down rabbit holes trying to eliminate them: In my case, completely disabling ipv6 (in /etc/default/grub) on the home assistant vm helped. I have a virtualbox guest bridged to 2 host adapters so home assistant can discover the wiz bulbs on a separate wifi subnet as well as work with other devices on the main network.

Edit #1: I also changed the vm from the Home Assistant Operating System to Debian with Home Assistant Container. The Supervisor seems to add a significant amount of traffic (maybe reflecting broadcasts between the 2 networks? - don’t know).

Edit #2: One of the brief 15 second ‘unavailable’ blips across the bulbs was at around 4:12am each morning. That time happened to coincide with the daily history purge - however, that may have been a coincidence. It turns out the guest VM system clock was drifting (it is supposed to stay in sync with the host but wasn’t for some reason). Installing the ntp service straightened that out and I haven’t seen a single ‘unavailable’ blip ever since.

Not sure how all this is intertwined but thought I would mention them in case it happens to apply to others too.