Inovelli are coming to Europe soon! 
6 Likes
Prepare to be blown away. Their blue series Zigbee dimmer is like a master control center. disguised as a switch.
1 Like
With the can now wide open and the worms crawling out, I’ve got to ask—what’s the actual use case for chaining switches together? mmWave is a motion sensor, so you wouldn’t normally have one switch turning on just because another one does.
1 Like
Ha, well, as one use case for me, I will have one mmwave switch for the kitchen under cabinet lights and one mmwave switch for the kitchen can lights, with the different switches being at different locations/boxes for providing coverage for detecting presence in different parts of the kitchen as a whole. I'll have both lights come on if either switch detects presence in the kitchen.
Certainly welcome input if there's a better approach though!
Binding them would basically turn both switches into a three-way. Even if you remove the motion rule, turning on one switch would turn on the other switch all the time even by physical press. IF this is your desired behavior (the two switches always being connected), then binding is the way to go as it would synchronize both motion and physically presses.
If you do not want to do that (or later decide to change the behavior), it's probably easier to just use a Rule. It won't be quite as instant, but it would allow for greater flexibility.
For me, I see the mm sensor as a distinct entity from the switch. It is useful, only if the box is usefully oriented. There may be good reason to activate devices, unrelated to its switch. and not the switch, I see this as a mm sensor sharing the same space as a switch.
1 Like
I talked them into the lux sensor. I also warned them they needed a back shield for the mm wave, but they found out the hard way.
The mmwave is motion and presence. Sure, micro movements that are presence are motion so it's motion, but obviously different than pir.
I also see the mmwave as separate from the switch. I was excited about this product because it offers a line powered mmwave sensor at torso level with 120 degree spread. That's going to give at least 50% of rooms an invisible motion and presence sensor. The sensor they chose has some capabilities beyond simple sensing so I'm looking forward to seeing how it performs in the field.
The price is a little high from where they originally intended, but a lot of time passed also. If it is solid in the field it's worth the price.
I'd certainly like to see a hubitat driver and imagine a solid low complexity driver with core capability can offer some value.
I hope demand is high and I hope they can keep up with the demand. Looking forward to their configurable keypad.
4 Likes
Hmm. Good points. Hadn’t thought of this. Will need to think about it.
Further qualifying my response, now that Inovelli has started public documentation.
Built-in Basic Driver: I could see this following their "basic" functions.
- Detection Area: preset or coordinates
- Detection Omission: auto-interference set and clear
- Detection Settings: sensitivity and speed
- Detection Behavior: occupancy and vacancy
"Advanced" features are ultimately where I expect to find this to be useful for me, but it may prove daunting to start there. I would learn a great deal about what and how to tune from using the basic driver.
1 Like
They have their driver here:
1 Like
I feel like the mmwave advanced sensor configuration could benefit from an app. Let's say you put a phone against the wall and snap a photo. Use the photo to map your areas etc. App pushes the congig to the switch. Then you have a test mode where you test the config and the app plots the movement and presence on the image. Maybe they have that planned. Or that's where hubitat shines.
25 of these switches finally arrived today. I've installed one of them and the inovelli drivers, and I can control the switch and light bar, etc, but I can't seem to read any motion sensor information from it. Not sure if I am just doing something wrong? I've tried factory resetting the switch and re-pairing it, but it hasn't helped.
Are you using the Inovelli or Hubitat driver?
Inovelli, 2025-12-03 version.
I looked at the Inovelli mmWave Dimmer Blue Series VZM32-SN driver; it has a ton of commands and options for fine tuning the mmWave module (much more than any other mmWave sensor I have seen) :
There is a rather detailed documentation available online :
All these advanced tuning parameters have properly selected default values. For a quick start, you shouldn't adjust them—the mmWave module should report motion as active or inactive right out of the box.
Observe the Current States: motion attribute. Does it change between active / inactive?
4 Likes
Clearly I'm in the minority here, but I think it's redundant and a waste of the limited resources you guys have, and just adds confusion.
I don't see any point in releasing a driver that is less capable than one (or more) that already exists (regardless of whether the HE staff writes it or contracts someone else to do it). No offense, but most third-party drivers have far more features and are updated more frequently than the built-in drivers. Again, no offense intended but I will always look for a third-party driver before resorting to a built-in one.
I'd rather see you guys focus on core capabilities that only you can address, and which others can leverage. Dynamic commands and attributes for example, would allow driver developers to have basic and advanced modes, eliminating the need for "basic" built-in drivers.
Take a poll and ask devs what core features they'd like to see so they can write better apps and drivers.
I know you've been adamant against it in the past, but a HE supported app/driver store would allow third party apps and drivers to be far more discoverable by new users. Google, Apple, Samsung, Microsoft and lots of smaller vendors recognize this. A new user knows nothing about third party drivers and apps until they discover HPM.
I'm sure there are concerns about vetting submissions and all that, but that's something you could contract out and would be infinitely more valuable (IMO) than another in-the-box vanilla driver for something that's already out there.
Caution: Lots of personal opinions to follow, read at your own risk. 
Generally agree, however, the elephant's butt in the room, as you note, is that HE has not shown interest in promoting or managing a third-party app store like HPM. So most HE users (who don't come here) won't know about HPM/community drivers, and their OOBE will be that the device will look like it's unsupported.
They will then have a secondary discovery experience that ranges from interesting but slightly annoying to completely frustrating, depending on how geeky/explorative they are. They have to discover this forum, learn about community apps/drivers, learn about HPM, install HPM, install the driver from HPM, change the drivers on the device page, remember to hit "Configure" and Save, etc. That's going to feel like an epic fail to many customers. And some will be worried about their network security and just not want to use community drivers.
I don't think Bobby likes putting customers through that experience/process. As he's noted before, a basic driver gets our more "basic users" up and running, and they can get an enhanced experience at a relaxed pace if they are the type that does like to dig into HA stuff to that extent. 
So from HE's perspective having basic driver isn't a waste of resources as it should provide a much better OOBE overall and reduce support requirements.
I do think that HE should at least include "...hey, this exists..." reference to HPM in their support docs & their SEO, so it is more easily discovered by those at actively looking for enhanced/extended app/driver options, but that's obviously their call until they finally give in and make me CEO (Chief Embarrassment Officer). 
7 Likes
Totally agree. Yet a very capable, proven solution (HPM) has been out there for a very long time now, but it's not discoverable without a lot of (IMO unnecessary) effort.
I understand that point of view. However, the vast majority of people on the planet know what an app store is (and those that don't most likely aren't going to buy an HE).
I just bought a Streamdeck and they have an app store. The more obscure Soomfon Streamdeck clone I have has a store. Visual Studio Code has an app store. There are probably dozens of examples of small to mid sized products that have app stores. The concept of an app store may have been obscure 20 years ago, but not today.
I would argue that the lack of an HE app store feels like an epic fail to many customers. A built-in app store would eliminate the difference between "built-in" and third party apps by providing a single search facility. HE can still provide it's own drivers/apps, as all the other vendors do in their unified stores.
Look at all the confusion (and technical issues) created by adding Webcore as a built-in app. What did that accomplish? Put the effort into platform-related things that enable us developers to produce even better apps and drivers.
I'll stop ranting now 
2 Likes
I agree with lots of that. I find the driver situation to be not that satisfying as a user, but manageable as a long time user. And I think it adds complexity that Hubitat then has to manage.
I'm not a fan of "basic" drivers as they by definition leave something out. Perhaps the best example is Hue. For a long time, years, the built in integration was basic. There were 2 more complete integrations. The basic became inadequate long ago with any Hue complexity. Hubitat finally fixed the issue by more or less making CoCoHue the built-in driver.
The situation makes it hard for new users & sometime experienced users to know what to do. A couple more examples: 1) Third Reality plugs have configurable power recovery settings. The built in driver does not. So users are forced to find and use a community driver from a developer that isn't using Hubitat any more. (To its credit Third Reality marketing material notes that Hubitat doesn't support the feature.) 2) The Zooz drivers. Everyone relies on 1 non-employee to make the devices work as expected, with often more capabilities than the Hubitat "basic" drivers. Not to mention support of those drivers.
If it were my company I'd put in regular reviews of built-in device drivers. Identify & prioritize improvements/feature additions. I'd also develop an official developer program and invite the more professional devs to be part of it. I'd develop some sort of "Hubitat seal of approval" for the drivers developed by those devs. Maybe kind of similar to Home Assistant where vetted projects get to be part of the core platform where they now have different certification/quality ranks. The non-officially sanctioned drivers get added via the HACS (similar to HPM).
Finally, one more from the peanut gallery, one of my higher interest drivers to be taken into "official" land would be ESPHome. There are some cool projects out there. The community driver doesn't support encryption due to platform limitations I believe. And the developer doesn't use Hubitat anymore.
2 Likes
