Zigbee / Matter Motion Switch | Project Linus (Blue Series)

NOTE: This is a product pitch to Linus Tech Tips following his issues with a competitors motion switches. The back story is that we were his #2 pick for outfitting his new house and the only reason he didn’t choose us was bc we didn’t have a motion switch. Given the issues he had and the frustration with Home Automation in general, we wanted to show him HA can be fun with the right product and right community backing it.

THIS IS NOT AN ENDORSEMENT BY LTT.

Linus Tech Tips Video: I've been defeated... - YouTube

Our Pitch: Project Linus - PRD 062722.pdf (1.8 MB)

NOTE: Original PRD was updated as the design changed.


Project Team
Feel free to tag any of us with questions. Myself (Eric H) & Darwyn are the go-to’s for overall project management and timeline questions, Eric M is the go-to for any firmware related questions and I’m (Eric H) the go-to for anything else. Either way, we’re all here to help!


Introduction
As per our tradition of working with you amazing people, here’s what this thread allows us to do as a community.

  1. Allows us to keep everyone updated on the project status (either good or bad)
  2. Allows you to participate and help us develop amazing products together
  3. Enjoy each other’s company and have fun talking home automation

How this initial post will be laid out is in five sections:

  1. Project Overview
  2. Initial Hardware & Software Requirements (edited to remain up-to-date)
  3. Timeline (edited to remain up-to-date)
  4. Pinned Ideas & Shout-outs (edited to remain up-to-date)
  5. Weekly Recap

Housekeeping

  • DATES & FUNCTIONS ARE NOT SET IN STONE: Just a reminder that all dates and functions are sometimes fluid. We have to make choices based on feasibility, opportunity costs, and overall timeline. I will be as transparent as possible on these decisions, but just a heads up, they may not always be exciting.
  • NO IDEA IS A BAD IDEA: Ok, some are, but honestly throw out anything that you can think of. If we use your idea, we’ll credit you and send you a free device, so take that shot!
  • VERSION 1 VS VERSION 2: Some ideas may be fantastic, but may not make the cut for the first version of the product. Once the product is locked in from a function standpoint, we’ll keep a tally of V2 ideas and then once the product is produced, we’ll move the ideas over to a suggestions/wishlist section.

Ok, let’s get this party started!


Project Overview
The purpose of this project is to expand upon our Blue Series (this will also reach our Red Series line) as well as show Linus and team what the power of a community can do when it comes to creating products and automating our houses.

In addition, there has been a huge market for motion switches and a large B2B client reached out to us for a WiFi/BT version that we are in the process of securing the contract.

We’re excited to finally get some publicity and recognition for our innovative products and I’m personally excited to work on another project with the community as you all are the secret weapon.

Project Name - Linus

We chose the name Linus bc I felt that it could be a rallying cry around what Home Automation can do given the right platform and products. We were excited to be considered on his channel and, while ultimately he went with a competitor, the reasoning is because he wanted a motion switch which we currently didn’t have. Upon hearing some of the challenges he had, frustration with Home Automation in general, and many of our customers reaching out to let us know we should make something for him, we decided to see if we could fast track this project.

So, we’d like to name this project after him and his channel as a way to show him and his audience what the Inovelli community can do and show that it can be night and day in terms of what he experienced with another product.

My goal is to come up with a truly inspiring motion switch with you guys that, regardless of which route he and his team choose, will have an impact across North America as our other switches have.


Linus - Hardware Requirements
We will be using our current dimmer switch hardware with a few modifications. If you’re really interested in seeing what’s under the tent and how we kick off these projects, here’s the internal PRD (Project Request Document) that we presented (Note: The below is a revised PRD as the design has changed).

Project Linus - PRD 062722.pdf (1.8 MB)

Hardware

NOTE: Subject to change as R&D has not kicked off

