Minor clarification - Zigbee and Thread use the same chips. Thread is one of the transport protocols that Matter is built upon, but Matter itself does not technically require it. As @chack mentioned, assuming Matter is here to stay, most hubs will eventually speak Matter and will bridge Z-Wave and Zigbee (and other devices) to Matter even if they don’t natively support it (or Thread).
Unfortunately there’s a lot of confusing documentation out there (and so many blog posts) that use Thread/Matter interchangeably .
I think Matter may also use the same chips? 100% agreed that documentation isn’t clear when we’re talking Thread vs Matter and the way you clarified is the way I had understood to be the case in the past, so could easily just be getting confused by that link, etc.
Thanks for the link. That’s the first time I’ve seen it laid out that way. Silicon Labs is not helping the confusion here!
Either way, your main point stands: this switch (Z-Wave) won’t talk Matter directly, but that’s not a serious problem since the hub will most likely bridge to it.
There’s so much confusion about thread/matter. And a lot of it is justified. The distinction didn’t apply to Z-Wave or ZigBee, and there are lots of situations where you could correctly complete the same sentence with either Thread or Matter.
ZigBee and Z-Wave are “full stack” protocols. They specify both the application layer (what do you say, and what does it mean) and the transport layer (how do you transport data from one place to another, how do you know when to transmit vs listen on your radio, etc).
Matter is an application level protocol. It can run on any transport protocol that supports IPv6, most commonly WiFi, Ethernet, and Thread.
Thread is a transport protocol. It can carry Matter traffic, and in many ways Matter is the “killer app” Thread was designed for (and vice versa). But it can carry other protocols too, like Apple’s HoneKit over Thread. Like WiFi, Bluetooth, and ZigBee (but unlike Z-Wave) it operates in the 2.4 GHz band. So the hardware needed for a Thread radio is mostly the same as the hardware needed for, say, a ZigBee radio, making it possible to switch from one to the other with a sufficiently large firmware update.
The MG24 chip is (as I understand it) both an SoM and a radio. That means it will be responsible for both the application and transport layers, so it has sdks for Thread and Matter. Other chips may only handle a single layer, and would then only be used with the protocol appropriate for that layer.
So in Inovelli’s case, the upgrade we’re talking about really is both Thread and Matter. The switch will go from sending ZigBee application data over the ZigBee transport to sending Matter application data over the Thread transport.
Having read most of the Matter spec, I think it’s going to be a while before it supports all the functionality needed for the Inovelli switches.
@Eric_Inovelli - I don’t remember if we discussed this elsewhere, but wanted to flag it for the forum just in case. It would be cool if these could have an extra association group specifically for the mmwave sensor. So it would trigger an on when the mmwave triggered and then an off when the mmwave had no presence for a configurable period of time.
We’ve received the STP files and are reviewing them for approval (so they can start 3D Printing the initial samples). One of the internal discussions between the beta testers has been around the lux sensor and how we bring it to life.
While not something we actively marketed (because I wasn’t sure if we could pull it off), it’s something that we feel is important, so we’re trying to make it work.
I was going to go into the designs that we received back, but I think what’s more important before I share is understanding from everyone who wants lux the reasoning why and use cases.
–
Those that want lux built in, I have two questions for you:
Why do you want lux built in (like what use cases are you going to us it for)?
How accurate do you need it to be (ie: are we trying to measure foot candles or are you good with the lux sensor detecting whether or not the room is light and dark)?
Understanding these questions will help us tremendously in what we can get away with from a design standpoint.
The primary use case of these switches is to turn on the lights when someone walks into the room. The lux sensor is to be able to say turn on the light unless it’s bright enough already.
Fully calibrated ft candles seems obsessive, but a reproducible number would be more relevant - after dark with the “other” light on should report the same number from day to day - since that hard coded (or hopefully parameterized, but even so) number is likely to end up determining the flow of an automation.
What’s also important is timing of the lux reporting - the luminance level should be measured at the same time as the motion is detected. E.g. I turn on a light in a room, then walk past the motion sensor for another light - I’d like the motion automation to be based on the luminance of the recently turned on light, not when it was dark 30 seconds before.
My use case would be the same as @mbbush’s. I’d like to be able to tell if the room is already bright enough or not. For example, is it a cloudy day and the blinds are closed, or is the room bright enough from natural light.
Accuracy isn’t too important TBH. Just a general idea of the light level to decide if a lighting automation runs or not.
+1 for relative lux levels. But I’m afraid there will be a fairly narrow margin where some of the community think its still too dark and others disagree. I think granular lux readings are valuable to have, but the exact calibration, not so much.
I care a lot more about being able to say my tipping point for a particular switch in a particular room with its own shadows and light angles is 37 because that’s what my testing in that room has decided is my tipping point. Than I do about 37 being exactly 37 candles or whatever the proper unit of measurement is.
I also have a motion detection question. I know mmwave is better at presence detection than IR. But how does it handle motion for non living things?
Here’s my use case. I want to put one in the garage. I want it to detect motion not only for people, but also when a car pulls in. I assume mmwave is good for that too, but everything I’ve read was about human presence detection since that’s the primary use case.
And to expand slightly, if we measure the light level at (@chowell’s example) 37, the same light level should be measured at 37 for all days in the future (so not changing with time or temperature). But if the switch dies & gets replaced with another one, we don’t expect that one to measure exactly the same number. We don’t need “true” calibration where all switches would be calibrated to measure the same number, just consistency within that switch, across time.
I’m afraid of this, too. Everyone makes fun of the Zooz 4-in-1 (ZSE40) for effectively only reporting “light or dark” (technically a 0-100% scale of who-knows-what, convertible by some non-linear formula to a rather narrow range of questionably useful lux values). I wouldn’t want that to happen here.
But I’m not sure I’m on Team “Sensor in the Switch” anyway (measuring lux in a room you’re lighting is inherently problematic), so I’m not sure I really care.
I’m thinking the primary use case for this sensor is deciding whether it’s “bright enough”, so the light doesn’t need to be turned on. Given that, I would think we’d like a fair bit of precision at the lower light levels. E.g. I might not want to turn on the bathroom light at night if there’s moonlight coming in the window. But I don’t care too much at higher levels. E.g. whether the sun is coming in through one window or three (not turning the lights on for either).
However, you are right, I can come up with other uses where 1 window vs. 3 could be significant (might be able to see the TV with 1 window but should automatically lower the blinds for 3!).
For this “primary” use case, and assuming that the motion, lux & controlled light are all together, then knowing the light level at the switch just before the automation decides whether to turn it on seems reasonably useful.
On the Lux sensor use case questions, my use case is this:
I plan on using this in my dining room to turn on the table lights if:
a) motion is detected in the room and
b) it’s dark enough, since there are windows on two sides of the room providing natural light already.
My wife prefers the natural light, and I want the lights to turn on automatically, so the compromise is to turn them on automatically sometimes. So a lux sensor that can tell at least a good reliable range from 0-100 (or whatever lux is measured in… I’ll admit I haven’t used one before) is a great deal. If there’s no lux sensor, I could just disable the motion sensor based on the Solar elevation using Home Assistant, but it would be better to just use the brightness of the room it’s in IMHO.
Use the these as switches as intended to control a load and/or smart bulb.
My ask under #1 is as follows:
A dimmer variant.
A 4-speed fan control variant.
One of the overlooked use cases is a clean install of a mmwave sensor (rather than wall mounting it or having it sit on a desk, table, or counter) in mmwave-only mode (not connected to a load) throughout the house by expanding gangboxs by 1 gang. An example is a bathroom with a sink area that is separated by a door from the shower and toilet. The sink area has a single light switch for which I am using a Lutron RadioRA3 switch. The shower and toilet area has two switches: a light switch and a exahust fan switch. I want mmwave detection in both areas due to challenges with PIR. I will expand the gangbox in the sink area to add a mmwave switch (which won’t have a load on it) so I can keep the Lutron switch. I will replace the exhaust fan switch with a mmwave variant (hopefully this switch will support a builder-grade bathroom exhaust fan). The Lutron RadioRA3 light switch will remain.
My asks under #2 are as follows:
An option to lock the switch (so it doesn’t click when pushed) and that Inovelli sells a flat “blank” to replace the decora paddle. That way we can benefit from the mmwave detection and LED indicator without a load, and not confuse guests with a clickable switch that doesn’t do anything.
Confirmation that we can run a builder-grade bathroom exhaust fan off the switch.
I have a stretch ask. Having a temperature, humidity, and lux sensor built-in would be phenomenal (or as upgradable module or modules) that either go behind the “blank” or attach somewhere on the switch. Even a PIR option (as early mmwave sensors were made better with both mmwave & PIR). The clean install issue is a problem when upgrading an existing home. As technology changes so much, or as devices break, the idea of cutting holes in sheetrock and then having to fix them when the a broken device is discontinued is a big problem.
I hope that helps. Let me know if you have questions.
The specifications show this sharing the features of the 2-1 switches, so it should be software selectable as dimmer or on/off.
Also, like the 2-1s, it will probably have the sine wave on/off option, which will likely drive a simple bathroom fan - but I agree, it would be nice if this could be “certified”.
Multi-speed fan might be nice, but in most cases, I’d expect to have 2 switches, one for the lights (which would be this one) and another for the fan (the upcoming fan switch, it’s “4 speed”, so long as you count off!). Then the mmWave motion in this (lights) switch would be connected via bindings/associations/scenes to the fan switch.
I like the “blank” paddle idea. Hopefully it’ll fit the existing “normal” switches too - giving an automation controllable circuit with an indicator, but looking different enough that people won’t expect to be able to push it.
A lux sensor is in the plans already. I’ve seen requests for temperature & humidity sensors before & the usual answer is that a wall mounted switch, with heat generating components isn’t the right place to put these - but, if it could be made to work…!
Having additional sensors (PIR, temp, humidity, air quality, etc) would be awesome but perhaps not realistic for this project. If not, maybe those things could be available in a distinct module that fits in a decora one gang blank plate?
Re the lux sensor, I don’t think it has to be overly precise. Having said that, allowing for accurate (enough) detection of relative lux level would be nice particularly if a dimmer feature can be incorporated. This could in turn nicely tie in with the Project Walt switch, future fan control, sensor plate as above, etc cumulatively resulting in a very useful switch ecosystem.
.