My shortcut on IOS says “No Note Provided”.
do you know if this a known issue (I have an Android, so I’m not able to test it)? Thanks so much for your help with this!
Oof, I think this might be related to iOS versions - I saved the shortcut on an iPad running iPadOS 16.1, I’m not sure if it’ll be compatible with older versions (and I have no devices to test this on anymore). Maybe that version skew would explain it.
An alternative method (if a bit more tedious is to make a shortcut with just “Scan QR code” in it - that will display the QR code’s text representation and should allow copying it out by hand. Here’s the screenshot if you want to repro it (and note the “Setup” pane on the right, that is configured to prompt for a icloud Note to save to; if that balks, open the Notes app & tap away any confirmation or setup prompts; this blocked me from running the workflow):
Shoot, no.
I’ll forward onto their team. Great catch!
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 think this probably got lost in the shuffle, would be curious to hear your opinion on it, thanks!
@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.
We’re confirming that the two IEEE addresses are the only ones, but they are the only ones they listed thus far.
We’ll have to tackle the routing issue separately I think. It appears this only effects signal and routing is a side effect.
Whereas it appears in your setup (correct me if I’m wrong) your signal is strong but the routing isn’t working. Is that right?
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?
For clarification, you want the ieee number and a picture of the qr image for each switch or just a listing of the ieee #'s alone?
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).
Same here, if we get to keep them I’ll actually have enough to replace every switch in my house which would be sick!
16.1 is the trick - I manually recreated on 16.0 and it still crashed (side note: typing regex on a phone is no fun)
After upgrade to 16.1 yours and my new one worked.
Slightly tweaked version that will save a pic if it is in one of the bad ranges:
https://www.icloud.com/shortcuts/612beede564a400093426c6092e2ce5b
27/30 bad from Inovelli
0/7 bad from ZWP
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.
What kind of bulbs?
Sengled zigbee 3.0 E21-N1EA, see this thread for more detail