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.
Why do you want lux built in (like what use cases are you going to us it for)?
Generally, the use is something like, only turn on the light if it’s dark enough to warrant it.
A motion sensor alone will turn on the light even if it’s bright as day. With a lux sensor, you disable the motion sensor (or just prevent it turning on the light) until/unless it’s dark enough to need it.
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)?
Usually LUX is measured on a scale of 1-1000 or so. 1 being pitch black, 1000 being sunlight. It would be nice to be able to set the threshold (as a setting) for disabling the sensor or preventing the sensor from turning on the light (different people might have different thresholds of how dark is dark enough).
Why do you want lux built in (like what use cases are you going to us it for)?
I have multiple use cases for a lux sensor. I want to use it for automation control of shades in rooms that get a lot of sun. I want to use it to determine if my automation auto turns on lights. I want to use it in the movie theater room to determine how bright to turn up lights when a movie is paused.
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)?
I would definitely need more than light/dark to do what I wanted.
Would something like 5-10 different levels accomplish what you want? Also, the ability to calibrate slightly if we’re able to add levels – would that be something beneficial?
I could definitely work with 10ish levels if there was calibration options. So the lux sensor is so-so accurate and I can assign values to the levels. That way I can adjust to something close to what I want, but the cost of the lux is not outrageous to the overall switch price.
For a point of reference I have a few existing Homeseer HS-FLS100+ G2 That sense lux reliably to 900 Lux and the G1 that have a Max Lux setting of 250.
Chart shows the Lux sensor (Outdoor) output for an average week…
A rule I have is using a 250 lux setting outside to control a darker internal stairway… Based upon my experience with this sensor I would have no use case for any lux reading above 400 for a sensor located OUTSIDE
As the use case for this switch is for Interior Lighting, the above curve is not 100% relevant. For reference I have another of the same sensor located in an unfinished basement and it only reached about a max of 35 lux when the basement lights are active… (Sorry No chart as It was not programed to log in InFluxDB)
So when you talk a few steps It would be better to understand an estimated Flux range as this user perception is not linear… Lux 10-20 vs Lux if 220-230. Having Inovelli determine light/dark setting would not be preferred.
Would a solution be to have a parameter that the user can adjust with an offset value(+/-) like one does with when setting up temperature sensor? It would establish a sliding scale above offset its is bright enough, below offset dark…
We definitely don’t need precise lux readings (they won’t be precise anyway, it’s probably easiest to aim for arbitrary units) but it would be really nice to at least get out something more precise than 1-10. Bins that small won’t let people adjust the finer end of the scale to match their actual lighting.
I’d suggest exposing a value that goes 1-256, do the log-scaling in software on the switch so those values are at least ballpark linear to the human eye. This will be much easier for most people to understand and work with than a 2048 count log-scale value.
When selecting sensors, aim for more resolution in the low end of the scale - the difference of a couple lux will matter a lot for some people’s “the lights are off, or very nearly off” automations, where nobody really cares at all about the difference between cloudy and direct sunlight. If the max on the sensor is 500 lux, you’ll save a lot more of the scale for the low light situations where precise control matters.
As far as use cases - my existing motion sensors offer brightness that I can use to help decide “should this light come on, and how much”, this would do similarly. It’s possible to use the various automation frameworks to say “ok, of the 12 lightbulbs nearby, which ones are on, and what does that mean about whether this one should come on?” but that’s a huge pain. It’s much easier to say “it’s dark, so we’ll turn on the lights when someone comes into the room.” The tricky thing is understanding what “it’s dark” means contextually.
A Lux sensor would help me round out my home automation with less upkeep. Cloudy days my house gets darker than usual, thus an automation around “timing of sunset” isn’t always accurate. Being able to kick off/on lights using lux readings versus scheduling would be more accurate and a lot less upkeep from creating routine etc.
For me, accuracy would only need to be accurate enough to tell when a room is dark/light, but would need some accuracy of how to distinguish “cloudy” dark from “night dark”.
Another thought with the lux sensor is how you report those values. I think this was already discussed, but here are some visuals to help. You need to know that big changes in lux at the brighter levels aren’t very noticeable to the human eye, but changes at the low end are. So if we graph it on a linear scale, it doesn’t really match with what our eyes see.
The change in lux during ramp up in the morning from 6:30am to 9am is a very small fraction (maybe 10%) of the max lux if you plot it linearly, but if you do the log plot now that change is 70% of the total. So you are able to capture a LOT more granularity at the dim levels, which is where you need it.
I also would like to have precise low lux but don’t care after,
I wanna know the difference between total dark and low light, for instance, when you wake up at night you need almost no light just to navigate the corridor so you need to know that is not actual dark but just enough light if that make sense.
the log idea seem very good
Will it be possible to know thee distance between the person and the sensor ?
The lux sensor is the most important for knowing when the light can turn on or not. If lux sensor is not integrated into the switch we will need to add an extra sensor in each room. As smart home integrator I never install motion sensor in a room without lux sensor. By adding an external sensor it increases the overall cost of the project and defeats the purpose of choosing the mmWave switch for not having external sensors installed.
I’d be happy to use the lux sensor just to know if I should turn on the lights or not based upon available ambient light to start with. That said, I always like having more options on the data granularity than fewer. I have no idea if I’d use more than a single threshold though, but having it exposed is nicer than buckets/levels just for the ability to choose how to use it without configuring buckets/levels.
Configuring different levels would just add to the complication of using it and describing it, but it isn’t a deal breaker for me.
I already use the lux sensor embedded in my HUE motion sensors to dim based on the lux level (illuminance) in couple of rooms (with Home Assistant). That way, I’ve always the best possible light level.
You product is a smart dimmer switch. Automate the switch action based on the presence is great but automate the dimming action based on the illuminance of the room is the way. And this requires a pretty accurate lux sensor.
It’s ok if day one, it’s not fully integrated and just exposed.
I’m waiting to see if your switch will include or not the lux sensor to actually pull the trigger.
I have some experience with testing MMwave sensors. I like them a lot, but they do require some understanding and that makes me a little concerned about how this product may be received in the field.
I hope you are putting the sensor on the board with a socket. I’d want you to be able to swap the board if needed.
I actually hope you opt for a Bluetooth enabled sensor board to allow for customer configuration. Perhaps allow for the software to toggle the Bluetooth on and off.
The radome design is important. I assume you have addressed this but putting these behind a curved surface that isn’t consistent in it’s thickness of material will impact the function.
The normal orientation of a switch is vertical. Many of the 24ghz sensors are on a board that is long to separate the send and receive pads. These orient horizontal.
MMwave sensors have a back lobe of sensing and shielding can be expensive. Best to check if they can sense more than a few inches behind since these are installing in a wall. They will also sense though materials like drywall.
These will sense pets and ceiling fans and there is very little you can do to minimize that unless you go for an LD2450 and go crazy complex with your customers to make them set up exclusion zones.
Switch locations are not normally located in the most ideal location for a radar sensor. Close to doors and walls. Without a way to adjust direction like you can with a non in wall sensor you are potentially getting a less than ideal field.
I’d suggest considering a 5.8ghz sensor due to board size and the fact that that work pretty well for basic sensing. They penetrate objects better so get one with the ability to control sensing distance. Meaning where the device events on movement.
I like this idea. Based on my experience with about 10 sensors I just have some concerns that people are going to be frustrated with the sensor not working great and you will be inundated with discussions and disappointments.
MMwave is great on the ceiling. Great with no ceiling fans or pets. Fast and accurate. Great at micro movements like breathing and sitting still.
An alternate suggestion for offering an MMwave sensing product would be a wall socket. You can locate them better than light switches or at least you have more options. Honestly, a good sensor might be making a nightlight looking mains powered sensor that plugs into the top socket of a wall outlet. The top of it could pivot slightly to allow for some degree of aiming.
Not right now. Currently the switch will only be produced in Zigbee and zwave variants and based on the performance of the 2-1 Thread/Matter version and what capabilities will be supported by Thread, Inovelli will decide at what point they pursue a Thread version.
Thank you rohan!! This might be the wrong place to ask but will I be able to control “pure” thread bulbs (such as the Nanoleaf essentials) with this switch using Home Assistant as a bridge?
