Wiz Bulb Offline but can control it normally

1

Hello. I’m new here. Long time Home Assistant user.

I am trying out openHAB in the hopes of getting a more stable Wiz bulb integration. Within Home Assistant the integration is not able to control some of the lighting effects. The openHAB one IS able to do this. Score openHAB.

One negative that I have found is that openHAB marks Wiz bulbs as OFFLINE after a period of time. Random. Never the same bulb.

Within the Wiz mobile app and Home Assistant I am able to control the bulb normally.

Here is what it looks like in openHAB Things,

image
image1480×110 13.9 KB

In openHAB I can click on it to get this
(had to delete second screenshot as I’m a new user)

Then I click “Save” at the top and the bulb is then shown as ONLINE.
(had to delete third screenshot as I’m a new user)

Is there anything I can try in openHAB to correct this? I tried the Heartbeat thing already and that just made the problem worse. With that most bulbs were OFFLINE at any one time.

I have the bulbs on a 2.4GHz dedicated UniFi network.

Thank you!

2

I’ve upgraded you to a basic user so the restrictions on the number of images should be lifted.

I don’t know these devices but I suspect the logs should show why they are going offline. Often when you click on the OFFLINE badge it will give you more information about why it’s offline.

If you don’t see anything in the logs, you may need to put the logger into debug level logging. Then post the logs that occur around the time that the Thing goes offline.

Use code fences:

```
code goes here
```
1 Like
3

Thank you for the response and forum upgrade.

When I click on an OFFLINE badge it doesn’t give me anything. Might that be an add-on specific thing.

Thank you for the logging idea. I did find, under Settings, Add-on Settings, a section for Wiz and I set that to Debug.

I am able to view logs running now. I hope to find something useful. Debug is indeed, by design, very chatty.

4

@rlkoshak is correct; however you probably need to log:set DEBUG org.openhab.binding.wiz in order to get enough detail…

5

Thanks Andrew. I will look into that debug setting now.

I was just able to capture the following…

12:47:23.241	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Polling for status from device at 6c:29:90:54:ee:42.
12:47:23.241	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Sent packet to address: /172.28.48.181 and port 38899
12:48:23.743	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Polling for status from device at 6c:29:90:54:ee:42.
12:48:23.743	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Sent packet to address: /172.28.48.181 and port 38899
12:49:24.245	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Polling for status from device at 6c:29:90:54:ee:42.
12:49:24.245	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Sent packet to address: /172.28.48.181 and port 38899
12:50:24.746	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Polling for status from device at 6c:29:90:54:ee:42.
12:50:24.747	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Sent packet to address: /172.28.48.181 and port 38899
12:51:25.248	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Since no updates have been received from mac address 6c:29:90:54:ee:42 in 300 seconds, setting its status to OFFLINE and discontinuing polling.

It is quite clear and yet I am able to control this bulb at 172.28.48.181 from the Wiz app itself and also from Home Assistant.

I realize this is an openHAB forum so I don’t want to bang on about Home Assistant too much. I am here trying openHAB as I believe the Wiz add-on / integration is more capable in openHAB. I’m also over the volume of breaking changes in Home Assistant that leads to poor husband acceptance factor. That is a whole different discussion lol.

It appears the openHAB binding tries to get status four times within a few minutes. When they fail the bulb is marked as OFFLINE.

6

So I was here…

image
image2084×1674 203 KB

I clicked “Save” at the top and the bulb was instantly marked ONLINE

356	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Sent packet to address: /172.28.48.181 and port 38899
13:13:48.835	DEBUG	org.openhab.binding.wiz.internal.utils.WizPacketConverter	Incoming packet from 172.28.48.181 to convert -> {"method":"getSystemConfig","id":161,"env":"pro","result":{"mac":"6c299054ee42","homeId":6083030,"roomId":9492093,"rgn":"eu","moduleName":"ESP22_SHRGBC_01","fwVersion":"1.34.0","groupId":0,"ping":0,"accUdpPropRate":100}}
13:13:48.836	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Sent packet to address: /172.28.48.181 and port 38899
13:13:48.872	DEBUG	org.openhab.binding.wiz.internal.utils.WizPacketConverter	Incoming packet from 172.28.48.181 to convert -> {"method":"getModelConfig","id":162,"env":"pro","result":{"devTotal":1,"headTotal":1,"swHead":0,"ps":2,"hasGradient":1,"nightLightOff":0,"stdbyPin":12,"minDimLevel":10,"devices":1,"devType":0,"lightType":1,"pwmFreq":1000,"pwmRes":11,"pwmRange":[0,100],"pwmRanges":[0,1000,0,1000,0,1000,0,1000,0,1000],"wcr":50,"nowc":1,"cctRange":[2200,2700,6500,6500],"renderFactor":[200,255,180,255,0,0,42,0,0,0],"wizc1":{"mode":[0,0,0,0,0,0,0]},"wizc2":{"mode":[0,0,0,0,0,0,0]},"drvIface":0}}
13:13:48.876	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Scheduling reoccuring keep alive for every 60 seconds for device at 6c:29:90:54:ee:42.
13:13:49.876	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Polling for status from device at 6c:29:90:54:ee:42.
7

