Vreihen,
Can you get me the brand and model? Even just brand would be great. Id like to reach out to them. I am in close contact with many of these reps professionally and would love to shed more kight here for the community.
Agree with the poster below as well. Not medical advice*
First and foremost this is not medical advice. The concern regarding devices (pacemakers and defibrillators) is electromagnetic interference where the device falsey believes you are having a heart rhythm when you aren’t (pacemaker) or having a fast heart rhythm that needs treatment when you don’t (defibrillator). Mmwave is in the gigahertz bandwith, too fast to be in the physiologic spectrum and in the filtered spectrum of the device. In the case of cell phone placement in relation to your device it’s over the concern for case reports causing the reed switch to switch with the magnet in some cell phones (the latest iphone) which changed settings. As always, advice of your implanting physician is most important but if you don’t have an electrophysiologist it may be worth to find one and discuss with them. This is not meant to be medical advice.
What is (or will be) inovelli’s Z-Wave solution for non-light applications? E.G. Fans, outlets, ballasts (magnetic or electric) or any inductive/motorized loads?
Crossposting here from the Zigbee thread
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.
At this time, we’re focusing the mmWave solution on lighting loads. It’s possible that we could add it to a fan switch in the future.
In the bigger picture, we are certainly taking the feedback around the loads you mentioned and discussing how best to move forward.
Now that I’m also answering tickets, I do see the need for a dedicated On/Off switch that can handle the different loads. It’s just a matter of figuring out funding and true demand.
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.
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
Eric, let me start by saying this is a very cool and needed product. Thanks for all of your work on this and your significant engagement with broader community here. After reading through the various threads regarding this, I am interested in supporting the Indiegogo campaign but have several questions before doing so:
(1) Are you still on track for ~December?
(2) Will the final product include a lux sensor?
(3) Have you decided on a 24 or 60 GHz mmWave sensor?
(4) Will this sensor be able to discriminate movement to not react to say pets, someone turning in their sleep/other nighttime movement where having a light turn on would be disruptive, etc?
(5) Any progress on integrations with Home Assistant etc?
(6) Previously (perhaps in the Zigbee thread), you mentioned the possibility of a subsequent “commercial” product that may include more advanced features such as fall detection, number of people detected, etc. Is this still your plan? If so, any idea re timeline and cost?
(7) Finally, somewhat of a newb question but will the Z-Wave switch eventually support thread/matter? From what you’ve mentioned, it seems that there may be a bit of a dichotomy where the Zigbee product may support matter eventually but not the Z-Wave product; is that correct? As an end user, what are the anticipated pros/cons of the two products? Thank you and sorry if this has been addressed elsewhere.
I can try to answer this piece. Zigbee and Matter use the same chips (MG21 and MG24), and Matter is based in part on Zigbee with the same ‘Alliance’ of companies that designed Zigbee (Connectivity Standards Alliance) so there’s an (expected, depends on the manufacturer too) upgrade path from many Zigbee devices to Matter once firmware is made available for those devices. Zwave however uses different frequencies and at least from what I’ve seen, does not have an upgrade path to Matter (just some news about them opening up code and potentially trying to align themselves a bit more, but likely relying on bridge devices to communicate).
How does this affect you? Do you have a smart hub? If so, assuming it will also speak Matter/Zigbee/Zwave, etc it should serve as a bridge between protocols and the hub’s automation will still allow you to use triggers from one protocol to do something to a device on a different protocol. While Matter has some big players and the potential to hit a higher market adoption down the line as a result, I’m a bit skeptical of it really being a game changer in a lot of ways. Ultimately as long as your hub is local (cloud dependency could shorten the lifespan and depends on internet, etc), alive and supports Zwave or Zigbee, you’ll be able to continue using those devices until the hardware fails so even if Matter takes off, none of those should become useless.
It’s going to be hard for anyone to give you a full pro/con with Matter though as while the standard had an official Version 1.0 release back in October 2022, there’s still a ways to go before Matter can achieve feature parity with Zwave and Zigbee.
Thank you for that explanation
Hey thanks for the kind words – we’re excited about it as well!
I’ll try to answer as best as I can, but it’s still fairly early in the process and we don’t have beta samples yet so some of these questions I don’t have the answers for yet.
I haven’t heard otherwise – but I’m starting to doubt this timeline as we don’t have beta samples yet. I’m banking on the fact that we’re way ahead of schedule for the firmware which made up for lost time during the contract negotiations. I asked for an update today, so hopefully I’ll have something early/mid next week.
This was included in the BOM (bill of materials), so unless we decide it doesn’t perform well in field tests, I would say yes, it will be included. I personally want it.
At the very least we are going with the 24 which we’ve been testing for 6+ months now (and the team in China has a great relationship with the mmWave sensor company), but there has been talks about having a dual sensor. I just sent an email asking for clarification.
Yes, but more as a workaround as it’s next to impossible to have the sensor discriminate between humans and animals. It’s very sensitive. The workaround is to add zones – so you would make one that covers the ground where animals are. But I realize that may not help if the animal jumps. More testing needs to be done here.
I haven’t had any issues with light during my testing, even with it shining through my window.
No, too early for this right now – but rest assured, Home Assistant is a priority along with Hubitat and SmartThings to have full functionality. It also helps Home Assistant’s cause that Linus uses it and we want to make sure we don’t screw up his house 
It’s still a possibility, but for now we just want to focus on the consumer version. We unfortunately don’t have a sales team that could be out pitching this to business customers to see if it’s a viable option or there’s demand.
@chack answered perfectly 
Thanks, Eric
Minor clarification - Zigbee and Thread use the same chips. Thread is one of the transport protocols that Matter is built upon, but Matter itself does not technically require it. As @chack mentioned, assuming Matter is here to stay, most hubs will eventually speak Matter and will bridge Z-Wave and Zigbee (and other devices) to Matter even if they don’t natively support it (or Thread).
Unfortunately there’s a lot of confusing documentation out there (and so many blog posts) that use Thread/Matter interchangeably 
.
I think Matter may also use the same chips? 100% agreed that documentation isn’t clear when we’re talking Thread vs Matter and the way you clarified is the way I had understood to be the case in the past, so could easily just be getting confused by that link, etc.
Thanks for the link. That’s the first time I’ve seen it laid out that way. Silicon Labs is not helping the confusion here!
Either way, your main point stands: this switch (Z-Wave) won’t talk Matter directly, but that’s not a serious problem since the hub will most likely bridge to it.
There’s so much confusion about thread/matter. And a lot of it is justified. The distinction didn’t apply to Z-Wave or ZigBee, and there are lots of situations where you could correctly complete the same sentence with either Thread or Matter.
ZigBee and Z-Wave are “full stack” protocols. They specify both the application layer (what do you say, and what does it mean) and the transport layer (how do you transport data from one place to another, how do you know when to transmit vs listen on your radio, etc).
Matter is an application level protocol. It can run on any transport protocol that supports IPv6, most commonly WiFi, Ethernet, and Thread.
Thread is a transport protocol. It can carry Matter traffic, and in many ways Matter is the “killer app” Thread was designed for (and vice versa). But it can carry other protocols too, like Apple’s HoneKit over Thread. Like WiFi, Bluetooth, and ZigBee (but unlike Z-Wave) it operates in the 2.4 GHz band. So the hardware needed for a Thread radio is mostly the same as the hardware needed for, say, a ZigBee radio, making it possible to switch from one to the other with a sufficiently large firmware update.
The MG24 chip is (as I understand it) both an SoM and a radio. That means it will be responsible for both the application and transport layers, so it has sdks for Thread and Matter. Other chips may only handle a single layer, and would then only be used with the protocol appropriate for that layer.
So in Inovelli’s case, the upgrade we’re talking about really is both Thread and Matter. The switch will go from sending ZigBee application data over the ZigBee transport to sending Matter application data over the Thread transport.
Having read most of the Matter spec, I think it’s going to be a while before it supports all the functionality needed for the Inovelli switches.
@Eric_Inovelli - I don’t remember if we discussed this elsewhere, but wanted to flag it for the forum just in case. It would be cool if these could have an extra association group specifically for the mmwave sensor. So it would trigger an on when the mmwave triggered and then an off when the mmwave had no presence for a configurable period of time.
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:
Understanding these questions will help us tremendously in what we can get away with from a design standpoint.
That’s a great idea – @EricM_Inovelli – can you add this to the tech spec if it isn’t there already?
The primary use case of these switches is to turn on the lights when someone walks into the room. The lux sensor is to be able to say turn on the light unless it’s bright enough already.
Fully calibrated ft candles seems obsessive, but a reproducible number would be more relevant - after dark with the “other” light on should report the same number from day to day - since that hard coded (or hopefully parameterized, but even so) number is likely to end up determining the flow of an automation.
What’s also important is timing of the lux reporting - the luminance level should be measured at the same time as the motion is detected. E.g. I turn on a light in a room, then walk past the motion sensor for another light - I’d like the motion automation to be based on the luminance of the recently turned on light, not when it was dark 30 seconds before.
My use case would be the same as @mbbush’s. I’d like to be able to tell if the room is already bright enough or not. For example, is it a cloudy day and the blinds are closed, or is the room bright enough from natural light.
Accuracy isn’t too important TBH. Just a general idea of the light level to decide if a lighting automation runs or not.