Perhaps related and maybe another hardware issue – I’ve noticed that some LED bulbs that are fine on the Red series flicker when dimmed with the Blue series. It’s a strong 60hz flicker when dimmed to lower levels on some, but not all, LED bulbs.
Is that possibly also a hardware defect since I never saw it with the Red series? Or is that maybe expected given different components in the Blue series?
Seems like the hubitat driver doesn’t have all the state variables labeled yet. I have a 94:de:b8 that seems to be working about 11 feet away from my hub through 1 wall. Do you know what parameter# the LQI is?
I don’t think there’s a parameter for it, just have to go to your zigbee logs to see it.
I have 2 affected switches out of 6. The working one starting with 40: seems to have a low LQI, and I noticed out of hundreds of Zigbee devices I’ve used, it’s the only one labelled “low ram concentratorType” , is that the way it should be in Hubitat?
status:Active, age:32, routeRecordState:0, concentratorType:None, [Plug Iris Basement Stairs, B6B0] via [Plug Iris Basement Stairs, B6B0]
status:Active, age:32, routeRecordState:2, concentratorType:Low Ram, [Switch Blue Zig 3.0 8278 at join, 8278] via [Plug Closet Kitchen Iris, B3FD]
status:Active, age:0, routeRecordState:0, concentratorType:None, [Aqara Button 6, 92B4] via [Syl Hat Fam 1, 592D]
status:Active, age:0, routeRecordState:0, concentratorType:None, [XBEE3_PC_ANT, B1D3] via [XBEE3_PC_ANT, B1D3]
status:Active, age:64, routeRecordState:0, concentratorType:None, [_nightlight_1DA5_909, BF58] via [_nightlight_1DA5_909, BF58]
status:In Discovery, age:0, routeRecordState:2, concentratorType:High Ram, [null, 0000] via [Plug Closet Kitchen Iris, B3FD]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Repeater Tuya Basement By Furnace, 4326] via [Repeater Tuya Basement By Furnace, 4326]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Light rear vest smart 💡, A9CB] via [Light 3D printer, 045E]
status:In Discovery, age:0, routeRecordState:0, concentratorType:None, [Repeater Tuya Porch, DA18] via [Syl Hat Loft 3, 6FEE]
status:Unused
status:Unused
status:Unused
status:Active, age:64, routeRecordState:0, concentratorType:None, [Plug Iris Addition, 1CCD] via [Syl Hat Fam 3, F50A]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Light Front Porch 💡, F35C] via [Light Front Porch 💡, F35C]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Syl Hat Loft 4, C451] via [Syl Hat Library 1, 0B1E]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Syl Hat Fam 3, F50A] via [Syl Hat Fam 3, F50A]
I have a switch that reports its LQI as a constant 255 through HA / ZHA but its working just fine. IEEE is 04:0d:84 series. The other switch I have (Same IEEE) reports as per normal.
Installed 9 Blues yesterday as multi-way smart-to-smart switches. They worked great - until I packed them back into the wall. Then 2 of them stopped responding at all to any updates from bound switches, and stopped updating the switches to which they were bound. 100% failure rate on those 2 switches.
Found this thread - it’s unclear which ranges are impacted (is it all 38.xx and 94.xx ranges, or just 38:5b:44:ff:fe:ee and 94:34:69:ff:fe:08?)
6 of my 10 switches are 38.xx or 94.xx, but only 3 are in the more restrictive ranges. 2 of those 3 aren’t working for me at all.
By the way, for SmartThings users on the Edge drivers - you can view the EUI/IEEE address digitally by digging through “Switch to Bulb(s)” → “Smart Bulb(s) Wired to Smart Switch” → “Smart Switch to 1x Smart Bulb” → “Written Instructions” → “Getting the Zigbee ID” → “Smart Bulb is using an Edge Driver” at How To's | Setup Zigbee Binding - SmartThings When you get to the end of that chain, you find a link to generate an OAuth-like token at SmartThings (SmartThings. Add a little smartness to your things.) and then paste it into an Inovelli page that can list device details (ST Device Info Viewer). Don’t lose the token - you’ll need to re-paste it every time you visit the Inovelli page.
38:5b:44 and 94:34:69 are the ranges I’m aware of from testing that occurred by community members. The 94:de:b8 range doesn’t appear to be affected from personal and others experience as an example. Obviously would have to defer to the manufacturer as I’m sure they have more specific details, but at least at this point, those are the only ranges I’m aware of that have this issue.
Okay, great - that clarifies things, and matches my experience. I have 2 switches in the 94:de:b8 range that seem to be working fine.
I only have one switch installed (94:DE:B8, FW v2.05) but I’m having issues receiving tap events from the switch; sending events (led_effects and on/off) to the switch seems to work great. I’m using zigbee2mqtt v1.28.2-1 on HA 2022.11.1. Fortunately, this switch seems to be working well as a router for several other zigbee devices.
I just checked the other 29 switches I received last week and it looks like 24/30 switches I ordered fall into the problematic IEEE ranges. Assuming more ranges are not added, at least I have six good ones.
I also only have one installed (94:DE:B8 - and upgraded through Z2M to 2.05) - I just went and checked to see if I was having the same issues with sending or receiving messages.
I didn’t see any immediate issue with sending messages ‘like pulse’ or receiving multi-tap events - I did noticed that if I was too quick on clicking it wouldn’t register - I had to be a little slower but deliberate.
But that isn’t to say that this should work for everyone - just adding in my experience.
As many others, I just checked my shipment and 49/50 are in the ‘bad number’ ranges. Just want to confirm what I need to do to get on the list for replacements.
And also to thank you all for working through this.
Glad I checked this thread before installing more than 3 switches, 20/21 of mine are on the naughty list haha.
Just getting caught up on this. 9/10 of my switches are in the bad batch. I filled out the form for completeness, adding the switches I hadn’t installed yet. Thanks for your help with this! I have one switch that seems to function well and it’s great! Looking forward to getting more like that one 
Filled out what form?
When Inovelli was trying to troubleshoot the connectivity issue, there was a questionnaire to provide input about the issue(s) you were experiencing. I believe that’s was the poster was referring to. At this point, since the manufacturer has identified the issue, I’m pretty sure there isn’t any need to provide further feedback.
This is configurable with the button delay entity / setting
Good morning everyone and happy Monday!
I’m feeling much better after a solid weekend of rest. Thanks for all the well wishes, they sincerely helped.
Alright, sleeves rolled up and let’s tackle how to get you guys new switches effectively.
–
I will be sending out a form within the next couple of days that will help us verify those affected and get you on the list for replacements. I need to put together instructions to help people get the IEEE numbers (which shouldn’t be too hard).
–
To answer some of the questions I saw above (feel free to re-ask if I missed them, I’m still sort of sick so I may have missed them).
IEEE numbers affected?
Right now I only know of 94:34:xx and 38:5B:xx but I have a note out to the manufacturer for confirmation as they didn’t mention specifics in their report.
What was the root cause?
In my opinion, I’m not sure how the R1 and R4 was missed during QC, but I think the biggest factor as to why this was missed was the 0.5m testing range. No clue why that was an appropriate testing threshold as I have 10yr old Bluetooth devices that can connect at that range, but they sure can’t mesh properly.
Not trying to rehash any bashing as I know they’ve learned their lesson, but moving forward we’ve moved the testing to 5m for all devices and then spot checks at 100m.
Can these be safely used still?
Yes, the defect has no impact on the safety of the device.
Are all switches in these ranges defective?
We recommend that if you are experiencing any issues to reach out for a replacement. However, if you are not experiencing any issues, it’s up to you. We will honor it regardless.
–
Thanks again everyone for your understanding, I was fully expecting to walk into a pitchfork situation this morning, but was pleasantly surprised
Oof, that’s a tough spot to have an issue. It looks like that part of the PCB is covered with an RF shield, which would be hard to remove without a hot air rework station. I also briefly looked at one of my switches and it seems like there are two MOSFETs that are through-hole soldered, making it difficult to un-sandwich the board without first removing those joints.
Glad to hear the issue has been identified and I look forward to getting replacements.
No shield on the module. But the cap that needs to move is like 1/5th the size of a grain of rice. The mosfets are held by plastic push pins. The entire unit can be safely disassembled but it is time consuming and definitely not fun. I wouldn’t recommend attempting this fix unless you are seasoned and very skilled w/ electronics rework and you have very steady hands.
@Eric_Inovelli glad you’re feeling better and thank you for the information. Once it was confirmed last week that 04:0D:84 was NOT impacted (2 of my 10 switches), I decided I would move forward with installing them. I finally did this morning and wanted to let you know that they worked perfectly. Paired quickly and easily and functioning as desired. I can’t wait to get the other 8 replaced as I can see how high quality the product is when working correctly. Just wanted to share some positive feedback since I know it has been a rough few weeks!
