Great news. This is the best zigbee platform IMO…especially for home assistant users.
1 Like
Wow these switches impress me more and more! So is there any way to get these working with HomeKit now or will I need to buy a Zigbe hub as well? If I do need to buy the hub, fingers crossed that I will eventually be able to update them to work off of thread. If not, money well spent supporting Inovelli.
1 Like
I have learnt from my experience with my Casa light switch that I need a simple switch. It needs to be so intuitive that a sleep deprived parent won’t screw it up. This is why I love the design of your standard switch.
If I want scene control that’s all I want. The two buttons on the bottom leave room for late night confusion. Yes completely understandable most of the time but leaves a window open for error in the middle of the night. The thing that sets those ones apart is I don’t need to look at the switch to find the right button. I can count up or down and it is an easy find. There is another company out there that does a 2 x 4 grid and I like the looks of that too, but I think the one I posted wins for the reason I stated.
I think my ideal setup would be in a 2 gang box. One gang would be the standard switch, with a default set of controls programmed into it. The other would be the scene buttons that modifies the function of the on off switch. Then there could be a delay programmed I to the switch to turn it back to its defaults.
1 Like
Is the plan to still have children devices for disabling physical control and remote control in smartthings?
YES!! The multi color is what I’ve been missing. So does that mean, and I may have missed it, but does that mean I could have 3 notifications all with different colors displayed?
Thanks! Yeah, we’re pretty pumped at how they’re turning out 
The beta team has made these better and better as well, which is amazing.
In regards to HomeKit, yes, unfortunately you’ll need some sort of ZigBee hub/gateway to get these to work. I haven’t dug too deep into how it will work, but from my understanding ZigBee is needed. The other limitation is what is exposed in HomeKit. I’m not sure (only bc I haven’t tested) if all the advanced features will work in HomeKit.
Regarding Thread and upgradeability, if you’re wanting Thread, as much as I hate to admit it, I think you should wait until we put the MG24 chip in the switch. I mentioned it in more detail above (I’m sure it’s buried by now) but essentially, the chip we have in the 1st iteration is the MG21 and, while it can be upgraded, it will require a burner wire that plugs into the serial port on the switch as it does not support OTA updates (cross-protocol – ie: it will allow OTA ZigBee to ZigBee, but if you go ZigBee to Thread or ZigBee to Matter, it will require the hardwire update). Whereas the MG24 will allow OTA cross-protocol.
We are going back and forth and ultimately I’m waiting for some things to settle internally from an organizational standpoint (should have everything figured out mid-March) but I’m pushing for a separate line that specifically markets to HomeKit (Thread 2-1 Switch (On/Off & Dimmer) | Project Jonagold (White Series) - Projects & Roadmaps - Inovelli Community) that I’d like to get off the ground. It seems like a no-brainer to just create the firmware and make a limited batch to test the waters.
TLDR: The Blue Series initial launch will require a ZigBee bridge to work with HomeKit and the first iteration will require a physical cable to update to Thread (whereas V2 will allow OTA updates). I’m pushing for a separate series that targets HomeKit, but I need the resources to do so – however, in the coming weeks, there should be a big announcement that should free me up to focus more on innovation, which may include HomeKit (knock on wood).
@jrperry – makes complete sense. We had also considered putting some sort of, “brail” on the 5-Button so that you could easily figure out which button is which. I like the aesthetics of the flat button vs the convex design, but I can understand the sleep deprived parent scenario (I have 4 girls lol).
Yes
This is the plan, and works now with the groovy device handlers, but I’m not entirely sure what is supported with the Edge drivers. Possibly @EricM_Inovelli can answer this one!
Yes, we just got v8 of the firmware which has individual notifications built in, so we’ll see how it performs, but this is the goal!
The issue we’re running into that may not be solved is that the way the diffuser works (see terrible illustration below lol):
Basically, how the switch is designed is to create a smoothing affect that makes the LED bar look like it does in the photo above (and how it has for the past couple years). In order to have 7 individual LED’s lit up, we need to come up with a different design.
The good news is that the diffuser pops out really easy so we could, in essence just sell (or put in the package depending on how much extra cost there is) a separate diffuser. My fear is that it will not be ready in a month though as it does take a bit of tooling money/time, etc – so this may be something that’s built into the firmware initially and then the hardware will follow.
Hope that makes sense?
1 Like
I honestly like the smooth look. I would setup my notifications such that they would be recognizable. Yellow/Blue etc. But I get what your saying.
Here’s what it looks like with all 7 different lights lit up:
Here’s with LED 1, 4 and 7 lit up:
So, I think at the very least for the first release, we could encourage people to use 1, 4, and 7 (so 3 different individual notifications at least) – then we could work on the diffuser for a later release.
What do you think?
2 Likes
I could 100% use it just like that. Looks awesome. Let me know when you want me to test it out. 
2 Likes
I’d actually be really curious at seeing what the strips look like without the diffuser. I’m sure most prefer it diffused, but I think it could look nice and “crisp”, and also be easier to identify the dim level, etc.
Thanks, I’ll be waiting on the v2 with the MG24 chip it sounds like. Would be great for a hardware standpoint to have a single Zigbee or thread/matter capable base that you can sell either way or allow for customer switchover later. Probably by the time that becomes reality you won’t need to even entertain a 3rd specific thread/HomeKit variety and can simply use thread/matter as an all inclusive bundle option from Zigbee.
You are right that HomeKit is limiting to your higher level customizations, but this is where most manufacturers have their app (iOS or macOS) to make those work.
1 Like
I’ll give it a whirl later and see if I can get a good pic. I’m waiting to test this myself bc I have it on SmartThings and we’re still working on the updated device handler. All the guys with Hubitat and Home Assistant are having fun though haha.
Yeah definitely – luckily they can all share the same base chip (MG21 or MG24) but yeah OTA’ing from one protocol to another is not possible on the MG21. But, that’s not to say we wouldn’t just release a small batch of the MG21’s with Thread firmware to test the waters (although, they’d run into the same problem as the ZigBee version in that if they want to update to Matter, it would have to be via a hardwire).
It would be nice to get the base firmware completed for HomeKit early though so we can at least understand the capabilities.
Or a distinct and direct copy of my recommendation to add some arrows to the level buttons… I mean it’s pretty damn clear they are snooping.
Once you flash the radio to Thread you can use any ip “language” that the radio accepts. That means current HomeKit (like Nanoleaf or Eve) or future Matter. Apple is planning on moving its HomeKit to Matter, so you should be good to go with a single product.
1 Like
Since I don’t currently use your Zigbee products I likely need to research more, but I am unclear how a single switch is going to ever do Zigbee/matter by itself. In all my reading and digging into Matter there is no mention of any such direct integration of Zigbee/matter on a single device outside of a zigbee device communicating via zigbee to a hub that then converts to matter, just as a hub converts Zigbee to HomeKit, Alexa or google home elsewhere.
Zigbee networking was intentionally not included in the first Matter specification. Only thread/Wi-Fi/Ethernet was given the go-ahead. I know your initial forum post on this preceded those announcements as well as preceded the Zigbee alliance changing its name to the Connectivity Standards Alliance, partially to disentangle the recurring idea that Zigbee networking was directly supported by or included in Matter.
Wow when this community wants to be active they are active! I love it.
I have to say, that makes you 25% braver tham me I went to 3 and stopped.
My two sense is I am sure it would be nice to have all kinds of notifications, but I am not sure how practical it is. My plan is to start off with one and work my way up. I think 7 is over the top and too hard to distinguish even if the diffuser was broken up into 7 pieces. I see my max being 3, so using 1, 4 and 7. That being said I look forward to seeing if I can bring some wled animations to the bar. I think you should run a contest for the best animation.
It’s possible I missed it (long thread!), but I’ll share my out-of-the-box idea…what if notifications were run sequentially instead of in parallel?
So let’s assume all notification animations last 2 seconds. Instead of trying to fit “all” notifications into 7 LEDs all at once, why couldn’t they rotate through? If there’s one active notification (let’s say a red fast-blink), then the LEDs just blink until the notification is cleared. If there’s three active notifications (for example, red fast blink, blue slow blink, and solid yellow), then the LED bar would do 2 seconds of fast red (maybe 4 blinks in that time), then immediately show 2 seconds of slow blue (2 actual blinks over 2 seconds), then solid yellow for 2 seconds, and back to the red fast blink. All notifications are shown within a 6-second time period, before the whole sequence loops back to the beginning and starts again. If a 4th notification pops up, then it gets added to the sequence, making it take 8 seconds to get all the way through before it loops and starts again. 2 notifications get cleared, and the LED bar now takes 4 seconds to rotate through the remaining 2 notifications. I’m guessing a majority of the time, there will only be max 1 or 2 notifications at any given moment (so the loop wouldn’t take all that long to get through), but this allows as many as hardware/software has room for.
Maybe a dumb idea, maybe impossible with the available space in the chip/driver…maybe easier than monkeying around with the diffuser and trying to change a LED bar that already looks beautiful.
Thanks man, super helpful!
Admittedly, this is getting to be confusing lol.
I’m in way over my head tbh and I know Eric M is swamped with getting this line off the ground and making sure it works with all the major hubs, so I don’t think he’s done extensive research into the matter (pun intended!). One of the downfalls of having such a small team. I wish I was more educated on this.
I think I just saw you on Reddit and was reading through your comments and need to work with you (and probably @jrperry) to better understand the relationship from a technical level so I’m not misquoting things.
How my brain thinks is way different, but here’s how I’m looking at it from a marketing/product oriented lens.
I’m going to go on a tangent a bit, but hopefully it gives some context:
Initially, I was interested in Project CHIP (Connected Home over IP) because it promised interoperability between major companies (Apple, Samsung, Amazon, etc) and our goal as a company is to impact the smart home market via community driven products. I know it may be cliche, but whatever lol. Since the beginning, Eric M and I have worked to bring innovation into the category bc I noticed that most of the big dogs just put out, “me too” products that had the basic on/off/dim and maybe an extra parameter. That’s it.
We believed Z-Wave was the best protocol (for the DIY market, I understand there’s difference of opinion here and that’s fine) for allowing us to really bring innovative features (scene control/multi-tap, notifications, bulb calibration, etc) and were very disheartened when Amazon announced they were putting ZigBee in their Echo’s as, in our minds, the only decent ZigBee product was Philips Hue – it was the Wild West, nothing was cohesive, everyone had their own implementation of ZigBee and it was a mess.
Before we knew it Z-Wave was pigeon-holed to specialized hubs and mass market would never understand the power of Z-Wave.
When CHIP was announced, I did not want to be left behind again and again, because we want to get our products to mass market and have an amazing community helping us, this was our chance.
Along the way, I had the unique opportunity to be mentored/coached by one of the founders of CHIP and he mentioned that ZigBee would be a great way to start as it would merge into CHIP/Matter. He is also the one who recommended us to the new manufacturer as they had kind of an, “inside path” to CHIP/Matter.
What he didn’t explain though (likely bc I just never asked) was HOW ZigBee would convert to Matter and the roadmap – he just mentioned we’d be good. And me looking at other companies that run on ZigBee (aka Philips Hue) announcing they’ll support Matter, I just assumed it was possible.
So, the way I looked at it was that we’d start with ZigBee and if CHIP/Matter fell apart, at least our products would still work with all the major Hubs (ST, Hubitat, HA, etc) and also with Amazon Echo.
Idk, hopefully that made sense in terms of the Blue Series, “Origin Story” lol.
But, I’d like to better understand the nuts and bolts on updating from ZigBee to Matter. We’re part of the CSA now and all of their materials are from the ZigBee Alliance (in fact, the NDA that I signed still had ZigBee Alliance on it – they had to retract it and send me the CSA one lol – I get it, we’re all unorganized).
LOL – let’s just say I need the Blue Series to take off to afford 4 weddings 
Completely agree. Not only distinguish, but even remember what color is what.
Excellent idea
@EricM_Inovelli – is this possible? I know we were playing around with this on the Red Series and I feel like someone hacked it with HA or something.
Great idea @quinnjudge – I like this too!
Happy to help any way i can. Yes, that was me on the Reddit forum. No question the naming and changes have made things very confusing recently, more so if you were already following along from a CHIP/Zigbee perspective.
Briefly, Hue and Aqara will support MATTER but only through a separate hub update. Their current switches will still communicate with that hub via Zigbee same as now/before. The same hubs that translates the Zigbee application layer from current Hue/aqara switches to Homekit, Amazon, Google home now. Later new or capable updated older hubs will add the new universal language MATTER (that can talk to all smarthome ecosytems). Caveat aqara recently announced they will releases a separate line of thread/matter sensors and switches (so they are looking to do close to what you have proposed).
Based on what you said I think the Zigbee alliance had early expectations to utilize Zigbee networking with CHIP/MATTER, but they were quickly overruled and Thread replaced ZigBee. Making ZigBee work over standard IP was too hard and never has been finished and Thread was already in use by nest/google and was built up from the beginning over IP using the same 802.15.4 protocol and radios as ZigBee.
Zigbee is 2 things - Zigbee 802.15.4 wireless mesh (does not use IPv6) and the Zigbee application layer communication language that is not universally understood by all Smarthome ecosystems). It’s both the nonstandard connecting wires (no one but zigbee uses) and the nonstandard data (language only other zigbee devices understand).
Thread is only one thing an 802.15.4 wireless mesh using IPv6. Its just the connection like a bare wire and is a standard (IPv6) connection everyone knows how to use.
MATTER is the new standard commnication language (The communication data on the Thread/wifi/ethernet wires) everyone understands.
So once the MATTER spec is released and apple/amazon/google hubs are updated to it you will have these options below to take advantage of MATTER.
- Thread/Matter Inovelli switch directly speaking (via a thread mesh that is shared and extended by all thread/matter certified manufacturers) to any Apple/Amazon/google/smarthings hubs capable of thread/matter.
Thread/matter Inovelli switch → any Thread/matter Smarthome hub from all ecosystems (ie.homepod mini)
- Zibee Innovelli switch directly speaking (via a ZigBee mesh that is limited to only some ZigBee manufacturers) to a Zigbee Hub, Then that ZigBee hub with more resources translates Zibee information to Matter info/commands which is resent (via standard wifi or ethernet) to Matter compliant apple/google/amazon hubs. This is what Hue will do.
zigbee Inovelli switch-> select zigbee hubs-> all Matter smarthome hubs
Hue zigbee switch-> hue zigbee hub (Matter translation)-> all Matter smarthome hubs
1 Like
Awesome, very helpful – where are you getting this info? It’s amazing lol.
So, I guess based on SiLabs MG21 (EFR32MG21 Series 2 Multiprotocol Wireless SoC - Silicon Labs) which is what we’re using initially, Thread could be flashed onto that chip via a hardwire (which we have built into this product, shown below). I’m getting this assumption from the URL above that says Thread/ZigBee can be flashed on that switch and also there’s a blurb on that site that says, “You can start developing Matter (formerly project CHIP) solutions using the EFR32MG21 Series 2 SoCs”
From there, that firmware would convert into Matter?
ZigBee > upgrade to Thread > upgrade to Matter
In other words, if I’m understanding correctly, it boils down to this: one could still take the ZigBee switch and convert it to Matter, but if they started with a Thread switch, they wouldn’t need to convert anything as Thread is basically the same thing as Matter.
Is that correct?