Inconsistent mmWave sensing

Product Support
, , ,
1

I’ve been installing over a dozen of the mmWave blue series switches and have had success with them mostly, but find that the sensing is inconsistent. I have an example here where two of the same switch are in a 2-gang box. They were installed at the same time and they ‘point’ at the same hallway wall. The have the same settings.

Right now the house is empty and you can see that one switch has a single false reading, and one has false readings several times an hour.

How do I get these two devices to behave more similarly?

image
image1648×238 33 KB

image
image852×841 65.5 KB

image
image848×954 43.8 KB

2

I’m also curious. I have similar experiences in my house. Some of them I’ve just given up and turned off presence sensing as a result. I’ll eventually get around to getting the working presence sensor to control both lights instead.

3

I installed VZM32-SN yesterday and also too much false presence detection even on low sensitivity. How to fix it or VZM32-SN just an expensive useless toy?

4

I don’t know much about how the mmWave detection works, but if they are right next to each other, is it possible they are interfering with each other?

5

I guess thats *possible but then why would one consistently be much more “quiet” and well behaved than the other?

6

I wonder if this is an interference case that @EricM_Inovelli has tested? I know he (and I) have tested up to 3 pointing at each other from different parts of the room with no issues. I personally haven’t checked 2 in the same gang box.

If you air gap the one that is working and then reboot the one that is not working, does it behave more like the other one?

7

You were absolutely right. Pulling the air gap on the ‘working’ switch resulted in the other switch reporting significantly less false positives. I also have a 3 gang box with the same problem.

8

Since you’re using Z2M and we have multi area support there (up to 4), my suggestion would be to stick with one switch with mmwave in the same box and create a hub automation driven by a different area if necessary that turns on the other light.

9

I appreciate the suggestion but I don’t want to rely on my HA server to be up to have the lights operate. One switch controls a hallway and the other works in tandem with another switch for a stairwell.

I’ll make add a post in the ‘bugs’ thread

10

Im having the same problem. I have 3 mmwave switches in a 3 gang box, connected 3 different sets of lights. Is there a way to completely disable the mmwave module from emitting radio waves?
Also weirdly enough the middle one has the most false positives, and the other 2 are pretty ok.

11

Not currently.

I don’t think this was a use case that anyone tested during beta since most people only had one switch (besides Inovelli) and I don’t think anyone expected people to put multiple mmWave switches in the same gang box.

12

If you’re wanting all ganged switches to always turn on together with the same detection area, you could use Inovelli dimmers for the additional, and bind the mmWave switch to the others. Save a chunk of change, too. For different detection areas, I don’t know what could be done besides doing the same thing — single mmWave switch — but instead of binding, configurable multiple detection areas on that single switch and use automations based on those areas to trigger the other switches. Hub dependent at that point.

To just have it work as the OP expects, maybe the adjacent mmWave modules could be configured to have synced clocks and staggered emission times, but I think that’s an extremely long shot for many reasons - is that even possible radio and detection wise? Would HLK (the mmWave module manufacturer) be willing to implement it? Would Inovelli be willing to use that functionality if it’s available? Would it even be possible to sync clocks precisely enough between two switches with only Zigbee communication? These are 60GHz mmWave modules, so timing would have to be extremely precise.

13

I skimmed the docs on the sensor and it looks like they do a frequency sweep and would only interfere when 2 or more sensors are close enough to each other in frequency. If one sweeps a bit faster it would probably keep overlapping and passing where other sensors are and look like motion to them. Especially when right next to each other like that since the return would look basically identical and the timing shift would look like motion.

If the sensors have the compute needed HLK could probably just add an identifier modulation at the start of the sweep that all other sensors could use to recognize there are others and it is not noise, and use to time their sweep start to not overlap.

14

Its cool that everyone here is a hobbyist and we have different values like “saving a buck” and the flexibility to just “run an automation” but this company will need to scale at some point and considering builders and commercial applications is paramount. What builder would consider implementing or standardizing on these switches if using them stipulates that you can’t install them side by side (or other physical limitations), or the builder is required to install a hub and setup lots of automations just to get the system to work properly? They’re going to want a solution that they can standardize on and implement with the least amount of time and labor setting them up. They want to install a switch, edit the mode using the paddles and then have it work. You come in the room - lights come up. They stay up until you leave and then turn off after a minute.

