If you were to go the mmWave route, would you go the with 24GHz or 60GHz sensors? I believe 60GHz are superior and can distinguish between motion of humans vs inactive objects like a fan
A built-in lux sensor would be amazing too!
1 Like
Great question - we’re still waiting for the manufacturer to come back with a recommendation but we should hopefully hear some preliminary ideas by the end of the week (at least that’s what I’m told).
Ultimately, it will come down to cost and what the MSRP will have to be based on that cost.
1 Like
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.
1 Like
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.
1 Like
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.
Any chance this could be z-wave to avoid the crowded 2.4GHz space?
EDIT: and what happened to the original motion switch planned in the 2020 roadmap (2020 Product Roadmap)?
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.
1 Like
Potentially down the road I would think. Zwave chips are still unobtainable (unless you’re the Big 5).
2020 happened, so that’s probably what happened to the Roadmap.
1 Like
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
1 Like
Oh man, where to begin.
-
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!
4 Likes
He also used a 24GHz sensor vs 60GHz sensor in the FP1. Wonder if that has something to do with the delay
1 Like
Great reminder – just added it!
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.
1 Like
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…
1 Like
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.
1 Like
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.
Adding this to the list above! Thank you!
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.
Not just brightness but color based on time of day could be nice as well. red isn’t as harsh in darkness and doesn’t ruin your night vision
1 Like
From a hardware perspective, I would love to eventually see devices where the zwave/zigbee chip is on a detachable low-voltage daughter board. Basically, put the physical buttons, mosfets, LEDs, transformer, etc on the main board, and then have the chip/firmware/radio on the daughter board. This would allow for some of the same hardware to be used across multiple SKUs. It would even allow you to more quickly add support for Wifi, BT, or whatever the next “standard” home automation protocol ends up being.
From a software perspective, this is what I would like to see from a configuration standpoint (Its written for zwave because that is what I am most familiar with, but a lot of this can probably be used for zigbee too)
-
PIR Sensor
- Enabled (default): PIR sensor is enabled
- Disabled: PIR sensor is completely disabled. It will not send any reports to the hub, and cannot be used to control any devices
-
PIR Command Type: used to determine what types of command are used to control the load
- On and Off (default): ON command is sent when motion is detected, OFF command is sent when motion is cleared
- On: ON command is sent when motion is detected, no command is sent when motion is cleared
- Off: OFF command is sent when motion is cleared. No command is sent when motion is detected
-
PIR Load Control: used to determine what devices the PIR sensor controls
- Local device: Sensor controls the local load only
- Association Group: Sensor controls associated devices only (useful if you want a sensor in one area to control a light in a different area)
- Local + Association (default): Sensor controls both the local load ans associated devices
- Disabled: Sensor does control any load (but still reports status updates to the hub for automations if configured to do so)
-
Physical load control: used to determine what devices the physical buttons control
- Local device: Physical buttons control the local load only (not associated devices)
- Association Group: Physical buttons control associated devices only (can be useful if used in conjunction with “Special Operation” option below)
Local device + Association groups (default): Physical buttons control both the local load and associated devices
Disabled: physical buttons do not control local load or associated devices (but still send scene updates to hub)
-
Zwave Load Control
- Local device: Commands received via zwave control this device only (useful for virtual 3-way setups_
- Association Groups: Commands received via zwave associated devices only (I cant think of a valid use case for this option)
- Local device + Association group (default): Commands received via zwave control this device and associated devices
- Disabled: Commands received via zwave do not control local device or associated devices (I cant think of a valid use case for this option)
-
Special Operation: Holding the config button and then pressing the on/off buttons can be used to control devices or change some settings
- Local device: When the config button is held, button presses can be used to control the local load
- Association Groups only: When the config button is held, button presses can be used to control associated devices
- Local device + Association group (default): When the config button is held, button presses can be used to control local load and associated devices. (this option is set as default to prevent frustration that happens when someone fat-fingers config+on when attempting to turn on the light)
- Enable/Disable PIR sensor: When the config button is held, pressing the ON button will enable the “PIR Sensor” config option, and pressing the OFF button will disable the “PIR Sensor” config option
- Disabled: When the config button is held, the on/off buttons do nothing
-
Smart Bulb Mode
- Normal (default) - switch behaves normally
- On/OFF - Switch outputs 100% if brightness level > 0. Dimming is disabled, but switch still behaves as if dimming works (you can set dimming value to 1, but it will still output 100%)
- Smart Bulb Mode - Switch always outputs 100%, even when off
-
PIR Sensor reporting
- On (default). PIR updates sent to hub
- Off. PIR updates are not sent to hub
-
PIR On Level. When a motion event would result in light triggering ON, use this brightness value instead of full brightness
- 0 = off
- 1-99 = brightness level
- 100 (default) = default on level
- 255 = restore most recent (non zero) value
-
PIR Off level. When a motion event would result in light triggering OFF, use this brightness level instead of off
- 0 (default) = off
- 1-99 = brightness level
- 100 = default on level
- 255 = restore most recent (non zero) value
-
PIR Ramp on rate. How quickly the light fades on when triggered by PIR
- 0 = instant
- 1-127 = 1 to 127 seconds in 1 second resolution
- 128-253 = 1 to 126 minutes in 1 minute resolution
- 254 = reserved
- 255 = default
-
PIR Ramp off rate
- 0 = instant
- 1-127 = 1 to 127 seconds in 1 second resolution
- 128-253 = 1 to 126 minutes in 1 minute resolution
- 254 = reserved
- 255 (default) = default
-
PIR Reset time: When light is updated manually (via physical buttons), temporarily disable motion detection for a period of time to avoid re-triggering the device
- 0 = instant
- 1-127 = 1 to 127 seconds in 1 second resolution
- 128-253 = 1 to 126 minutes in 1 minute resolution
- 254-255 = reserved
-
PIR Delay time. When motion is detected, it will stay active until no motion has been detected for a set amount of time (be careful with this, as it can cause a lot of report spam on the network
- 0 = reserved
- 1-127 = 1 to 127 seconds in 1 second resolution
- 128-253 = 1 to 126 minutes in 1 minute resolution
- 254-255 = reserved
-
PIR Retrigger time: How long after motion is cleared should the sensor wait another motion report can be sent
- 0 = no delay
- 1-127 = 1 to 127 seconds in 1 second resolution
- 128-253 = 1 to 126 minutes in 1 minute resolution
- 254-255 = reserved
-
PIR Off command delay: how many seconds after motion is cleared before connected load is turned off
- 0 = no delay
- 1-127 = 1 to 127 seconds in 1 second resolution
- 128-253 = 1 to 126 minutes in 1 minute resolution
- 254-255 = reserved
-
PIR sensitivity: used to set the “range” of detection
-
LED behavior - Motion: add some sort of notification or LED effect when motion is detected
1 Like
One thing to keep in mind is mmwave is VERY sensitive. It will activate by wind blowing the curtains, a ceiling fan spinning, a small cat or dog, etc.
So, if it means the cheap sensor activating for ANY motion in the room and unable to tell the difference between 0 humans and 1 human, it may be worth it (or necessary) to go with the more expensive sensor that can actually detect HUMAN motion.
2 Likes