Thanks for the tip I’m going to have to give this a try. I didn’t really play with the switch but I’m playing with one now and it is a little mushy I’m going to have to redo this one.
1 Like
If they have each IEEE number tied to the person who submitted it for a refund, they could also blacklist the seller from future purchases from inovelli. Not sure if they’d be that cutthroat, and I’m sure people could get around it if they tried, but it could be a reasonable threat. Anyway, I’m hoping we get to keep the defective ones for personal use- to me it seems like the best way to make up for the frustration of more waiting.
I don’t think they need to go that far.
Small business is all about limited resources, so cost-benefit is one of the most important guiding factors.
The knowledge that anyone who sells defective units may have the buyer informed that they knowingly sold said defective unit if the buyer contacts Inovelli acts as a deterrent. Selling a known defective unit can get the seller in trouble with the buyer, the platform they used to sell, and legally. All of these routes would resolve the issue without Inovelli needing to be involved.
What’s the benefit of this proposed blacklist? Are there legal issues that could arise from its creation? Is a blacklist itself potentially bad publicity? How much work is it to ensure blacklisted customers are actually blacklisted (you’d have to write the code to do so)?
Keep It Simple (if Sufficient)
2 Likes
I don’t think they need to go that far either and said it would be cutthroat, but that seemed like a way preventing resales without spending the money to have everyone return them, if they wanted to be extreme. I didn’t think about having the middle man (like eBay or whatever) step in, so that’s probably the better option! I didn’t think about the ramifications of a backlist, it’s just an idea that popped in my head since they’d get & look up the IEEEs anyway.
2 Likes
Did you send an e-mail out about this yet? I sent the form in awhile ago and haven’t heard back.
1 Like
Interested in knowing as well. I saw the expectation was to send the email out this week?
A thought to save on shipping- I have backorders that are coming in December, and I suspect many other people with affected units do as well. Bundle the replacements with the new switches if the logistics work out and if nothing else it will save a box.
2 Likes
I watch this thread because I’m in the group who have defect 2-1 switches. My frustration was very short-lived, because the company and the community were all over this unfortunate issue right up front. For 2+ yrs, I’ve seen nothing but absolute commitment to customer service and integrity from Inovelli. That said, as a business, they can’t drive their business in the ground trying to account for everyone who lacks the same integrity. I just want to go on record applauding Eric and team (and the upstanding folks in the community who won’t be hacking and reselling defect units) for relentless pursuit of a solid suite of products and the strongest community I’ve ever seen. Stay the course!
14 Likes
@EricM_Inovelli I got a zigbee sniffer and am poking around the traffic when a device that is supposedly routed via one of the Blue series fails to respond (the Sengled bulbs are the devices not responding). Here’s what I see:
First it looks like there are a series of retries, the coordinator keeps sending the command, then the final packet is a resoponse from the Blue series switch saying “Bad FCS”.
I don’t know enough about the zigbee protocol to know what this really means, but I’m guessing you do 
Also of note – the Blue series switch that is reporting this “Bad FCS” when routing to the Sengled bulb is not one of the “bad IEEE” batches. It is 0x040d84fffe061243
Frame 1145: 99 bytes on wire (792 bits), 99 bytes captured (792 bits) on interface 0
Internet Protocol Version 4, Src: 192.168.1.3, Dst: 192.168.1.3
User Datagram Protocol, Src Port: 17760, Dst Port: 17760
TI Radio Packet Info
Interface: COM 4
Frequency: 2475 MHz
Channel: 25
PHY: O-QPSK
RSSI: -79 dBm
Frame Check Status: 0x80 - OK
Payload Length: 55 Bytes
IEEE 802.15.4 Data, Dst: 0x3f65, Src: 0xf991, Bad FCS
Frame Control Field: 0x8861, Frame Type: Data, Acknowledge Request, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
.... .... .... .001 = Frame Type: Data (0x1)
.... .... .... 0... = Security Enabled: False
.... .... ...0 .... = Frame Pending: False
.... .... ..1. .... = Acknowledge Request: True
.... .... .1.. .... = PAN ID Compression: True
.... .... 0... .... = Reserved: False
.... ...0 .... .... = Sequence Number Suppression: False
.... ..0. .... .... = Information Elements Present: False
.... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
..00 .... .... .... = Frame Version: IEEE Std 802.15.4-2003 (0)
10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x2)
Sequence Number: 168
Destination PAN: 0x2404
Destination: 0x3f65
Source: 0xf991
FCS: 0xdc9f (Incorrect, expected FCS=0x773e)
[Expert Info (Warning/Checksum): Bad FCS]
[Bad FCS]
[Severity level: Warning]
[Group: Checksum]
Data (44 bytes)
Data: 480660804c0f1dec010091f928a7aa2400431206feff840d…
[Length: 44]
3 Likes
All this talk about fixing the switches…I don’t have the hardware or skillset or time available to learn how to fix my 17 defective/broken switches. Nor do I feel like I should have to after spending ~$45 per switch. I get the gravity of the situation and how it’s not inovellis fault or anything, but can we at least get a confirmation email that our defective switch submission list was received and we will be getting replacements? Or should I take the 3 working ones out of my walls, return both 10 packs, and try again when all the dust settles? I feel like customers are in a precarious situation with all of this because the switches we received are broken, we haven’t gotten an email saying they would be replaced (we’re going off this public forum), and the window to return these switches is probably closing soon. (Is it?)
Eric posted elsewhere that they’re extending the ability to return them, so you’re not under some deadline to decide.
After identifying which of my switches were good and getting them upgraded to the 2.08 firmware, I can say that they are fantastic. I don’t think anyone else has a comparable product on the market right now, and these finally work as expected.
I agree that the communication could be slightly better, but I can imagine the chaos unfolding behind the scenes as they’re trying to get things figured out. I think they’ll get there, it’s just going to take some time.
5 Likes
is there a way to disable the inovelli switches as being routers? i also have 6 of the bad batch and they are causing havoc in my environment…
1 Like
I wouldn’t try to join any of the bad batch ones – it just seems too risky for the overall zigbee mesh.
The 3 I have are installed but unjoined, so they’re just acting as dumb switches/dimmers – that’s working fine as I wait for replacements.
1 Like
This would have to be done in the switch firmware. Perhaps inovelli could expose a configuration parameter to use the switch as an end device. Not sure if it would need to be re-paired after or how this works to ensure it’s treated as such.
yes that would be very helpful. spent the past week troubleshooting zigbee network issues, and once I identified the bad switches/disconnected them, everything went back to normal.
would be helpful if invovelli would clearly state to remove or disjoin them from the zigbee network; i specifically asked them if i should leave them in/on net and was told it is fine to keep them on, it should not be an issue. not to say anything negative, support has been exceptional, but this was a mistake and cost me a lot of time.
2 Likes
That’s unfortunate, but I gotta think there was a misunderstanding – I’m guessing Inovelli intended to convey it should be fine leaving them wired up (to use as a dumb switch or dimmer [which can be “programmed” via the paddles]), but they are well aware that the bad batch is bad for meshes, so I doubt their intent was to convey they thought pairing them would be OK.
But very early on, some folks seemed to have some success with bad-batch switches that were paired immediately next to a controller etc, so perhaps something got lost in translation around that time? All the same, I don’t think anyone has ever wholly endorsed trying to keep any of the bad-batch switches active in a mesh.
They could potentially in firmware make it default to an end device for ieee addresses in the bad batch to avoid wrecking the mesh.
@EricM_Inovelli is this possible?
Yeah the ones I have installed are great! I wish I had taken all the red series dimmers out of my old house before I moved. Love inovelli products!
@Courtney_Inovelli @Eric_Inovelli @EricM_Inovelli I appreciate that you all are probably very busy and very stressed with new projects and old problems (this), but it’s been nearly a week since we’ve heard anything from an Inovelli rep regarding our defective switches. Can we please get an update?
2 Likes
Thanks to everyone in this thread, and especially the detailed disassembly video, I managed to make the DIY repair myself. It was a great reason to get out the soldering iron I bought a few months ago and had yet to use . Like magic, just a drop of solder in the right place and it connected right up. Thankfully I only have one more switch to repair, it is definitely a delicate operation.