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. https://youtu.be/VEqWlOeJ2YA
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.
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
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.
This is great idea, I would really like the zwave version of this! I know you said it would come, just making sure the zwave demand is there.
mmWave device would be great product too. I am sure there would be good usecase for a switch and another standalone model. In my case I would need a standalone model due to placement of some switchs.
I also want z-wave to avoid the 2.4 GHz band. As excited as everyone is to jump ship for matter/thread, it’s yet another thing in the 2.4 band which is already crowded. I have far better results with z-wave in 900MHz.
Another option for motion detectors is great. Literally nobody makes a line powered motion detectors that fits in a standard j-box except Jasco for some reason. Is there no demand? I hate battery devices. People are like but oh the battery lasts so long, and I’m like line powered stuff doesn’t even need a battery.
Move the sensor to the top so that it visually aligns with the config button
Inovelli switches can be inverted so that the config button is at the bottom. It’s a configuration done per switch. That’s my preferred setting, as I don’t like the config button to be at the top. I was kinda hoping that I could invert these as well to put the sensor at the top and the config button at the bottom. Especially useful for verbal instructions, “Press the small button at the top (or bottom)” becomes less effective if there are two small buttons (or what appears to be a button) and both are on the same side.
Even better would be to turn the sensor itself into the config button when pressed.
I like the idea of the sensor being a button, but if the config button moved or disappeared it wouldn’t visually or ergonomically match other Inovelli switches. If you use the config button to call a scene to run some other automation, you would expect that to be there on this switch as well.
Dude watching Linus struggle with the smart bulb in his son’s room while using these Inovelli switches in SMB with my Hue lights was sooo painful! Literally these are the only switches on the market that fulfil that niche. It’s actually what made me choose them.
Also, while my Jasco fan and auxiliary paddle switches feel really nice, the motion sensing ones at least looked like they probably weren’t very tactile. (And honestly, I’ve used Lutron switches at my parents’ and I suspect his experience was with a bad batch or something. They felt fine.) I really like the proposed design because it keeps the traditional paddle switch that everyone intuitively knows how to use and looks clean. And probably feels as nice as the others.
One area I will give Jasco a win is that my Inovelli paddles can jiggle slight left or right. The Jasco ones I have don’t nearly as much. But that’s miniscule.
I think a motion sensor that takes up a whole slot is a tough sell. A multipurpose device that did temperature, sound, motion, lux, vibration, humidity, maybe an RFID reader or some generic buttons and and RGB indicator LED too… No relay or anything, just line voltage and Decora shaped… I’d pay $100ish.
I have two Eaton Z-wave dimmers that have bad Z-wave modules. They dim just fine, but they’re “dead” on Z-wave. If replacing just the daughterboard could make a bad device work again, that would be a nice way to allow end users to repair their devices easily. I don’t know what Inovelli’s QA says about where their devices fail, but a modular approach might be beneficial if they see that a lot of their issues are with the zigbee/z-wave sections.