Hardware - Dimmer Switch (Look / Feel)

  • Responsive Paddle: rests in a neutral state (tap up = on // tap down = off & hold up = dim up // hold down = dim down)
  • Config / Favorite Button: button should be used for configuration of the switch as well as scene control.
    • Should be able to be held (for config)
    • Should be able to be tapped (for scene control)
  • RGB LED Bar: should measure the % of how much the switch is dimmed
    • LED’s should be RGB (artificial white included)
    • LED’s should also be able to be dimmed
  • Colors: dimmer switch will be offered in white (matching Lutron Claro wallplates), but the paddle should be able to be replaced to change colors (almond, brown, red, black, grey, etc)
  • Slim Design: depth of switch should be as slim as possible so that it can fit into metal boxes.
  • Motion Sensor (and potentially Lux) – motion detection either via PIR or mmWave with built in lux (if possible and based on costs)
  • Air Gap: UL requirement
  • No heat-sink tabs: remove heat sink tabs for easier installation (note: may have to sacrifice max wattage)

Hardware - Features & Capabilities

Should follow 2-1 Switch tooling and capabilities if possible.

  • ZigBee 3.0: use the latest ZigBee chipset (should be the same one that will be used for CHIP and compatible with Philips Hue + Amazon Echo Plus)
  • 3-Way / 4-Way Ready: should work in multiple different settings in a 3 & 4 Way setting
    • Should work with an auxiliary switch (like GE’s does)
    • Should work with an existing dumb switch
    • Should work with another smart switch (if wired to another smart switch, it should be able to detect this)
  • Power Monitoring: switch should measure the power consumption
  • ZigBee Distance Estimator: should be able to estimate the signal strength of the ZigBee signal and notify via the LED bar
  • Instant On: when tapped 1x (and scenes aren’t used), switch should turn the bulb on instantly (no delay)
    • Configurable delay in 100ms increments (see tech doc)
  • CFL & LED Compatibility: minimum buzz and flickering
  • 600W: increase the wattage to 600 like GE’s
  • Neutral & Non-Neutral Compatibility: switch should be able to work with a neutral wire or without a neutral wire
    • Should auto-detect which setting it’s in (neutral/non-neutral, aux/dumb) and if it can’t, then there should be a manual override.
  • Auto-Detect Line/Load (and if possible other terminals)
    • No matter how customer wires it, the switch should be able to detect what’s wired/where.
  • Auto-Detect Neutral/Non-Neutral: Switch should detect whether or not it’s connected to a neutral wire or not
  • PIR or mmWave: Prefer mmWave if possible
  • Lux Sensor: Detect light brightness

Linus - Software Requirements
Will follow the 2-1 Switch firmware, but adds in motion/lux parameters

  • On/Off or Dimmer: Switch should be able to be either an on/off or dimmer depending on what the user sets it as
  • ZigBee Scene Control: Multi-taps to activate various scenes
  • RGBW Bar Config: Bar should be able to change colors and dimmed to the customer’s favorite level
    • LED bar will also be fully addressable (thanks for the call out @suzakutk!)
    • Animations that mimic our 2-1 & Fan + the addition of weather animations
  • Auto Timer: Switch should have a timer that shuts the switch off after a certain amount of time
  • Easy Config: Switch should be able to be configured via the config / favorite button.
    • There should be infinite customization via parameters in the firmware, but also set customizations for HUB’s that do not allow parameter changes (ie: Wink)
  • Internal Relay Disable: Internal relay should be able to be disabled locally and via ZigBee
  • Minimum dim level / Maximum dim level
  • Ramp rate configuration: Ability to change how fast/slow light turns on
  • Ramp rate & instant on/off separated
  • Default Dim Level: Ability to set the default dim level
  • OTA Ready: Ability to update firmware via OTA
  • Zigbee Bindings (Individual & Group)
  • Smart Bulb Mode
  • PIR or mmWave: Zone settings and calibration
  • Lux calibration: Ability to adjust lux reading if something is off

Timeline
NOTE: This project is also not officially kicked off – a lot hinges on Linus promoting it as well as the B2B customer order. We also are very cognizant of the other projects that are being worked on and/or stalled and are working on timelines for everything.

Ah, everyone’s favorite part. When is this flippin thing going to be released? Great question – here’s the high-level of what happens leading up to the first release of the timeline:

  1. We present a PRD (Project Request Document) that has all of the above info in it (see above section for the pdf)
  2. R&D (manufacturer) analyzes the PRD and we go back and forth until we can align on 90% of the product
  3. Initial Timeline is released and remaining 10% of product features are added/cut along the way

Again, just want to throw this out there – I don’t have a crystal ball so I can’t predict things that come up along the way. Trust me when I say we’re trying our best to get things launched on time.

Pre-Initial Timeline Milestones:

  • Present PRD: Completed
  • R&D Analyzation: In-Progress
  • Initial Timeline Released: Not Started

Timeline (Estimated)

The initial timeline will be shown below once released and will be updated bi-weekly (if needed).


Pinned Ideas & Shout-Outs
Here are the ideas from the community. We sincerely appreciate them, we love them, and we couldn’t create the products we do without them. So, thank you for your input and let’s continue to innovate together and change the home automation category for the better (NOTE: if an idea is crossed out, it’s not because it wasn’t valid, nor was it something we didn’t consider – we’ve discussed it internally or with the manufacturer and unfortunately it was not feasible).

Hardware

  1. @suzakutk’s idea of moving the sensor to the top and also exploring a sensor/config button combo

Software

  1. @suzakutk: 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) - idea here: Zigbee / Matter Motion Switch | Project Linus (Blue Series) - #17 by suzakutk
  2. @JimK: 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.
  3. @Eric_Inovelli: Ability to customize sensitivity based on time of day (or just have some sort of control over sensitivity)

Weekly Recap
Every Wednesday evening or Thursday morning, we have a meeting with our manufacturer to go over the various projects (status, issues, timeline, etc) and below I’ll provide a recap as well as edit the sections above so we can all keep track. If you have any specific questions you’d like me to ask, feel free to tag me and let me know so I can ask them as well. The weekly cadence for updates will be Thursday mornings (or afternoons depending on when we have the meeting).

4 Likes

TLDR: I’ll need everyone’s help to bring this to life. Convincing Linus and team to go with us will be a huge help! Let’s show him what the power of our community can do for home automation!

