Zigbee 2-1 Switch (On/Off & Dimmer) | Project New Horizon (Blue Series)

So Hot Right Now Projects & Roadmaps
, ,
#326

Thanks! Yeah, we’re pretty pumped at how they’re turning out :slight_smile:

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)) 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 :slight_smile:

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):

image
image1096×884 51.9 KB

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
Thread 2-1 Switch (On/Off & Dimmer) | Project Jonagold (White Series)
#327

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.

#328

Here’s what it looks like with all 7 different lights lit up:

image
image916×1162 80.2 KB

Here’s with LED 1, 4 and 7 lit up:
image

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
#329

I could 100% use it just like that. Looks awesome. Let me know when you want me to test it out. :slight_smile:

2 Likes
#330

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.

#331

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
#332

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.

#333

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.

#334

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
#335

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.

#336

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.

#337

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. :slight_smile:

#338

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 :eyes:

Completely agree. Not only distinguish, but even remember what color is what.

Excellent idea :slight_smile:

@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!

#339

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.

  1. 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)

  1. 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
#340

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”

image
image1018×1702 132 KB

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?

#341

Almost. If you release a thread switch you will still have a potential decision. If you are ready to release that product early, before the MATTER spec is out or anytime before Apple/Amazon/google hubs get updates to Matter, you could do what eve and nanoleaf have done. Release a native HomeKit language over thread product (devices are apple HomeKit only for now though). Once Matter is in use they will release a firmware/software update that leaves thread as is but converts the device to speaking the universal Matter language over thread (then their devices get access to all the smarthome ecosystems in Matter). Thread is is still there and doing the same job connecting devices in both cases.

Where you will need to plan and work with your suppliers is to ensure that current hardware can not only convert from Zigbee networking to thread but you are also as certain as possible you have space to also do a software/firmware update for matter. The logistics and timing likely favor simply doing it once and going Zigbee and/or Matter certified over thread as opposed to taking the Nanoleaf/eve intermediate step and doing small run of HomeKit certified over thread (with added trouble of getting apples HomeKit certification) switches that can later get an update to Matter certified over thread networking.

What I am sure you want to avoid with zigbee is exactly what you described with zwave, looking back 3 years from now seeing how despite your best efforts you skated where the puck was and not where it was going. As long as you ensure the Blue Zigbee hardware can convert to Matter over Thread you should have those bases covered as you intended.

3 Likes
#342

No pressure @Darwyn_Inovelli :wink:

#343

@Vesalius it sounds like you have a good handle on it.

Let me preface this with I am not an expert just an enthusiast. I have been following the smart home since the days of X10 and I remember when Zigbee was as new as Thread is now.

I don’t think I caught any follow up on can two Zigbee devices talk to one another without a hub.
In the original spec the answer is yes. The only thing the hub is for is to communicate outside of the network. Think of a hub more as a translator. Today there are a lot more things built into a hub which makes it difficult to remember the key purpose of the hub. At that some of the things that consumers think are “built in” to a hub aren’t actually built in, they are hosted in the cloud. Saying that I can see why the hub has become this thing that everything must go through. If the communication doesn’t go through the hub it cant get to the cloud and the provider cant add their secret sauce that makes their product better than their competitors.

That being said it doesn’t help that Zigbee is implemented is a way that you may need multiple “Zigbee” hubs to make every thing work together (or at least get to some app on your phone). The downfall of Zigbee is that from the beginning it has been open and there is not enough standard enforcement, so there is nothing stopping a company from doing it “better” or, a more cynical view, forcing customers into their ecosystem by not playing well with others. This as well, is a reason that one Zigbee product can’t talk to another.
If you look at Z-wave it has always had two strikes against it, at least until recently. It has ensured devices meet their standard, and the expense of this has been passed on to the customer, put it beside an equal Zigbee device which one do you think the majority of people will pick. On the other side its source has been closed, making it less appealing from the people that want to play.
If you look at thread, I feel it is the result of people looking at their mistakes. the CSA seems to treat Zigbee as if it is here to stay but I feel it is only here for as long as the products that are out there stay alive. I am hedging my bets on Thread, not because I am currently set up to use it but, because from everything I have seen it fixes the issues of the past in a way an existing standard cant.

Also, I feel it has been expressed here but for the benefit of someone that hasn’t went through the 300+ posts, I didn’t say Matter. I do not know enough about Matter because it hasn’t been released yet, but it is important to understand it is different. I like to use the example of a radio station. Thread, Zigbee, and Z-wave are in essence are what a transmitter broadcast through the air, just like FM and AM radio. Matter is the language the DJ chooses to speak. Matter could have been built to work with anyone of those radios, but because of the benefits of Thread it is the one that was chosen.

1 Like
#344

The only thing I will add here, which makes things harder to keep straight, is that Zigbee specifies both a transmission side and they also defined a zigbee specific language (network parlance it’s called an application layer). Thread only specifies the transmission side, which allows thread to very easily use other application layers (such as Matter or Homekit). It is significantly harder to make another application layer such as Matter work with ZigBee. Requires a beefer sort of hub to do that translation from the always present Zigbee application layer to the Matter application layer. Switches just don’t have the horsepower to do both and remain economically feasible.

6874.figure 1

Thread vs. Zigbee – what’s the difference?

Thread Vs. ZigBee (For IoT Engineers)

totally agree. Even more so because when players with the size and influence of Apple/Google/Amazon get together and in unison agree to back thread/matter it’s not very safe to bet against them. I use homekit over thread now with Apple/Nanoleaf/Eve and even this early it has been great.

2 Likes
#345

With Edge we will likely be trying custom capabilities. We should have edge ready at launch, but if there are any community developers out there that want to take a stab at it., let me know.

Currently there are three modes. Notificatons off, ALL LEDs notification, Single LED notification. If you set a “Single LED” notification you can “stack” an “ALL LEDs” notification on top of it. So, if you have this currently configured:

LED 1 - Red solid
LED 2 - White pulse
LED 3 - Blue pulse

And you then start an “ALL LED” notification to chase red for 30 seconds, once it finishes with the “ALL LED” notification it will return to:

LED 1 - Red solid
LED 2 - White pulse
LED 3 - Blue pulse

In that sense you can have the notifications run sequentially. You can also do other sequential notification configs from the hub side.

6 Likes