Wiz integration not discovering devices

[madbrain76]

The problem

I have a triple digit number of Wiz devices - currently 113 smart bulbs, and the number will only be going up. When I added them to my Wifi network using the Wiz app, they initially got dynamic IP addresses from my router. The Home Assistant Wiz integration discovered them, with those temporary IPs. I did not want to set them up in HA at the time, so I clicked "ignore" on every single one of them.

I then spent a lot of time carefully assigning reservations and labeling all devices in the pfSense DHCP server, and in Unifi. I probably need to write some code to automate this, since this is quite tedious.

Anyway, now, when I try to add a Wiz device in HA, it says I have to enter the device IP, or if I leave the field blank, it will run discovery. The problem is that the discovery process never finds anything. It just says that no devices were found on the network. I only have 30 currently setup in the integration, and 83 left to add. If I specify the IP address manually, the integration does find the device.

I'm not quite sure what's causing this. My guess is that it's mainly related to having clicked "ignore" when the devices were first discovered. Is there a way to "unignore" them ? I couldn't find one.

Alternately, it could be due to the subnet I'm using, which is 192.168.100.0/22, not a /24 like many are using as I have exceeded 256 IP devices.

What version of Home Assistant Core has the issue?

core-2025.1.4

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Wiz

Link to integration documentation on our website

https://www.home-assistant.io/integrations/wiz

Diagnostics information

N/A

Example YAML snippet

Anything in the logs that might be useful for us?

Not sure

Additional information

No response

[home-assistant[bot]]

Hey there @sbidy, mind taking a look at this issue as it has been labeled with an integration (wiz) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of wiz can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign wiz Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

wiz documentation wiz source _{^{(message by IssueLinks)}}

[madbrain76]

Actually, the fix was to show "disabled integrations". I was confused, because in my mind I wanted to unignore "devices", not integrations. But that is HA terminology.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[madbrain76]

Actually, the fix was to show "disabled integrations". I was confused, because in my mind I wanted to unignore "devices", not integrations. But that is HA terminology.

This turned out to be incorrect.

Clicking ignore on a discovered Wiz device under Settings/Devices makes the device disappear from the GUI. Issue 1 : Enabling the "show disabled integration" checkbox does not cause it to re-appear. Issue 2 : after bringing the device back online, the automatic discovery fails to find it.

The only workaround is to enter the IP manually. With the number of Wiz bulbs I have, >200, it is a lot of work to track all the IPs for each bulb.

[sbidy]

Most of the time this is not an issue of the integration. To connect to the bulb (especially discovery) is done via UDP broadcast. This is an "old" approach and sometimes network components are not allowing this (especially WiFi controller). It is also not possible to discover bulb over different subnets (broadcast domain). Please consider to have a simple and "flat" network to the bulbs. You can use the https://github.com/sbidy/pywizlight CLI to test the discovery from any python supported device.

[sbidy]

Please also provide the MACs of some of the devices which could not be found.

[madbrain76]

I'm using a single subnet, although it is a /22, not your typical /24 . They are all on the same SSID. There are no VLANs.

The APs I use are Ubiquiti Unifi. 127 bulbs are on vacancy motion sensors that turn them off after 30 minutes, so they don't stay online unless there is someone in the room. The other 95 are now on smart switches with the relay always powering them on, and the switches act as mere scene controllers.

The Wifi network completely falls apart when I turn on all 222 bulbs, despite the APs supposedly being able to handle hundreds each individually. It seems to be an issue with airtime limits on the 2.4 GHz band, and limited number of available channels. At least, that's the explanation Ubiquiti is giving me. And of course, the bulbs are not the only Wifi devices, though they are the majority.

In any case, when I reported the problem, the issue was the inability to discover bulbs that I knew were online at the time, from looking at them in the Unifi controller, and from ping/smokeping data.

I have now gotten all 222 Wiz bulbs in my Home assistant installation. It's consistent between my pfSense DHCP table with reservations and hostnames, Unifi controller, the HA Wiz integration, and smokeping. However, it was a lot of manual work every step of the way. Not to mention the Wiz app itself for first adding them. I did build a script to convert between pfSense DHCP -> smokeping. I may do one for pfSense to/from Unifi as well to ease things in the future. Not completely clear how things could be made easier from an HA standpoint, besides fixing the auto-discovery that is the subject of this bug. I assigned local DNS names for every device on my network, including those 222 bulbs. If HA integrations such as Wiz (or TP-Link, I also have dozens of their devices) could look at those DNS names using reverse DNS, it would simplify things for me greatly. Of course, for people not using IP reservations or not able to set DNS names, this would not be advisable.

In order to reproduce the discovery problem, I would need to remove the bulbs from HA, and then try to add them again with auto-discovery. I can certainly make an HA backup, but I'm not certain how to delete all 222 bulbs without clicking hundreds of times - I suspect it will be several times per bulb. Is there a faster way to do it in bulk ?

Another problem is the way the integration periodically looks for online and offline bulbs. The process of doing that is fine - of course it has to do it. But it is very unnerving in the GUI when you have 100+ bulbs offline and everything randomly scrolls away every 20 seconds or so. That is not an issue specific to the Wiz integration, though. It happens with TP-Link, too, but there are fewer devices that are not permanently online so it's less troublesome.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.