Alright everyone here’s the backstory and if this project interests you at all, please head over to Linus’s YT or Twitter, wherever and let him know you think he should go down this path.

Backstory

  • Jake from LTT reached out to us maybe a year ago at this point and asked to test out some switches as Linus was building a new house.
  • We sent him some, kept in communication, but ultimately they went with Jasco because they had a motion switch.
  • Then a couple weeks ago my phone started blowing up with a lot of you commenting on how LTT is having an issue and is not happy with the Jasco switches and their not releasing firmware publicly
  • I reached back out to them and offered to first just try to help troubleshoot, but eventually it turned into a, “hey, why don’t we just create something for you together with our community” and that’s where we are today

How to bring this to life
As many of you know, there have been supply issues, backorders, pre-orders and quite frankly it’s been a mess over here. Luckily around the same time we were in contact with Linus, we also pitched a fairly large company who is entering the space in WiFi/BT and they loved the idea (ours will be Zigbee/Z-Wave).

However, it’s my firm belief that between the B2B deal and if Linus gets behind this, there will be a ton of momentum that we can show the manufacturer to get this officially kicked off.

So, whatever you can do to show Linus and team that it would be in their benefit to go with us and our community, the greater the chances this project has to come to fruition quickly.

On a separate note, would love to hear everyone’s thoughts around mmWave and PIR. We had a pretty good internal discussion with beta testers and another one with an mmWave expert and we’re pretty pumped on the technology.

I’ll come back to edit this with links later – our CS guy is out so I have to answer tickets!

First, this is awesome. I’ve commented on the video and I’ll send 'em a tweet! I was waiting on ordering a bunch of blues until the 2nd/3rd run when they’d have the chip that would allow potentially upgrading to Thread in the future, but it this project comes to fruition, I’ll just have to wait even longer with my dumb switches haha.

Between PIR / mmWave, it really comes down to that delay, I think… Did the mmWave expert you talked to elaborate on the limitations / why there is a delay on these devices? Are they mitigable in any way?

I am assuming the answer is “there is no way that’d fit, you’re bonkers” but what about putting both techs in the switch? Instant-on of the PIR, combined with using the mmWave to detect vacancy.

The mmWave just has a lot of additional applications beyond simple light on / light off functionality that make it really appealing, and may be worth compromising on speed (a bit). Bedroom occupancy / vacancy is a big one that comes to mind (using mmWave is much easier / robust than bed sensors and the like).

2 Likes

This is a very exciting project! I hope Linus picks this up and helps shed some light into Inovelli

Having motion via mmwave may be the way to go, if it can also do presence detection, like Aqara’s new FP1 presence detection sensor

In addition to commenting on the video, consider posting about Inovelli on the LTT forum post as well

https://linustechtips.com/topic/1436954-ive-been-defeated/

1 Like

I came here after linus had mentioned you guys and i really kike how your products look and think it would be great to see you make a switch with motion sensor on it. Is it possible to as well as having a lux sensor to also have a temp sensor in it as well?

1 Like

One software idea (possible I missed it), but please make the motion detection and light control separable via a configuration parameter. For some rooms, I have multiple motion detectors or other conditions that should keep the lights on so I would want the hub to receive the motion detection and make the decision to turn the lights on. In other rooms, I would want the two to be linked.

1 Like

I’m thinking a temperature sensor wouldn’t be feasible. Switches, dimmers in particular, produce heat. I’m thinking that a temperature sensor anywhere within the switch would render accuracy nil. Sort of like the temperature sensors on some watches that aren’t accurate when worn because they pick up body heat.

1 Like

I really hope this product comes to life! I instantly came here to check for conversations after seeing Linus’ video. So happy to see a potential product! I’ve already left my comment on Linus’ video (and I’m not one to typically leave comments on YouTube, but this deserves it!!!).

For the sensor technology, my vote is mmWave with built-in lux. For me, having lux sensors built into all of my switches would be extremely useful for adaptive lighting.

I do have a recommendation from a visual design perspective though: Move the sensor to the top so that it visually aligns with the config button (or move the config button to the bottom). Even better would be to turn the sensor itself into the config button when pressed.

Great to see that you guys are taking this and running with it. Even if the Jasco firmware issue did end up being a bit of a miscommunication, the fact that their switches are that buggy on up to date firmware is crazy. I’m confident that switching to Inovelli would show so much contrast with how things should actually be done

1 Like

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.)

Do we know if the delay with mmwave is an actual limitation of the technology or just one of the current products that we’ve seen?

Thanks! That means a lot :slight_smile:

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 :slight_smile:

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):

https://www.swidget.com/inserts/wi-fi-temperature-humidity-and-motion-sensor-insert/

Appreciate it, thank you!

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, @NateB_Inovelli 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 :stuck_out_tongue_winking_eye:

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.

This video seems to show that it’s pretty instant: https://training.ti.com/3d-occupancy-sensing-home-and-office

Hopefully it does turn out to be a firmware related issue – time will tell but yeah, would love anyone else to weigh in if they have personal experience!

3 Likes

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!

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)?