Evidently the binding does not have a restart retry strategy; so once it is marked as offline, it remains that way. Personally I would implement a restart retry for say 2 or 3 attempts before finally marking it as offline. But in any case that would really just be a work around for the underlying issue; which is that there is no data being sent for 5 minutes. => So how often does this occur? Is there some pattern to the dropout e.g. every 24 hours, ‘n’ hours/minutes etc.?

8

No experience with Wiz, but from your logs the device responds to the startup packets “getSystemConfig” and “get ModelConfig” so goes online, but I don’t see any response to the “status” polls, so goes offline. Do you ever see a successful status poll in the logs?

Also, another thought; on the ThingUI page click the show advanced configs. I’m guessing status poll frequency may be there. Maybe that could be changed? What would be valuable (but I don’t know if it exists in the binding) is what I call a “command poll”. Rather than ping the device every minute, just poll after a command is sent.

9

That bulb is currently ONLINE. Yes, it does respond to the polling. Here is one just now.

15:18:21.563	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Polling for status from device at 6c:29:90:54:ee:42.
15:18:21.563	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Sent packet to address: /172.28.48.181 and port 38899
15:18:21.583	DEBUG	org.openhab.binding.wiz.internal.utils.WizPacketConverter	Incoming packet from 172.28.48.181 to convert -> {"method":"getPilot","id":262,"env":"pro","result":{"mac":"6c299054ee42","rssi":-74,"state":false,"sceneId":0,"r":255,"g":164,"b":0,"c":0,"w":220,"dimming":30}}
15:19:21.584	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Polling for status from device at 6c:29:90:54:ee:42.
15:19:21.584	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Sent packet to address: /172.28.48.181 and port 38899
15:19:21.794	DEBUG	org.openhab.binding.wiz.internal.utils.WizPacketConverter	Incoming packet from 172.28.48.181 to convert -> {"method":"getPilot","id":263,"env":"pro","result":{"mac":"6c299054ee42","rssi":-75,"state":false,"sceneId":0,"r":255,"g":164,"b":0,"c":0,"w":220,"dimming":30}}
15:20:21.794	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Polling for status from device at 6c:29:90:54:ee:42.
15:20:21.795	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Sent packet to address: /172.28.48.181 and port 38899
15:21:22.295	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Polling for status from device at 6c:29:90:54:ee:42.
15:21:22.296	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Sent packet to address: /172.28.48.181 and port 38899
15:21:22.411	DEBUG	org.openhab.binding.wiz.internal.utils.WizPacketConverter	Incoming packet from 172.28.48.181 to convert -> {"method":"getPilot","id":265,"env":"pro","result":{"mac":"6c299054ee42","rssi":-74,"state":false,"sceneId":0,"r":255,"g":164,"b":0,"c":0,"w":220,"dimming":30}}
15:22:22.412	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Polling for status from device at 6c:29:90:54:ee:42.
15:22:22.412	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Sent packet to address: /172.28.48.181 and port 38899
15:22:22.619	DEBUG	org.openhab.binding.wiz.internal.utils.WizPacketConverter	Incoming packet from 172.28.48.181 to convert -> {"method":"getPilot","id":266,"env":"pro","result":{"mac":"6c299054ee42","rssi":-73,"state":false,"sceneId":0,"r":255,"g":164,"b":0,"c":0,"w":220,"dimming":30}}
15:23:22.620	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Polling for status from device at 6c:29:90:54:ee:42.
15:23:22.620	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Sent packet to address: /172.28.48.181 and port 38899
15:24:23.122	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Polling for status from device at 6c:29:90:54:ee:42.
15:24:23.122	DEBUG	org.openhab.binding.wiz.internal.handler.WizHandler	[172.28.48.181] Sent packet to address: /172.28.48.181 and port 38899
15:24:23.249	DEBUG	org.openhab.binding.wiz.internal.utils.WizPacketConverter	Incoming packet from 172.28.48.181 to convert -> {"method":"getPilot","id":268,"env":"pro","result":{"mac":"6c299054ee42","rssi":-73,"state":false,"sceneId":0,"r":255,"g":164,"b":0,"c":0,"w":220,"dimming":30}}