15

We are talking about z-wave/zigbee switches from a company that makes z-wave/zigbee/matter devices. The z-wave/zigbee/matter functionality should be goal #1, and anything else like local auto on/off a bonus “because we could” feature.

Anyone looking for a device that does everything they want without a hub should not be looking at z-wave/zigbee/matter devices. Arguing that they should make a z-wave/zigbee/matter switch that does not connect to anything and is 100% local is actually arguing they should make a non z-wave/zigbee/matter version.

For the interference, Inovelli will have to bring that up with HLK and it will be on HLK to fix it. These are not common sensors so I doubt anyone before now has had multiple right next to each other. Hopefully Inovelli is a big enough customer that HLK will rush to make a new firmware that addresses this. If we are lucky they will find a way to auto detect and sync neighboring sensors giving a stronger signal and better range.

16

:man_shrugging: I’m not sure what your experiences are, but my anecdotal evidence is very different. My entire extended family (besides me) are electricians. They avoid any automation like the plague, because they don’t want to deal with supporting any of it after install. They don’t do commercial regularly, but otherwise span the gamut from small starter homes to large tracts of townhomes and apartments to deci-million-dollar custom homes. And plenty of smaller old work jobs (adding a switch or outlet here and there, fixing oddly configured things, etc.). The deepest they get in any sort of automation is using Lutron Caseta with a Pico remote directly bound to a switch so that they can add a 3-way without needing to run wires all over. One of them got certified on Lutron Radio RA 2 for one mega-home, but has since not used it. Another uses very small motion sensors to trigger accent lighting in bathrooms. That’s it. It’s just too expensive (in time) for them to try and support anything more complex. Which to some extent is your point. But I can’t imagine a use case that they would ever want to install multiple occupancy switches in the same gang box without the context of a more advanced automation system with a hub. For basic “turn on all the lights," all the lights that they would want to come on would be on the same switch (why have multiple switches if there’s no intention of switching them on separately??). For a location covering multiple rooms (end of a hallway, or separate sections of a large combined living/dining room, for example), you would want to configure precise detection areas, which means a hub is involved, and if you’re doing that, you can do what I mentioned before and use a single mmWave switch with multiple areas, and automations to control the other switches.

In the commercial arena, I have less personal experience, and my experiences are simply from being highly observant of many office buildings I’ve worked in over several decades, or any other public commercial space I find myself in. 90% of the time, it’s like you say - they want it set-it-and-forget-it. No complications. Which again means not a bank of switches. We’re talking a single switch in a bathroom or a conference room. Then for the larger projects (gymnasiums, auditoriums, libraries, museums, large retail stores, airports, etc.) there’s not a “regular” switch in sight. These things have far more “industrial” building control systems with separate sensors or timers controlling large swaths at a time, usually with centralized switching. And like @cfoos1 pointed out, they are certainly not using z-wave, zigbee, or matter for these systems, and are not Inovelli’s target audience.

So overall, I don’t want to discourage any possible use case for Inovelli - I really love them! - but I also want to avoid any notions that the product is terrible because it can’t reasonably work for some specific use case that is pretty niche, even if for that person it feels mission critical. Not every technology is a good fit for every situation, and decisions need to be made. As I’ve gained experience with these switches, I’ve added some in places I didn’t originally expect, and not added some in places I had originally expected. I use other technologies where appropriate, and view my system as a whole. I love being able to bind devices together so that basic functionality (read: turning on and off and dimming things locally, not automatically turning lights on upon presence or in different lighting conditions) works without my central hub, but have no qualms about relying on the hub for more advanced automations that need to take multiple sensors into account. I realize there is a spectrum there of people that don’t want to do anything that won’t work if the hub is down, and others that do everything in their hub (or worse, relies on cloud systems), and their entire house stops working if the internet goes down or their hub goes offline for whatever reason. I personally think the sweet spot is somewhere in-between.

17

Would be nice to have the ability to turn off the mmWave radio in the switch. I have a lot of dual and triple gang boxes, and although I don’t plan on having all of them mmWave, there is a chance that there may be more than one mmWave in a single box just out of necessity of number of switches or in the future if I move to a different house and don’t want to buy more non-mmwave switches.