mmwave vs. PIR: I LOVE that mmwave is better at detecting presence, which opens up a number of other possibilities, but what it really comes down to for me is speed. I want INSTANT response. Any delays will drive me (and my family) nuts.
There might be times when you wouldn’t want mmwave detecting motion where it might: in a bathroom directly adjacent to a bedroom where someone is sleeping. This should be thoroughly tested before making a final decision as it could be a deal breaker for a number of people. Whichever solution is faster is probably the one I want.
Ideally, you would have both sensors and the ability to control them independently depending on the usage. Leviton has both in a dumb switch, but it might be too much to add both and the smartswitch components in one device. I would be willing to sacrifice the rocker aesthetic and go single-pole style if necessary to get both, if it works good enough (you shouldn’t have to ever touch the switch.)
I’m hoping in this project we can use the MG24 so that OTA between protocols is easy.
Yeah definitely. I read the Reddit reviews of mmWave and the Aqara sensor and it scared me (and the rest of the team). We had the same thought as you to put PIR as well as mmWave in the switch (and who knows we may still – depends on what R&D comes back with), but in talking to the expert, he said it must be a firmware or processing issue bc in all the devices he’s worked on, mmWave has been instant. If that turns out to be the case, then I think we can just get away with mmWave. This is also the reason why I’m hoping to use the MG24 bc it has better specs than the MG21 which is what we are using for the 2-1 and Fan switch.
Exactly – idk about you, but I used to work in a corporate setting and the building was completely outfitted with motion sensor switches. One of the most annoying things was when you were sitting in a conference room by yourself or with one other person and the lights would go off bc no motion was detected. Then you’d have to wave your hands like a maniac from across the room to turn them back on. With mmWave it sounds like it would detect presence which would eliminate the silly wave from across the room lol.
Also, it would solve for bathroom use – let’s just say I like to take my time and browse Reddit and I don’t want the switch turning off in the middle of my throne sitting haha.
Definitely, me too – thanks for bringing the initial attention to it!
mmWave would definitely provide the presence detection like the FP1 as I believe that’s what they use
Awesome, glad to see we’re getting some attention! The more people working on this switch, the better!
Regarding temp, it’s a possibility as I’ve seen some other switches provide temp, but it will really boil down to cost and room on the PCB (and the design of the switch aesthetically). I’ve definitely wanted to put temp sensors in a switch for a long time!
Definitely, we got you! Love the use case too, makes complete sense.
Yeah this has been the challenge for a while now and likely one of the reasons we may not be able to pull it off. However, I have seen this by Swidget, which seems inspiring (I haven’t tested it so I’m not sure how well it works):
Yeah, I definitely need to do more research on adaptive lighting – it’s been one of those things where I’ve heard about it, but I’ve never really paid attention to.
I would love to understand more about what your use case is if you don’t mind sharing?
We can certainly take a look at this from a design perspective and, in fact, @anon640257 also suggested this. Regarding the sensor turning into a config button or something similar, that’s actually an awesome idea. I captured it above in the, “Hardware” section and will see what we can do!
Yeah, definitely an unfortunate miscommunication – hopefully they can fix the firmware for Linus. If it were me, I’d put out beta firmware to their repository and work with him (and whomever else) to fix it. Then once it’s been tested, on the next production run, certify the new firmware and hopefully that fixes things.
But yeah, a little perplexing that something so simple was overlooked. I guess they need community feedback like we are fortunate to get
Ohhh yeah, we thought we had a debate over the 700ms built in delay, wait until we discuss the 4s delay Aqara supposedly has right now haha.
I wonder (and I haven’t looked into this yet) if there would be a way to separate motion vs presence with mmWave. If there is, we could create a parameter to turn off motion, but keep presence or vice versa.
Yeah, @chack pointed out that Legrand also makes one. Certainly a route we could explore!
This is the million dollar question. I asked this exact question to the expert last week and he’s convinced it must be a firmware or processing limitation on Aqara’s product. I’ve seen anecdotes on Reddit of people saying they believe it’s firmware and Aqara plans to release an update, but I’m not sure if it’s true or not.
I’m glad you like that idea. If it ends up being doable, I think it will result in a cleaner appearance and allow for a full-height light bar.
While your attention is here (tangent warning), I think I recall mention that with the Blue series, addressable LEDs were being considered for the strip, but I didn’t see mention of it on this topic. It would be awesome if the strip was addressable and I would be willing to pay more for it! I have notifications for the switch near my front door: solid blue if ran is forecasted and blinking yellow if there’s mail in the mailbox. The issue that I’m hopeful an addressable strip would fix is notification overlap. Both of these notifications could be true at the same time, I currently have to use some virtual switch entities in Home Assistant to track which notifications are active and then have an automation run on state change that enforces a priority so the mail notification displays if both are active. With an addressable strip, each notification could have a separate block of LEDs. I think that would make notifications way more flexible and easier to implement in some scenarios.
All of my lights are dimmable. I tend to put slightly higher equivalent wattage LED bulbs in so I can have really bright lights at 100% when cleaning, but then just typically run the fixtures at around 50% for day-to-day use. This works for the most part, but sometimes it’s midday, a bit overcast, you want to add some light to the space, and 50% might not be bright enough to contribute significantly to the overall brightness of the space. This leads to an interaction where you turn on the light, then have to adjust the brightness manually. I’d like to dynamically set the power on brightness based on the lux value. Put another way, I’m not manually interacting with the light switch because I simply want the light fixture on, I’m interacting with the switch because I want to add brightness to the space (but 100% brightness is typically overkill otherwise I’d just use the double-tap scene I configured to set it to 100%). By periodically polling the lux sensor, I could have Home Assistant adjust the power on brightness so that it is high enough to add brightness to the space when powered on, but not overly bright. It would be neat if this could become local configuration parameters (adaptive_bightness=on/off, adaptive_brightness_weight=numerical value that would be multiplied with the current lux value to determine brightness percentage when turning on the switch) but I’m not sure if there would be enough demand to justify development time.
I could of course buy some separate lux sensors to scatter around, but I find the concept of gaining quick lux coverage of my spaces via AC-powered sensors built into all the light switches to be very compelling. No extra devices to set up, power, and mount somewhere.
I agree that lux is an absolute must, but I’m not seeing the use-case in adaptive lighting? Adaptive lighting is based on the sun position to determine brightness of the bulbs and color temp. So since it’s sun based, lux doesn’t really come into play from what I’ve seen. What we really need lux for is so the motion sensor doesn’t trigger the light when it’s already super bright in the room because it’s a sunny day in July with the sun coming right in the window.
I don’t know if this is assumed, but would this switch be able to handle fan loads? I think this should be a critical requirement so that it could control bathroom fans and the like to shut them off when the room is vacant.
The blue series does have addressable LEDs. The motion switch will share similar firmware as the 2N1 as mentioned in the PRD, so I think it’s safe to say this will have addressable LED for the light bar.
Plus @Eric_Inovelli wants the Aurora light bar, so it has to have addressable LEDs.
You’re probably better off using the fan switch that’s rated for fan loads and use the motion sensor to trigger the fan switch.
My opinion is I don’t want the bath fan to turn on every time someone steps into the bathroom so I’d probably opt for using the fan switch or scene to turn on the bath fan. I had a light switch next to the shower at the last house. I just used rule machine to turn on bath fan once the shower light turned on. There was no reason to turn on the shower light unless you were taking a shower, so it worked. Then I used a double tap at the bathroom entrance to turn off all lights/fans in the way out. It worked.
I feel that the delay of mmwave is solely due to firmware and processing on the FP1. Everything smart home released a video about a month after his FP1 video where he diyed a mmwave sensor and it was way faster and more sensitive. I Built My Own Presence Detection Sensor! - YouTube
Community driven is Inovelli’s strong suit, so I have no question that this WILL only increase on the crazy functionality of the blue series, which is already the most function-rich and capable switch on the market (no question).
I know it’s been Inovelli’s signature look, but the LED bar is undersold IMO. I use this for EVERYTHING. I use it for meeting notifications when I am WFH, I use it for doors open, I use it for when the A/C is running, I use it for nightlights. It’s never been an issue that I run out of notification ideas…
MMWave vs PIR: Price is going to be key here, because I know this is going to be more than the blue series by about the sensor level. ALTHOUGH, you are getting essentially an Aquara P1 + Blue series if you pull off mmWave (assuming reaction time can be ~250ms or faster). I’d be interested in the B2B price point. I can’t be bothered for $100 anything in my smarthome though (frankly).
Lux is typical in most motion sensors. I’d expect to see it here although I don’t use it much personally (I drive most automations on cloud cover). Lux sensors are very cheap.
I agree with separate endpoints for motion and lighting. They can be firmware connected via parameter, but should be COMPLETELY separable.
Adaptive lighting is one of my personal passions, I even helped write one of your blog articles in the past. I look forward to talking to you on this as this IMO is a HUGE opportunity for Inovelli to become the Kleenex of the lighting game!
I keep forgetting that not everyone is likely familiar with the 2-1 switch and the firmware on it (bc it’s not been released yet) but essentially this switch would mimic the firmware on the 2-1, so we’ll definitely have the individually addressable LED’s
Also good news you won’t have to pay more for it haha!
Got it, that makes sense. Let me add that to the software section above so we don’t forget. The good news is that most of the firmware can likely be transferred from the 2-1 to this switch, we’ll just be adding in the motion and lux, so it shouldn’t take too long.
Yes, this is what I’m pumped about too – no batteries to worry about and you can crank the reporting up to the max setting (although I guess we should be careful if there are multiple switches to not flood the network) without worrying about draining a battery.
This is a good point and definitely one that we will have to look at. What we found with the 2-1 is that there are two separate UL requirements for dimming and on/off vs fan control (even if that fan control is simply on/off), so we’d have to make sure we pay for both UL requirements (ugh…).
But yeah, I think it will be worth it in this case.
Our plans are definitely to make everything that’s in Zigbee into Z-Wave and vice versa. Just with the Z-Wave chip issues we experienced (I realize it’s not as bad with other companies, but our specific Z-Wave manufacturer has to allocate chips to Ring, which has been taking up most, if not all, chips) it’s hard to develop Z-Wave right now. We are exploring other options and also with the announcement and release of 800 Series, it should make things easier.
You dang right I do lol.
Yeah that’s definitely one of the downfalls of sharing everything publicly – we see both the successes and more often the failures of plans. Hopefully somewhere in between we hit some dingers.
Wow, that’s insanely fast – especially the teaser at the 28 second mark
Then when he went through and showed it in his home and demonstrated what it could do, I was sold. We need mmWave lol – hopefully we can get it to fit inside a light switch.
One of the other things he references that I thought was a cool idea was putting a sensor under your bed for load detection. Now obviously we can’t put a light switch there, but I hadn’t thought about the automations that could be setup at night time.
Idk about you guys, but I have a small bladder or something at night bc I get up 2-3 times to go to the bathroom and while luckily our switches have the default on parameter, I still have to press a button (I know… first world problems), however with a motion switch, and especially the mmWave one, it seems like you could set it so the light turns on when you get out of bed and furthermore, the video talks about how you can set it to deflect off of walls so you can potentially dial it in to have it detect a couple feet before you get to the bathroom to have the lights turn on for you (at 10% or something).
Yeah I may need to pick your brain on ideas. I feel pretty lame compared to what you just mentioned you do haha.
Yeah definitely – one thing that I forgot to mention in the main thread is that the expert we talked to said there are basically two different solutions when it comes to cost.
Option #1 = mmWave that detects the number of people in a room = ~$20 part
Option #2 = mmWave that does not detect the number of ppl in a room = ~$2-3 part
IMO I can’t see that many, if any at all, reason to spend $17-18 more per switch to determine the amount of people in a room. So, if this is truly the case (and we should find out shortly), I’m thinking the MSRP will land somewhere of $15 more than the 2-1 depending on the other parts needed.
I remember! Thank you
Let’s just hope we don’t lose the trademark if we go the Kleenex route haha, but I like where you’re head is at lol
Yeah this was interesting – especially when it showed the graph of when he was sleeping. Curious on if he ever got that sorted out or not.
I have not been around the forums too much lately but follow some of the videos from Linus Media Group and have been waiting for someone to release a competing switch to the Jasco products with onboard motion detections… Count on me if testing or preorders are required…
One software feature I have not seen implemented is a night light mode. It would be nice if you could trigger the light bar on the switch to activate based on motion to assist a user with finding the light switch at night. You could additionally or alternatively activate certain lights at a very low state. For example, if a user has under cabinet lights in the kitchen, occupancy detected at the switch between certain times could trigger only the under cabinet lights until/if the user turns on the main lights at the switch. As another example, if the switch is paired with smart lights in the ceiling and in smart bulb mode, you could selectively activate just a single bulb rather than all the bulbs in the room to ensure sufficiently low light levels.
Oh dang, I really like that. One of the pet peeves I have w/our switches (yes, even I have complaints lol) is the LED bar at night time being too bright (even on the lowest setting). I basically just turned it off during the night time and back on during the day time, but this would be an awesome solution to that.
And it would seem pretty futuristic tbh.
What would really be cool is if we can change the sensitivity based on the time of day. So, if you’re moving in your bed, the LED bar isn’t constantly going off, but rather it only does if you’re close to the switch.
I do this with remote motion sensing. At night I set the “off” LED bar brightness based on motion:
Motion On: 10% LED bar brightness
Motion timeout/off: 0% LED bar brightness
It’s enough to find my way around in the middle of the night and I can find the switch if needed as well. AND since I set the on level dynamically based on circadian/sleep mode (1%) when I do turn on the light it is VERY dim (min level) such that I don’t wake others.
@Eric_Inovelli let me know if you want a blog post and/or to show you how I do this in HA.