ZigBee/Matter Fan Switch | Project Zephyr (Blue Series)

Project Team
Feel free to tag any of us with questions. Donovan & 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!

Note: This is Donovan’s first project and he’s stepped up to help and is eager to learn, so be nice!

PRD Presented to the Manufacturer: Project Zephyr (Fan) - PRD.pdf (1.0 MB)


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 round out our ZigBee/Matter portfolio and provide a dedicated fan switch. Currently, we’re developing a 2-1 Switch (On/Off & Dimmer) and an Aux Switch, so the fan switch should cover the bases for an initial ZigBee/Matter launch.

This is a huge project, and we’re excited to finally bring a fan switch to market. Building upon the 5+ years of technology and 3+ years of community ideas and backing, we really believe this switch will be the example of what a smart fan switch should be. Together with your help, we’ll continue to put the best products in market.

Project Name - Zephyr

“Zephyr” is not just an awesome RHCP song, but it also means, “a soft gentle breeze”, which sounds amazing on a hot, summer day. And also, “Windy City” was already taken by our Z-Wave switch, so we had to think of something else :slight_smile:


Zephyr - Hardware Requirements
Here are the initial hardware asks we came up with. Pretty decent start!

Hardware

Blue Series Fan Switch

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 the fan speed
    • 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.
  • Air Gap: UL requirement
  • No heat-sink tabs: remove heat sink tabs for easier installation (note: may have to sacrifice max wattage/amperage)

Hardware - Features & Capabilities

  • ZigBee 3.0 - use the latest ZigBee chipset (should be the same one that will be used for Matter and compatible with Philips Hue + Amazon Echo Plus)
  • 3-Way / 4-Way Ready – switch should auto-detect
    • 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 Z-Wave signal and notify via the LED bar (see Appendix - Section C)
  • Instant On - when tapped 1x (and scenes aren’t used), switch should turn the fan on instantly (no delay)
    • Configurable delay in 100ms increments (see tech doc)
      * CFL & LED Compatibility - minimum buzz and flickering (whoops, copy/paste error)
  • 2.5A – Match GE’s specifications for fan load
  • 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.
      • UPDATE 06/21/21 – we will likely have to start out with a neutral only version of this switch. We are still discussing if this is possible, but early discussions have this being neutral required.
  • 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.

Zephyr - Software Requirements
Below is what we came up with for the software requirements. Welcome to the next level!

  • ZigBee Scene Control (if there is one – would be nice to be able to set scenes directly with Hue)
  • RGBW Bar Config - bar should be able to change colors and dimmed to the customer’s favorite level
  • 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)
  • Local Protection Mode (aka: Internal Relay Disable) - internal relay should be able to be disabled locally and via ZigBee
  • Minimum fan level / Maximum fan level
  • Ramp rate configuration - ability to change how fast/slow fan turns on
  • Ramp rate & instant on/off separated
  • Default Fan Level - ability to set the default fan level
  • OTA Ready - ability to update firmware via OTA
  • Associations? Can ZigBee switches be associated (are Hue remotes associated with their bulbs?)
  • Smart Bulb Mode from our Z-Wave Switches – maybe a smart fan mode?
  • Pair in different security levels?

Timeline
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
  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 06/15
  • R&D Analyzation: Completed 07/14
  • Initial Timeline Released: Completed 07/14

Timeline (Estimated)

NOTE: A more comprehensive timeline will be released as we move through the process. This is the initial timeline.

  • August 15 - Complete the confirmation of preliminary schematics
  • September 15 - Complete hardware DEMO test
  • October 15 - Provide functional samples for testing
  • November 15 - Complete the gateway compatibility and interaction test
  • End of December - Complete product certifications
  • Delivery in Q1 2022

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

Software

Step Current State New State
1 Press and hold switch up Press and hold switch up
2 700ms pause Scene command for button pressed is sent
3 Scene command for button held is sent 700ms pause
4 N/A Scene command for button held is sent

Weekly Recap
Every other Thursday morning, we have a meeting with our manufacturer to go over the various projects (status, issues, timeline, etc) and below we’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 anyone from the project management team above and we’ll be happy to answer. The bi-weekly cadence for updates will be Thursday afternoons.

July 21, 2022: Updated the project status, received pricing and officially kicked it off with the manufacturer.

July 22, 2022: Exploring options for a non-neutral switch. Expect a poll going up in the coming days!

2 Likes

Any chance windy city will resume development once this comes out? :grimacing: I’m trying to stay away from zigbee/matter due to 2.4GHz spectrum interference.

Edit: Saw your post on the windy city thread. YAY! :partying_face:

Is this a fan-only switch, or a combination fan/light??? :confused:

Dangit… I always miss something when I copy/paste lol.

It’s a fan only switch. I’ll delete that part :slight_smile:

2 Likes

lol. keeping you honest.

1 Like

Since we’re here, can all of the future products either default to or have a configurable option to physically act-on and/or send an instant “on” command even if the switch has the delay for scene commands enabled? The perceived responsiveness of the system would be dramatically improved (especially for lights) if ON happened right away followed by dimming, etc as normal. I like 700ms before a held/dim action is performed, but hate that a simple click up/down also has a 700ms delay in it.

I think I’m tracking, but just so I’m clear – are you saying that regardless of if the switch is set for, “instant on” or 100-900ms, the signal sent to the hub (or associated devices) should always be instant?

