-
-
Notifications
You must be signed in to change notification settings - Fork 66
Firmware 1.21.0 Issues #62
Comments
Oh that's bad. So it seems to be a change in the UDP AIP of the bulb firmware.
So this should be return the state of the bulb. Please turn on the bulb via App and test this |
This is the output I'm getting currently on four of the bulbs:
|
The stack trace error may be related to another bulb in the group the automation was targeting... I assumed it was the four bulbs that were timing out, but I can see where this one is missing the dimming key.
Running the same check on this bulb (before doing anything via the app):
After turning it off and on again via the WiZ app I got this:
When turned off via the WiZ app and polled, the dimming key remains:
|
Thank you for report - I'll try to update my bulb to that FW. |
Sounds good! I'll wait for the next "timeout" to occur with the other bulbs and see what the getPilot output is at that time as well. If there are any other commands I can run against them, just let me know. |
So it seems to be another issue. I'm on the 1.21.0 FW and all features seems to be working without issues or timeouts . I try to reproduce this error. |
The "timeout" issue has been fairly intermittent for me, maybe once or twice a day... I've been keeping an eye on my HA since this morning to see if it happens again, but it may not happen until later this evening for me. |
@sbidy I have one bulb on 1.20.0 (not internet connected) and 1.21.0 (connected to internet) and both seem to be working. Not sure if there's anything that may need to be compared. I do know that where my office is where my wiz bulbs are installed, it's kinda hit or miss if they connect to one AP or the other in my setup. I have noticed that occasionally I have to reboot the one connected to my IoT Vlan, and I always assumed it's because they are stuck trying to connect to the farthest AP. Since I set up the test AP which I use for wireshark, that bulb never seems to go offline (it's only 1.5m from the AP). |
It might be worth reducing the transmit power of one or both of your APs
just slightly to allow your IOT devices to make a better decision.
…On Fri, Dec 18, 2020 at 1:16 PM ChrisLizon ***@***.***> wrote:
@sbidy <https://github.com/sbidy> I have one bulb on 1.20.0 (not internet
connected) and 1.21.0 (connected to internet) and both seem to be working.
Not sure if there's anything that may need to be compared.
I do know that where my office is where my wiz bulbs are installed, it's
kinda hit or miss if they connect to one AP or the other in my setup. I
have noticed that occasionally I have to reboot the one connected to my IoT
Vlan, and I always assumed it's because they are stuck trying to connect to
the farthest AP. Since I set up the test AP which I use for wireshark, that
bulb never seems to go offline (it's only 1.5m from the AP).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#62 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJNWE2OTA3YUAWLQ33KO7DLSVOL6PANCNFSM4VBJ4KSA>
.
|
Looks like it happened again this morning.
The info for those bulbs: #####Office fan lights in order:
#####Living Room Lamp
The fan lights are currently on, as is the lamp. Home Assistant shows the fan bulbs as off right now: Using the WiZ app, I can see that the fan bulbs are currently on with the Overall, it looks like the issue is that since the firmware update, |
I think in case of this exception the status update will stucked. Thats maybe the reason why the bulb will be displayed as offline. Can you maybe ping the bulb continuuesly to check if the is an general network issue? The app will use another connection interface (Rest API with HTTPS). |
I agree that it might just be the I've pinged the various bulbs for several minutes, but no packet loss, and response times have been <= 22ms, averaging about 5ms. |
OK, so please try to ping the bulb for a longer time (24h). It is really difficult for me to reproduce such an issue. I'm note sure if this is a problem of the bulb or HA. I will have a look into the exception handling. Because normally if the bulb is offline the UDP call will run into a timeout and another exception will popup. But I have an idea what's maybe happened. The bulb can also return a error messsag as json and this will currently not parsed and handheld correctly in the pywizlight. |
I have some Model ID 23007 A19 bulbs that have updated to that firmware. No issues to report so far. |
Here's my ping results, it's been a little over 23 hours.
The error did happen again today for me. I also think I found something in my automation script that might be related. When setting the effect to I'm going to see if removing the brightness setting fixes things for tomorrow. |
I'm having the same issue now after doing a fresh install of HA, I have the same mix of bulb types as well (B23065, 230007) all on the 1.21.0 firmware. I can delete a bulb, re-add (wiz app) and about 2min later it goes 'unavailable" in HA. I don't have any automations set and at the moment few integrations, just enough to keep the wife from killing me....for someone who doesn't like my new hobby she sure gets upset when these things don't turn on automatically and she has to touch a switch LOL. |
Now should be fixed. Please update the integration to Version 0.2 in the Releases. Issue:
Fix References |
Firmware 1.21.0 Issues
Bulb Information
Additional Info
I have four bulbs with a Model ID of B23065, other bulbs in the home are Model ID 23007.
Since the firmware was updated to 1.21.0 a few days ago, there have been timeouts and other issues with home assistant with the B23065 bulbs.
At times home assistant will see these bulbs as unavailable and cannot update or change their status. The only way I've been able to "fix" it is to kill the power to the bulb itself, wait, and turn it back on. After a few seconds they will show up as available again, until the next timeout.
During some automations, I'm also getting the following stack trace below in the logs:
The text was updated successfully, but these errors were encountered: