It makes sense but… I do believe there are still ways around it and at least to me (a software engineer obsessed with quality) any noticeable delay is not acceptable but maybe … this is the ocd talking
Anyway… just look around, there are multi tap events implemented all over, starting with your computer. Imagine if you had to wait 700ms every time you double click to open something?
I know it is not a fair comparison but my point is: this is nothing software engineering hasn’t solved in the past in a gazilion different ways.
I iunderstand inovelli doesn’t own the source code but if we had at least some pseudo code to start with I’m sure we could figure something out that could later be presented to the manufacturer as a suggestion.
I agree …but… this is a bit different. When you double-click the mouse, TWO events get generated. The first click still triggers the “select_object” event and then the second click triggers the “open_object” event. In the case of the Inovelli switches, a double-click should NOT trigger two events. If there are two (or more) clicks, it must NOT trigger the event for the first click. I don’t think there are any actions with a PC mouse that have this same restriction.
The good news is we don’t have to wait the fixed 700ms anymore The new firmware allows us to set the delay in 100ms increments. I have mine set to 300ms which is still a delay but much better than 700ms. I tried 200ms but that was too quick for other people in the house. TBH a setting of 250 would be almost ideal for me but that is not an option at this time
I agree there is probably some way but I think the special conditions may make this more difficult than it first seems. I have provided psuedo-code on a few of my previous recommendations, but I have not been able to think up a good code stub for this. If you have some ideas and can provide some pseudo-code for this it would be great
I see what you are saying and that makes it tricky.
Impossible to acomplish without introducing some sort of the delay.
That is a huge improvement. The threshold will vary by person (as you mentioned) and having it configurable kind of solves it. Also being able to turn it off completelly is a must have for those cases where you don’t need button events.
It seems like Inovelli has done about the best they can for controlling the physical load by allowing this timeout to be configured (or disabled) for multi-tap detection. I believe there might still be an issue about how long you need to hold a button before the dimming action happens - I think everyone thought the configurable delay would apply here also, but it didn’t (@Eric_Inovelli - am I remembering this correctly? Did it get fixed already?)
However, it might be nice if the switch did sent some kind of ‘raw’ button pushed/released messages to the hub (as well as the current messages that reflect the actions applied to the load - SBM excepted). If the scenes are just for normal light on/off/dim functions, then they’d need to implement almost exactly the same timeout logic that the switch does - so not much point. But there might well be other use cases where the scene can react immediately to a push.
Will/can there be some sort of icon on the switch indicating that it is for the fan in the room? I know with the current fan/light combo switch some visitors have had trouble figuring it out(… yeah… I know it’s really not that difficult and has icons on it).
I think this is still an outstanding issue. @EricM_Inovelli is this correct?
I know it was requested and it took me way too long to understand what was being asked for though haha. I’m pretty sure we had to draw the line due to space on the Z-Wave chip as well as exhausting the firmware engineers who already think we’re crazy for all these small improvements. But, it’s definitely something that should be tweaked and Maycock can capture this in our GitHub for future enhancements.
I’ll definitely add this to our ZigBee/Matter line and any future Z-Wave 700 Series switches.
You all are way too smart for me. I have such a hard time understanding these things lol. I’d like to go back to coloring between the lines with my crayons please.
Interesting – we hadn’t thought about adding an icon, but I can see the draw, especially as there will be two identical looking switches next to each other.
Yeah, I can see how that would be helpful. We’ve looked into laser engraving before but the project was put on hold, thread here. Eric and I are gonna look back into it and give you guys an update.
@Eric_Inovelli I do have another delay logic related QOL improvement that shouldn’t run into the same limitations. If the config button is pressed, then the top paddle is pressed, the config button press should be ignored, then the normal logic for the top paddle should be processed. I’ve noticed that I have two light switches (in bathrooms) I’m batting about 500 on, because I hit the danged config button accidentally on my way through the doorway. Nothing like having to turn around and hit the on switch again when you have to pee.
Project Update: I just updated the project and good news, we’ve made the deposit on tooling and we should have 3D renders by the end of next week. As for how the switch works in a 3-Way setting, we went back and forth, but ultimately decided to accept the design of it only working with an aux switch. Here’s why:
It would add an extra $1-2 to the design
In most houses we’ve seen (including our own) the 3-Way scenarios are non-dedicated fan only setups. In other words, if there is a 3-Way setup, it’s typically a situation where the switch controls both the fan and light and this switch is designed for controlling the fan only.
In the rare case you have a fan only switch on one side and a fan only switch on the other side, we figured the user experience would be that you’d want to control the fan speed from both sides and if you keep a dumb switch, you’d only have on/off control
We figured it would be more beneficial to have non-neutral compatibility and paid the extra for that feature (still confirming this is possible, but early signs point to yes) vs the dumb switch compatibility in a 3-Way
@anon88759745@Eric_Inovelli any idea when you will start pre-orders? I would rather have the Z-Wave fan switch but this will work as a temp until the Red Series fan switch comes. I understand still kind of early but thought I would ask.
I see you have DC fans on your features list. I was under the impression that DC fans all use proprietary controls. Do you have an idea how DC control might work? Would it be tied to a specific brand of fans? (Modern Forms fans have separate RF controllers in the canopy that might be replaceable.)
We definitely want to have preorders up as soon as possible because it will help give us a better idea on demand for our first order (Plus I want to show my friends/family how cool these switches are). However, we don’t want to over-promise then under-deliver on the switch so there’s a few things we want to verify before opening up preorders:
Will these work properly with Hue?
Can these be OTA updated to Matter (it’s looking like the answer is no right now, which is not we were told originally from SiLabs)?
If they can’t be OTA’d, will Zigbee 3.0 work with Matter Hubs?
Are the key selling points verified (notifications, scenes, smart bulb mode, etc.)
We should have the answers during our beta testing, which will likely take place in a couple of months. A more firm date will be given once we receive the official timeline from our manufacturer.
We have this on our checklist as people were asking the same thing with the Fan & Light Switch but haven’t officially verified if this is possible yet with the manufacturer. I just put this question out in our Zephyr teams chat with the manufacturer and will see if it was added in their initial feedback to us.
Thinking about this a bit more…what is probably the most feasible solution if direct DC motor control is not not a possibility, is to mimic the smartbulb controller mode from the light switches.
This would require a DC fan that has built in “smarts,” which most of them do now. Then you could have the switch provide constant power to the fan, the paddle becomes a scene controller to talk to the hub, which then sends speed commands to the fans integrated controller.
This would work with my Modern Forms fans and most of the other DC Wi-fi enabled fans I am aware of (Haiku, Home Decorators collection from Home Depot)
Q: How many speed levels will the controller support? Similar to dimming (99 minus the dead space that tends to be at the bottom?) Or will it be like other smart fan speed controllers (Leviton’s zwave, Lutron’s Caseta or RadioRA2) that support only 3, 4 or 7 speeds other than off?
My votes for Zephyr in order of importance
Color paddle options. White is a non-starter for us.
Fan icon on paddle. Nice to have a visual difference for fans vs lights.
Native support with major hubs for control. Zigbee fan controllers don’t seem super common, so getting native support with ST, Hubitat, HomeSeer, etc ASAP makes a big difference in adoption.
The “new style” small/less raised config button. Saves me from sanding down the production ones.
We’re fine with simple 3 way options. We have exactly zero 3 way wired fans. Adding cost for fancier 3 way options doesn’t get our vote.
We don’t need any scene or multi tap support on a fan switch. We’d just be using it to control fan on/off/speed.
multi tap support is always a welcome feature. especially for us who don’t have available space for installing a separate switch.
nevertheless, to use it just as a regular fan switch without the scene control, it would be enough using one of the generic device handlers which don’t enable said feature.