Here’s an example of what current state and new state would look like unless I’m misinterpreting what I see, and I think similar/same behavior occurs in the switch-local control as well.

Current state:
Press and hold switch up
700ms pause
Scene command for button held is sent

New state:
Press and hold switch up
Scene command for button pressed is sent
700ms pause
Scene command for button held is sent

2 Likes

Ok, that makes sense – tagging @EricM_Inovelli for visibility as we’ll want to implement this on our other switches.

The problem with that is it doesn’t allow button held events without first sending a button pressed. I’m not sure if that violates any zwave rules because currently button held events happen without being preceded by a button press. They are supposed to be independent actions and it likely would break a bunch of existing automations where button press and button held events trigger opposite actions

1 Like

I’d gladly take is as a configurable option. It’d really increase the guest acceptance level to get a more immediate response.

Have you tried this existing configurable option?..

image

I feel like sending a button press event immediately would mess up most scenarios where long press is used.

I would think the most common use of long press (up or down) is to control dimming, in which case - if you’re trying to dim a dark room up to 20% you’ll get greeted with a immediate blast of 100% brightness followed by needing to write a really complex automation to handle the dimming. I say complex automation, because you are no longer grabbing the current brightness level and slowly ramping it up, you now need decide if the current brightness level was the result of a single press immediately followed by a long press. But once you’ve determined that, you can’t simply bring the light back to 0% brightness and start fading up, you need to know what the brightness was before (eg. If it was at brightness 10% and you long pressed to bring it to 30%, it would be a poor user experience for that automation to begin by first taking the room down to brightness 0%).

I think the best way to handle this is how button presses are handled in most software; leveraging the on release action. On release can be acted on immediately because at the time it’s triggered, you already know if the intended action was a long press or short press.

1 Like

Agreed. From a firmware perspective, that is the correct way to handle button presses. Not sure why the Inovelli’s don’t seem to do that.

Pressing a button should fire off this routine:

START timer with TimeOut = button_press_delay
WAIT UNTIL button_released OR timer expires
IF timer < button_press_delay THEN  /*button was released before button_press_delay*/
     trigger button pressed event
ELSE                                /*button still pressed after button_press_delay*/
     trigger button held event
     WAIT UNTIL button release
     trigger button released event
END-IF

This logic will allow short clicks to fire off button_pressed events as soon as the button is released yet still be able to detect longer button_held and button_released events after the button_press_delay

It’s been a little while, bit I recall parameter 51 disabling held and multi-tap scene commands. I’ll try to experiment with it again this weekend. It is the very first parameter I enable on my black switches.

I do like the logic you and @kendrosg propose. It would resolve the majority of the issues I see and complaints I get. Most of the time it’s not the delay in initial brightness during a hold/dimming action, but a delay from a single tap action.

My understanding is that’s how it works now, right? I’ll be honest, I don’t often get as far into the weeds as maybe I should on a lot of the intricacies of the firmware, but I swore we made it to when the button is released it sends a command.

Tagging @EricM_Inovelli as he’s the real MVP behind the firmware.

All the evidence points to that not being the case. :frowning:

Its hard for any of us to say for certain without being able to see the source code (which I know the manufacture keeps hidden from you). BUT… its fairly easy to test by setting the button_press_delay to the maximum 900ms, then quickly click a button. (quick press/release click)

I’ve tested this quite a bit and can see that it waits almost a full second (~900ms) before it sends a command - even though the button was released within about 100-200ms. This tells me that it is waiting for the timer to expire and not immediately acting on button release. IF it was acting on button release (before timer expires) then we wouldn’t have had all those discussions and enhancements regarding the original 700ms fixed delay

To be clear, if the button is HELD longer than the button_delay, then a button_held event gets sent and after then when the button is released a button_released event is sent. BUT if the physical button is released BEFORE the button_delay then it does not immediately send a button_pressed. Instead it waits for the button_delay and then sends the button_pressed event.

Ahhh, I see – ok, so we’re saying there’s still a delay after the button is released?

I missed this part (sorry) and just read it as there was no command being sent after the button was released.

Ok, this makes sense – @fatherdoctor & @kendrosg is this what you’re talking about?

Sorry, my comprehension skills are not there today lol

Yes, if the release happens before the button_delay_time expires, it still waits for the timer to expire even though the button was released. AFTER the button_delay elapses, then it sends button_pressed or button_held depending on whether the button is still pushed or not. Either way it waits for the timeout before ANY events are sent.

This is the problem why a simple click ‘on’ has delay and why we pushed for the adjustable delay parameter which was, frankly, a bit of a hack around the problem of not acting immediately on button release.

After thinking about this a bit, I realize now WHY Inovelli does it this way…

It NEEDS to wait for the timeout before sending a button_pressed event because it needs wait for a possible 2nd, 3rd, 4th, or 5th button ‘click’. That is how it will know to send a button_pressed (or button_held) event for Button1, Button2, Button3, Button4, or Button5.

This is necessary because Inovelli on/off switches and dimmers emulate multi-button controllers using multiple taps of the same button. Therefore it must wait after the first tap in order to see if there is a 2nd, 3rd, 4th, or 5th.

Sorry about the prior lengthy analysis. But now looking at all the data, it appears the current method is the best compromise that covers the most scenarios overall.

1 Like