ZigBee Fan Switch | Project Zephyr (Blue Series)

So Hot Right Now Projects & Roadmaps
,
1

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

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 (MG24)
  • 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
  • Power Monitoring - switch should measure the power consumption (not possible as there is no space on the PCB)
  • 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.
      • UPDATE 10/16/23 – neutral wire is not required. We were able to put it in there. Only limitation is that you will not have high speed (only low and medium)
  • 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.
  • Work with DC Fans

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.

  • Final confirmation of the structure - 2021/8/20
  • Final confirmation of the structure - 2021/8/20 - COMPLETED
  • Plastic structure tooling cycle - 2021/10/25~2021/10/30 - IN PROGRESS
  • Metal structure tooling cycle - 2021/10/26~2021/11/20 - IN PROGRESS
  • Hardware design and proofing - 2921/11/18~2021/12/12 - NOT STARTED
  • Hardware debugging - 2021/12/13~2021/12/15 - NOT STARTED
  • Program development & testing - 2021/12/16~2022/1/16 - NOT STARTED
  • 25 Sample Assembly - 2022/1/17~2022/1/22 - NOT STARTED

NOTE: This project had started, then was put on hold, then was picked back up in mid-2022. We apologize for the lack of keeping this part updated. I’ve crossed out all the initial timelines and updated them below.

  • Final confirmation of the structure
    • Estimated Completion Date: N/A (using Zigbee 2-1 structure)
    • Status: COMPLETED
  • Plastic structure tooling cycle
    • Estimated Completion Date: N/A (using Zigbee 2-1 tooling)
    • Status: COMPLETED
  • Metal structure tooling cycle
    • Estimated Completion Date: N/A (using Zigbee 2-1 tooling)
    • Status: COMPLETED
  • PCBA prototype production
    • Estimated Completion Date: May 21, 2022
    • Status: COMPLETED
  • Prototype production and testing (3D printing structure)
    • Estimated Completion Date: June 1, 2022
    • Status: COMPLETED
  • Switch and gateway compatibility test
    • Estimated Completion Date: November 30, 2022
    • Status: COMPLETED
  • Program development and testing
    • Estimated Completion Date: November 30, 2022
    • Status: COMPLETED
  • Product certification Zigbee/FCC
    • Estimated Completion Date: February 28, 2023 June 30, 2023
    • Status: IN PROGRESS
  • Product certification ETL
    • Estimated Completion Date: February 28, 2023 July 1, 2023
    • Status: IN PROGRESS

Beta Testing will begin likely in mid-July 2022.

Production is anticipated to begin in April / May 2023 July / August 2023.

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

Bi-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!

August 5th, 2021: Tooling is approved and deposit is made. The updated pics will be shared before the end of next week. We had an internal discussion earlier on how the switch will handle in a multi switch setup. We haven’t made a final decision but we’re leaning towards the switch only working with an aux switch in a 3 way setting. It will not work a dumb switch. If you have a dumb switch, we recommend using an On/Off Switch. Further explanation can be found here.

August 19th, 2021: Discussed with our manufacturer about the switch being a 7 speed switch but that would require another capacitor. Unfortunately because of this limit, the Fan Switch will be handle 3 speeds: low, medium, and high.

Matter - while its delay is disappointing our chip is still on schedule for a Q4 release, we are still moving ahead with Zigbee. Eric wrote about more on our strategy with Matter in the Project New Horizons thread.

We received the 3D rendering file for the switch. Check it out!

September 2nd, 2021: Everything is still on track for a Q4 release. We discussed how we can expect these switches will update to Matter. However, due to design constraints of the switch, it may be difficult for users to access the port. We have asked the manufacturer to look for alternative solutions for the design and or a harness so that we could update the switch to Matter in-house for customers if need be.

September 16th, 2021: Nothing major this week as our contact is out of the office. We discussed a little about fan specifications in the US but otherwise the project is still on track.

September 30th, 2021: Talked about timelines and more advanced testing with Hubitat. Nothing too major but we’re still on track for Q4. Link to comment.

