I appreciate everything you are doing to attempt to make this right. However, I am NOT looking forward to looking up and manually typing in every single IEEE number and then taking pictures of and uploading QR codes for my large order, while somehow managing to keep track of which I have done and which I have not. For reference, I have 4 10-packs (1 of which was purchased from ZWP.) Unfortunately, they are ALL in the affected ranges.
What about typos? How are you verifying that people haven’t just made numbers up?
What am I supposed to do with the defective switches after replacement? I don’t want to throw them away and/or deal with the hassle that is e-waste recycling. I would prefer to just send them back through a normal RMA process (pre-printed shipping label provided by Inovelli.)
I will do whatever you guys decide is best for the process… but I think the best course is to just do a traditional RMA process. That way you at least get your stock back (and can potentially refurbish them to be usable for resale.) This recoups some wasted costs on this run and you don’t have to worry about unscrupulous people abusing the process.
Have you been provided an estimate of what percentage of switches is affected? It seems like it must be a LOT, because most posts have it in 90%+ of switches being affected for bulk orders.
Unfortunately I’m in the same boat. I ordered 80 switches and have installed 30 so far before realizing they are all defective (except 1…). Wish I would have found this thread sooner.
At least 3 of my 4 switches are in the ranges specified, I have one more to check. I only have 1 installed, and I haven’t noticed any issues so far, but it’s only been in place for about 24 hours and I have a fairly strong mesh in that area. Should I assume that any in the listed range are affected, or go ahead and install them all and see whether they work?
I think it is a safe assumption that they are all defective, since it is a hardware defect. They will work under certain conditions: a strong existing mesh and no need to use them as a repeater for other devices.
For many of us, we are using large lots of these switches for new buildouts with no other Zigbee devices and that is why we are running into problems.
@Eric_Inovelli I have a few switches with addresses starting with 0x040d84 and they seem to have generally poor signal as well. They’re also exhibiting the problem that brought me here initially, other devices will not route through them. For example:
The bulbs won’t route through the blue series. They drop from the network or have super low lqi and don’t respond rather than routing through the switches. Every one of those bulbs on the map there have line of sight to a blue series switch.
Yeah this is something we’re looking into as well. I think it ultimately boils down to incompatible bulbs and different components, but it doesn’t explain why the “hard” on/off still allows some lights to remain on.
I have a hot air rework station but I will hold off on attempting to fix the switches I have until I learn one way or another if the bad units are expected to be sent back.
Once we have filled out the form and sent in all the screenshots needed will we get some kind of notification once our info is vetted and that we are officially on the list for replacements?
I believe the intent is both the ieee number and a picture of the qr image for each of the switches (either at the switch or the little sticker that has both listed is my understanding).
Side note: @Eric_Inovelli 3 of 7 individuals have damaged packaging and one of the 10 packs (fine on the outside but the cardboard was damaged on the inside on the individual and plastic packaging cracked on the 10 pack). No damage to the switches but might be something you want to keep an eye on.
It’s a little of both. Some of my switches are from the affected IEEE addresses and they have generally low signal quality (or won’t connect at all).
Regardless of LQI or if they’re in the affected address group, devices don’t want to route through them.
My bulbs drop off the network or fail to respond to commands despite having line of sight to a switch with a “good” address and a high LQI. I’ve noticed that if I reboot the bulbs by switching the blue off and on again that after a few seconds they usually all respond again but after some times passes they drop out again. I think maybe they’re only routing through the blue for a little while after startup but then drop the route for some reason.
I didn’t get the email. I also didn’t get the shipping update emails, but it didn’t really matter since I could monitor the status here.
I can just use the form posted in this forum, assuming that’s the actual form being used.
If I didn’t get it, there probably are others. Is there any chance you’re just sending these emails to your marketing list, which would only include those who opted in to marketing emails?
Just scanned my 30 switches, thanks for the iOS shortcut!! That made this a fairly painless process. Only 28 of the 30 are affected, I can install 2 of them!! Trying to be positive…
So I had sengled bulbs before. I actually just replaced them all. Sengled stuff is generally solid but there are known issues with bulbs not liking certain devices. We saw this before with ZHA when there were routers based on TI zstack. I am fairly certain it happens with other hardware combos too. I’ll see if I can find other reports. Latest ZStack router firmware with ZZH, throwing MTORR error and triggering NWK changes · Issue #267 · Koenkk/Z-Stack-firmware · GitHub Adding certain devices would cause huge floods of network conflicts followed by devices dropping. We invested a good chunk of time into this and the main commonality was sengled bulbs.