I have a large UniFi wireless deployment. I have done a site survey etc using software on my Mac and mapped out the ideal 2.4GHz channel layout (1, 6, 11) for this dedicated IoT wireless network.

I’m investigating if there is anything in UniFi that might show why the traffic occasionally breaks down.

10

Well that is positive !

I did peek at the binding code and did see both a polling interval and a restart option (for failed polls) under the advanced configs. Not ideal, but an option. Also do you know what HA did in regard to polling frequency and restarts for comparison?

11

You don’t happen to have multiple VLANs or multiple IPs in general, do you? IIRC the WiZ binding has two methods of getting the state - unicast polling directly asking for the state and getting a response, and the more efficient “push” method where it registers with the bulb and says “send me an update whenever you can.” But in my case, my multiple VLANs means that the binding tells the bulb the wrong address to send update packets to. And the polling is both slower to show the current status, as well as being less reliable in general.

Perhaps @frejos has other ideas of things to check?

12

The status request ping performed for the polling is just asking the bulb for its status, its using UDP protocol to send a request directly to the bulb’s IP address and port. The bulbs usually respond immediately to this request. In some cases though, it has been noted that the bulbs may throttle responses or ignore requests if they get overwhelmed with requests.

Otherwise, I see that the response has a hard coded timeout of 500ms. (@ccutrer given this situation it maybe a good idea to expose this as a configuration parameter) If a bulb is on a weak wifi signal it could possibly be taking longer and just timing out. Be sure the bulb is close to an access point at least for testing. Also, in a multi-access point wifi configuration, the bulbs may get stuck on an access point that isn’t the closest/strongest. Try physically power cycling the bulb to get it to reconnect. Also pay attention to the signal strength when it is responding, is it weak?

You may also be able to see more information if you set the log level for this binding to TRACE.

I have about 50 Wiz devices in my home set up, I’ve found the polling to be extremely reliable, for years at this point.

13

I do have many VLANs. One per type of thing on the IoT 2.4GHz SSID. I use daloRADIUS to give out the correct VLAN based on MAC address. The network in Unifi is configured with RADIUS pointing to daloRADIUS. It works well since a normal network on an SSID can usually only give out a single VLAN.

That said, my Wiz bulbs are all on the main VLAN. Home Assistant, openHAB, Wiz app on iPhones are all on the same SSID. That was because the app on the iPhone couldn’t discover bulbs on a different VLAN.

Perhaps I have an mDNS issue that has surfaced with my trying openHAB if it is trying multicast.

What I have found is that in a high proportion of cases where the Wiz bulb is offline in openHAB simply clicking “Save” on the Thing in openHAB brings it back online.

14

I am indeed in a multi access point scenario. I have 9 UniFi access points of various types around the house. Some are outside in the roof soffits, outside porches etc.

Some things I might consider…

Setting a Minimum RSSI on each access point to make sure Wiz bulbs or anything else gets bumped to the best signal. I will monitor the Wiz bulbs to see what their signal strength is.

Configuring / hard coding each Wiz bulb to use a specific Access Point.

–

The Wiz bulbs are the only devices causing me grief. I wonder if the WiFi chipset inside them is not that great. Perhaps the firmware could be improved.

I have 82 Wiz bulbs. Ugh.

I am here trying openHAB as the integration with Wiz is much better than the one within Home Assistant. Home Assistant is unable to reliably get the current state of a bulb. If I use the Wiz app on my iPhone to change a bulb to a dynamic scene for example this is not picked up within Home Assistant. The same testing scenario within openHAB works perfectly. This has sparked my interest in openHAB to improve my reliability.

I am new to openHAB. Has anyone been to the Miniatur Wunderland in Hamburg, Germany? I have it in my head that the engine under the hood of openHAB is very reliable and it could cope with the volume of automation required there.

15

Here are a few bulbs currently OFFLINE in openHAB…

image
image1498×356 52.4 KB

Looking at one of them in UniFi it has a signal strength of -44 dBm and low transmission retries.

image
image1446×2410 105 KB

I see that the bulb has not roamed at all in the past 24 hours and it is connected to the closest access point.

As mentioned before it does seem like the bulbs are throttling requests in some way.

I wonder if openHAB could change the state of a bulb it thinks is OFFLINE. I don’t have any automations in openHAB yet.