October 14th, 2021: Still on track but this time around we ran into a small snag. Unfortunately the switch is having issues supporting an aux switch in a non-neutral setting. Due to current hardware limitations, we agreed to test the switch without power metering included. Hopefully by removing this the switch will seamlessly work in non-neutral setups with an aux. This isn’t out of the ordinary for us as our Dimmers & On/Offs don’t have metering in a non-neutral setting - still it’s a bummer to hear. We’re open to hearing others thoughts on this trade-off too.

October 28th, 2021: Received the bad news that there would be a 5 week delay from our manufacturer. This is due to general supply chain issues and a lack of parts. Expected release is Q1 2022.

November 11th, 2021: It’s been ten years since Skyrim was released, maybe we’ll figure out a way to re-release it on our switches? Kidding. Nothing too major this time around. We’re expected to have working samples for beta testers towards the end of January/early February but TBD :slight_smile:

–

January 3, 2023: Goodness, I didn’t realize this thread was not updated and thought for a minute we were ahead of schedule when I read, “samples for our beta testers at the end of Jan/early Feb” but then saw the year was 2021. Well, it’s 2023 now… this did not age well. Anyway, I’ve taken back the project and we’ve made a ton of progress. Long story short, we’ve finished beta testing on the MG21 module, but have just confirmed we will be using the MG24 (which allows for OTA updates – much better). So, we need to take a little bit to test the firmware on the MG24 (should be very similar). Estimated production is in April / May 2023.

January 12, 2023: No real updates here other than we discussed the timeline to switch between the already tested MG21 to the MG24 and how we can speed it up. As of right now, we’re still on track for April / May 2023.

March 30, 2023: We should be receiving new beta samples of the MG24 the second week of April (7-10). I should have a better idea of where we’re at from a timeline perspective once we receive them. I’m thinking this is probably more of a May / June release now, but I will give an update once we receive them and have analyzed them.

May 4, 2023: We’ve received the MG24 switches and are currently testing them. So far, so good!

May 26, 2023: Received a slight setback which will delay the release in that the manufacturer had to resubmit things to ETL due to the chip switch and they forgot to :unamused: - the latest estimate for production is late July to be finished August 3rd. The good news is that the MG24 firmware is wrapping up and we’ll receive our final release early next week.

July 27, 2023: Update provided here: ZigBee Fan Switch | Project Zephyr (Blue Series) - #338 by Eric_Inovelli - Projects & Roadmaps - Inovelli Community

August 15, 2023: Just got word from the manufacturer that all certifications are completed (ETL, FCC/IC, CSA/Zigbee) and they have a manufacturing facility audit scheduled for August 20th for ETL to come ensure the production run is setup correctly and follows its standards. There is a tentative production run scheduled for August 24th pending the audit passes (they are not worried). Production will last about 2 weeks give or take a few days. From there, it takes about a month to get to our HQ in Michigan. So, right now, we’re looking at a late September, early October delivery to your house. I sent out an email and will continue to send them out bi-weekly until they are delivered to everyone. We’re in the home stretch and thanks everyone for your patience!

August 29, 2023: Production has started and it is anticipated to be completed the second week of September. I’m excited to get this completed and in your hands (including mine bc I’m using all beta units before the MG24 chip was introduced lol).

September 15, 2023: Production has finished and the manufacturer will be releasing these early next week. From there it’s about a 3 week process to get to our Headquarters, but a lot relies heavily on Customs and what happens at the port. I will update if there are any issues. Right now, we’re targeting a mid-October pre-order fulfillment.

9 Likes
2

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:

1 Like
3

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

1 Like
4

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

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

3 Likes
5

lol. keeping you honest.

2 Likes
6

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.

7

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?

1 Like
8

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
9

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

10

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
11

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

12

Have you tried this existing configurable option?..

image

1 Like
13

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
14

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

15

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.

1 Like
16

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.

1 Like
17

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.

18

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

19

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.

20

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.

3 Likes