Does the mmWave tech require line of sight to detect presence? i.e., if the switch is next to a built-in bookshelf and a person is in the room but can’t see the switch due to the side wall of the bookshelf can the mmWave penetrate the wood bookshelf and “see” the person?
In my experience with the FP1, it can not penetrate wood
From what I can see with both the FP1 and FP2, Sheetrock will also block the signal. It will however pass through glass.
Project Update: We’re hitting some red tape with Indiegogo and releasing the funds, but fingers crossed that will work itself out this week. Once it happens, we will make the downpayment on the materials as well as start paying the NRE fees (Non-Refundable Engineering).
In the meantime, I wanted to share the speed of mmWave as I know this was an initial concern when we were reading about it in the forums and on Reddit. I don’t think I ever shared this with you all, but here’s a quick video of the motion/presence detection:
This is just an off-the-shelf 24GHz sensor that I put up next to a light switch to simulate as best as I could how the sensor would work.
In the video, you’ll see me poke around the corner as I just wanted to share what the setup looked like and the proximity it was to me. Then I walk through at a normal pace.
As you can see, the lights are near instant. There is a slight delay, but I’m attributing that to the fact that I have the sensor connected to Home Assistant and the bulbs are connected to the Hue gateway, so there is some jumps the signal has to go through. Still, very fast – faster then I could reach over to the light switch to turn the light on.
–
@EricM_Inovelli has been testing this in greater detail for quite some time and has it setup to detect his motion when he comes in the room and the light turns on and then on the way out, he has the sensor detect the lack of presence and wait 15 seconds before turning off the light. He says it has never failed and has been impressed.
–
The manufacturers are suggesting a more customized solution, but we’ve been using this as a benchmark in our discussions.
The Philips Hue motion sensors can’t go through glass so that would be great if the switch was able to.
Use case is if you’re in the shower, you want it to know you’re in there and not turn the lights off early.
Quick update: mmWave Smart Switch with Presence Sensing Radar | Indiegogo
I’ll copy the text here for reference:
July 7th Overall Project Update
Hey everyone!
I wanted to give an update as it’s been a little bit. There’s been a lot going on behind the scenes that I’d like to share.
- Manufacturer Selection
- Contract Negotiation
- Firmware Development
These three things have been taking up a lot of time and while they’re not, “sexy” per se, they are important in setting the foundation for the project.
Manufacturer Selection
We’ve decided to go with a different manufacturer for this project they manufacturer have mmWave experts that have been working on the technology for a couple years now and presented us with the best design to overcome a lot of the obstacles we brought up. They also seemed more knowledgeable than our current manufacturer and had better ties to Silicon Labs, which is nice as there are lots of eyes on this project.
What gave us even more confidence is that they have created smart switches for 5+ years now and are very familiar with our design (I’m not sure if that was a good or bad thing – good in that they are fimiliar with it which means less obstacles – bad in that it may mean someone is trying to copy it). They’ve created switches for a couple of the largest IoT companies and are confident they can create ours, especially since most of the R&D has already been done as they’re using the current 2-1 as a reference point.
Finally, ironically, their firmware engineers have worked on our projects in the past as they used to work for a different manufacturer that we used for our Gen 2’s.
Contract Negotiation
Since this is a new manufacturer, we had to make sure we have the proper MSA (manufacturer service agreement) in place as well as the other various important contracts. This takes a long time and what has consumed a lot of our time. We don’t want to rush into anything before the contract is signed as we’d lose our leverage.
Firmware Development
The last piece of the puzzle was firmware development and what can/cannot be used for the mmWave switches. We managed to get the source code for our current 2-1 switches and while negotiating with the new manufacturer, we were able to determine that almost all of the firmware used on our current switches can be used on the new switches, so we’re way ahead of the firmware development schedule. The only new portion is the mmWave parameters.
This is a huge win for us because we had some growing pains on the 2-1 switches that we didn’t want to have to experience over again, which was another risk involved with moving to a new manufacturer.
–
So where does that leave us on timeline? Well, where we delayed on negotiations, we made up for on firmware development timeline and at this time we believe we’re still on track for the end of December. But of course, I will keep everyone posted.
Hope everyone has a great weekend!
Eric
Founder | Inovelli
Thanks for the update! Now that we’re passed the “boring” (but important) business stuff, I’m looking forward to seeing updates on the exciting technical development!
Me too lol!
WHOA! This is huge!!
Definitely a valid problem! My concern with the sensor working through glass is that it would pick up movement outside windows (e.g. animals; pedestrians wind causing movement of trees, leaves, etc). It may be best to use another sensor to determine shower usage (e.g. humidity or a contact sensor on the shower door) in tandem with a mmWave sensor, rather than have the mmWave sensor try to pick up movement beyond a window.
CONGRATULATIONS!
Eric, You Did It. The Indiegogo Campaign Just Hit $400,000!
** well, not just but it sure hit it.
Hello @Eric_Inovelli, I have a question about this switch. Can you please explain which features will be unavailable when the switch is used without a neutral wire? I know that a bypass will be needed and energy monitoring will not work. Are there any other disadvantages? Specifically I am wondering about whether smart bulb mode will work and whether the switch will be able to act as a Zigbee router without a neutral wire.
Yes it will work with a smart bulb (assuming adequate load) and as a repeater.
@bdr9 – just wanted to confirm what @stu1811 said in that it will act as a repeater and will work in Smart Bulb Mode with a non-neutral.
The features that will be unavailable (at this time – I’m not sure if testing will reveal anything else) will be as follows:
- You cannot use this switch with a dumb/existing switch in a Multi-Way setting (you’ll have to use an aux switch)
- Power Monitoring will not work
- You will most likely need a bypass and this is highly recommended for smart bulbs.
- You will not be able to switch between Leading and Trailing Mode for dimming control (Leading will be the only option)
I think that’s it!
Project Update:
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…