That’s a great idea – @EricM_Inovelli – can you add this to the tech spec if it isn’t there already?
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.
If that makes sense.
1 Like
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.
mmwave is incredibly good at non human things- often too good! It can detect the slightest motion of a curtain moving under a ceiling fan.
1 Like
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.
2 Likes
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. 
This ^ This nailed what I see as good enough and very useful.
1 Like
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.
I have two main use cases:
- 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.
Having additional sensors (PIR, temp, humidity, air quality, etc) would be awesome but perhaps not realistic for this project.
The issue with Temp/Humidity sensors on a switch, is the switch and inside electrical box do get pretty hot… and if you have a double or more gang box, with other smart/dimmer/heavy loads, the switches generate so much heat that a humidity/heat sensor is just too un reliable. Now, having said that, you mention maybe a nice add to Project Walt. Now if one of the buttons on the Walt can somehow be insulated enough and have a small air grill on it, that could be a way to incorperate it into the switch.
I agree, a LUX sensor would be nice, but that is difficult to get a good reading because most switches are not direct for where the light itself is, or a picture hanging over the switches or a shelf will hinder its functionality greatly, and so return on benifit will likely be very few people actually have a useful area, unless maybe like the motion sensor “dumb” switches that are all over the market for decades now, the LUX sensor was a bump out. Come to think of this, a bump out for LUX, Temp/Humidity, even barrowmetric (think BEM680 or SGP30/SGP40 where the sensor to measure Temp, Humidity, Barrowmetric Preasure, IAQ, C02 equivelent, VOC equibvelant, Gas Resistance, etc is the size of about 1.5mmx1.5mmx1.5mm (stupid tiny)). Even a mic with an internal beep for feedback(no need for a speaker) to have hte ability to have a NON-CLOUD feed to HomeAssistant, where you can setup a custom wake word and in every room, have a mic to voice commands (feature released in newer HA releases)
I built my own FULL blown sensor in each room and adding a MIC and speaker to each ESP32 sensor stack. so I have a heatmap of air quality, temp, humidity, LUX, Radar motion, PIR for additional motion feedback, VOC, IAQ, radar distance/movement speed/still/motion/If close enough heartbeat BPM (60Ghz radar), MIC, Speaker (if a room has no radar person in the room, saying a wake word wont activate the sensor, this way i’m not having a mic in two rooms over picking up my comand and failing, and ONLY the switch with movement/detection. Love using the new wake word system in HA, no more relying on slow google/alexa to perfom commands…
Copy/Paste from the Zigbee mmWave Thread:
To catch you up to the parade if you’ve missed it, the last update I mentioned that we would have to push back the production schedule as we really wanted to push to add in lux monitoring which we ended up being able to do. This caused a delay.
This month, we also ran into a snafu in that the mmWave sensor we were going to use tested poorly (HiLink) and their specs did not match what we were promised. I think they were hoping we wouldn’t test the module prior to purchasing it or something as we tested their module alongside two other ones that were similar size and theirs performed the worst. Very disappointing.
We’ve settled on a new mmWave sensor that has a better field of view (150° as opposed to 120°) and tested the best. Much of the month was spent negotiating the price, redesigning the PCB and testing.
–
All this has caused a three month delay with most of the delay coming from Chinese New Year. We’re targeting March 25, 2024 for Mass Production.
That said, a three month delay in exchange for a lux sensor + a better mmWave sensor than what we originally scoped seems like a fair tradeoff. Disappointing, but it could be worse.
The timeline is updated in the project post!
6 Likes