Thread 2-1 Switch (On/Off & Dimmer) | Project Jonagold (White Series)

So Hot Right Now Projects & Roadmaps
,
1

Pre-Orders are Open: Inovelli White Series 2-1 Smart Switch • Works With HomeKit • Matter

BLUE FRIDAY SALE: 10% Off this Pre-Order w/Code BLUEFRIDAY

NOTE: We’ve kicked this off with the manufacturer and have a tentative delivery date (unsure of how long Matter Certification will be) of mid-Q1 2024!

Project Team
Feel free to tag any of us with questions. Myself (Eric H) & 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!

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 give our Google Home, Apple HomeKit, Amazon Echo, and Philips Hue friends an opportunity to enjoy the Inovelli magic.

Over the course of a couple years, we’ve gotten requests almost weekly to come out with a Thread/Matter switch and I’ve had to turn it down due to resources, and lack of real understanding of Thread and even moreso Matter.

I had been thinking about this switch one day in August randomly and at the same time someone IM’d our chat bot and simply said, “Matter” and I thought, “oh boy, another person I have to turn down, this stinks”. But he and I had an awesome conversation which lead me to start researching again what all it would take to start this switch.

Then a couple days later @jvm33 started posting about Matter and he and I have had some incredible conversations with him also providing us a ton of knowledge around Thread/Matter and what it can do.

The final straw was when I started talking to the firmware engineer and I found out this was a passion project for him and he’s already gone through Matter training and actually has been messing around with our switches and HomeKit.

So, I’m excited to announce this journey into the Matter world and put my money where my mouth is!

Project Name - Jonagold

Jonagold is my favorite type of Apple that happens to be grown in Michigan. We thought it would be fitting to tip our hat at one of the companies we draw not only our marketing and product inspiration from, but hopefully can partner with in the future and, at the very least, provide compatible products to (Apple execs, if you’re reading this, I’m talking to you!).

Jonagold - Hardware Requirements
We will be using our current Blue Series 2-1’s hardware for this, but we will tweak the firmware.

Hardware

white series 2-1
white series 2-11000×646 320 KB

NOTE: Above is a terrible Photoshop rendering. I did my best.

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 (if Thread supports it).
    • Should be able to be held (for config)
    • Should be able to be tapped (for scene control)
  • RGB LED Bar: should measure the % of how much the switch is dimmed
    • 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)

Hardware - Features & Capabilities

  • Thread: We will use the MG24 chipset
  • 3-Way / 4-Way Ready: should work in multiple different settings in a 3 & 4 Way setting
    • Should work with our auxiliary switch
    • Should work with an existing dumb switch
    • Should work with another smart switch
  • Power Monitoring: switch should measure the power consumption
  • Instant On: when tapped 1x (and scenes aren’t used), switch should turn the bulb on instantly (no delay)
  • CFL & LED Compatibility: minimum buzz and flickering
  • 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) and if it can’t, then there should be a manual override.

Jonagold - Software Requirements
Below is what we came up with for the software requirements. A lot has been inspired from our Blue Series 2-1 switch!

  • Thread Scene Control: Multi-Taps (if possible – not sure if Thread supports this yet)
  • Notifications via RGB Bars: there will not be animated notifications, but we can try to get it so the LED bar can change colors based on events. I can’t promise this one, but I will try
  • RGB Bars Config: bar should be able to change colors and also dimmed to the customers 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/favorites 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: HomeKit, Google Home, Philips, etc)
  • Set Min/Max Level: minimum dim level / maximum dim level
  • Ramp Rate Configuration: ability to change how fast/slow light turns on
  • Ramp rate & instant on/off separated
  • Default Dim Level: ability to set the default dim level
  • OTA Ready: ability to update firmware via OTA
  • Associations we are researching this - there doesn’t appear to be anything similar to Z-Wave Associations or Zigbee Bindings as of right now
  • Smart Bulb Mode: mimic our Blue Series smart bulb implementation but for Thread

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 (see above section for the pdf)
  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.

The good news is it should be fairly quick as the hardware will be the same as our ZigBee switch, we will just be tweaking the firmware.

Pre-Initial Timeline Milestones:

  • Present PRD: Completed
  • R&D Analyzation: Completed
  • Initial Timeline Released: Completed

Timeline (Estimated)

The initial timeline will be shown below and will be updated monthly.

Develop Initial Firmware

  • Estimated Completion Date: Nov 26, 2023
  • Status: IN PROGRESS

Create Samples for Beta Testing

  • Estimated Completion Date: Nov 30, 2023
  • Status: IN PROGRESS

Round 1 Firmware Test

  • Estimated Completion Date: Dec 31, 2023
  • Status: NOT STARTED

Round 2 Firmware Test

  • Estimated Completion Date: Jan 11, 2024
  • Status: NOT STARTED

Round 3 Firmware Test

  • Estimated Completion Date: Dec 21, 2023
  • Status: NOT STARTED

Final Firmware Test

  • Estimated Completion Date: Dec 21, 2023
  • Status: NOT STARTED

Manual Creation

  • Estimated Completion Date: Dec 11, 2023
  • Status: IN PROGRESS

Box Design + Inserts & Wiring Guide, etc

  • Estimated Completion Date: Dec 11, 2023
  • Status: IN PROGRESS

Matter Certification

  • Estimated Completion Date: Jan 30, 2024
  • Status: NOT STARTED

FCC/IC Certification

  • Estimated Completion Date: Jan 30, 2024
  • Status: NOT STARTED

UL Certification

  • Estimated Completion Date: Jan 30, 2024
  • Status: NOT STARTED

Mass Production

  • Estimated Completion Date: Feb 15, 2024
  • Status: NOT STARTED

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).

Sept 2, 2023: we’ve kicked this project off with the manufacturer and an estimated delivery date is set for mid-Q1 2024.

Oct 28, 2023: Project schedule released

4 Likes
2

Is there any expectation or potential for this and the Zigbee 2-1 to be effectively interchangeable between Thread/Zigbee(Matter in the future) with a firmware update? Or it’s just that the hardware is basically the same, but once the base firmware is on, you should only expect updates along the same line for lack of a better term?

1 Like
3

Is this a third manufacturer? I thought the blue switch was already with a new manufacturer?

4

I had the same initial question, but I think since this is a copy/paste for the most part that that’s a carry-over from the Blue series. Since that had the similar - ‘manufacturer 1 is zwave, manufacturer 2 is zigbee’ new one more specialized. I wouldn’t expect swapping to a 3rd when the 2nd was the one that pointed out the chip would work for both.

5

You’re probably right. I usually find one or two copy/paste errors in the new project posts. @Eric_Inovelli :rofl:

6

That’s an excellent question. My understanding is that if you’d like to interchange between ZigBee and Thread, you certainly can as they share the same, “base” chip. In addition, both will be able to upgrade to Matter :slight_smile:

Lol, you are the master at finding copy/paste errors haha.

This will be the same manufacturer as our ZigBee line, I just suck at editing haha.

5 Likes
7

I love everything you guys do, from products to customer relations. Keep it up!

I’m far from an expert on anything smart home and fairly recently started my journey, but I’d like to help in anyway I can. Here are my initial thoughts.

  1. How many users are programming the switch without a hub? It seems like that ability takes up a lot of real estate on the chip, and I’ve only ever adjusted settings from my hub, but perhaps some hubs aren’t as capable?
  2. How many people use the auto off feature? Again I would think most people would use an automation on the hub if they wanted that ability. I know in the past you’ve mentioned there isn’t always space on the switches for new features. These are the features that feel least useful to me.
  3. How many people are using power monitoring? From my perspective there is very little need to monitor the power of my lights, the only thing I use power monitoring for is to tell if specific appliances/TVs, etc are on. None of these are connected to my switches.
  4. I’d love it if the LED bar would have less of a fade when it is showing the current value. A more clear line would make it easier to tell the current state of the switch at a glance
  5. I’d love it if there was an additional hole for neutral and ground wires on the back. This would allow ‘daisy chaining’, cutting down extra wire / marettes in the boxes with multiple switches. In the attached technical drawing: Black is hot, blue is neutral, green is ground. I had a four gang and five gang box and it was a real challenge to get everything to fit, even being a brand new build with large boxes. Something like this would have been a huge help.
    InovelliDiagram
  6. If I switch the LED bar to a color in an automation, then switch it back to white, it doesn’t go back to true white. On Hubitat that leaves a 40 in the Custom LED RGB Value, which makes the switch look yellow. Perhaps this is more of a Hubitat issue, but it’s a little annoying to not be able to set the LEDs to a color then back to white without going back and doing it manually
    image
    image856×161 5.43 KB
  7. If you set parameter 2 to 101 it will follow the value of parameter 1. Could we get something like that to link parameter 9 and 10 (default dimmer value)?
  8. I’ve mentioned this previously, but I think a PIR sensor in the switch would be really cool to see someday.
8

The red, black and blue series have two holes each for the hot and neutral to accommodate daisy chaining.

I believe the same is true for the ground, at least on the blue series. TBH, daisy chaining the ground is not a good practice.

1 Like
9

I’m using the power monitoring.

I do not set any of the config options via the switch. I can see neutral/non neutral, and 3 way configuration being useful for new construction projects where a hub may not be setup yet

4 Likes
10

Can you elaborate on why that’s bad practice before I burn my house down or hurt someone? :thinking:

I know they have two neutral holes, I’m saying a third neutral and hole would have been helpful, as in the diagram.

1 Like
11

So in a daisy chain, successive devices are connected downstream. The ground is present as a safety mechanism, so it’s important that all devices in a box be grounded. Let’s say you have a 4 gang box containing switches and there is an issue with the leftmost switch where the ground becomes disconnected or broken (like when you are tucking it in and don’t realize it).

If the grounds are all pigtailed and routed to each device from the bundle, then only that one switch becomes ungrounded. But if the grounds are daisy chained, and let’s say that “broken” ground is at the first switch in the chain, then EVERY switch in the box and whatever else is downstream becomes ungrounded.

So if everything is intact all the devices are grounded one way or the other and everything is good. It’s only if an issue arises with the ground that a bad situation can be made worse because of the grounding technique.

I doubt you are ever going to see more than two holes at a given position. Adding additional holes would require additiional screws at each location, as you cannot have move than one wire under a backing plate on each side of the screw.

3 Likes
12

Thanks, that really means a lot :slight_smile:

Excellent question – the Gen 2’s were initially designed when Wink was still really prevalent and there is no way to edit Parameters on that hub. In addition, we were in talks with Ring at the time and one of the major selling points to them was the ability to configure from the switch as they also did not have the capability to change parameters from the hub.

Fast forward a couple of years and yes, you’re exactly right, there doesn’t seem to be that much need to have local configuration as most people use a hub.

However, for ZigBee and Thread, there are now people who don’t have a hub who will for sure need local configuration. Examples would be Philips Hue and Amazon Echo users for ZigBee, and Apple and Google users for Thread. Certain parameters are extremely important for configuration and can really set us apart from the competition – such as min/max dim levels (there are so many LED bulbs out there, that I can imagine the competition not having this built in could lead to a ton of flickering bulb issues and a lot of frustration from the customers end).

Yeah I never understood this one tbh – but surprisingly we’ve gotten this request from quite a few people. But it would also be one of the first to go if we don’t have chip space (along with invert switch).

Ah yes, the great debate lol!

Me specifically, I don’t use power monitoring – however, many do, so it’s a nice to have. However, the main reason we put it in there (if I’m being very transparent) is because we hope that one day houses can become truly smart, instead of just reactionary.

What I mean by that is right now smart houses are programmed to work based on automations – but the automation is only as smart as the person programming it. What if there was artificial intelligence built in to the hub that could predict when the right time was to turn off lights based on the energy grid? Or could save you money based on when power costs less?

Google, Amazon, Apple, etc are all building their own AI and our stance is that the more datapoints our switch can give their AI, the better it will work.

Hope this makes sense?

Are you saying you’d prefer more hard lines on the LED bar that will give you a precise read-out of where the the dim level is?

In other words, right now the LED bar has a diffuser put in it to minimize the, “hard line” and give it more of a soft, blended look – a hard line would be very visible that 1/5 of the LED bar is full when at 20%.

Very interesting – I hadn’t thought about that!

I’ll defer to @Bry’s stance though that it probably would require an additional screw for each terminal as there can only be one wire per side of the screw (w/two sides max).

Very interesting – @EricM_Inovelli – have you seen this?

@EricM_Inovelli – something to consider!

Agree :slight_smile:

1 Like
13

For clarity here, do you have the original value for true white? I know they’re blue by default, so not sure what your starting point was. Also have you tried using the LED Color Child device instead? That may be a bit easier to either use setColor or setColorTemperature to get it exactly where you want in your automation. (can take this to another thread if need to dive deeper?)

1 Like
14

I use and automate based on both of these features. More energy intensive applications get auto-off faster based on time of day and energy rates. Don’t mess with this :smiley:

5 Likes
15

@Eric_Inovelli I appreciate you taking the time to respond. Like I said I’m quite green with all of this stuff and get that much of my feedback is likely not that meaningful when you have other power users. Sometimes it’s nice to have a ‘fresh’ perspective from someone who is looking at things from a different angle than the people who have been using this stuff for a few years.

Awesome. I’m looking forward to seeing this in action some day.

That is what I meant, yes. I like the diffused look from an aesthetic standpoint, but just found it didn’t feel that meaningful from a practical standpoint. That said, I’m not usually looking at the LED bar to see if it’s bright enough in the room, so this isn’t a game changer.

That makes sense. The boxes just get so crowded so quickly I thought every wire/marette I can avoid is appreciated.

16

image
image856×161 5.38 KB

Hey Chack, Custom LED RGB Value was blank. Then I set 13. Led Strip Color to White on all switches. If I used the LED Color Child Device to change the color the Custom LED RBG Value populated with a value, but 13 still read as white. When I used the child device to try to switch it back to white the RGB value turned to 40 which is a gross yellowish color. I just don’t adjust the color of the LED anymore but I was using it as a pseudo notification.

3 Likes
17

Oh yeah man, totally agree! I sincerely appreciate you taking the time out to write your thoughts. You’re absolutely right, the fresh perspectives are what keep us relevant and on top of the competition, so we really do love it.

Interesting – we had tossed around the idea of selling separate diffusers, so maybe we can put this back in play. The initial thought was that each LED could be individually addressable and notifications would then be able to be shown in separate 1/5th’s (I’m wording this poorly lol). In other words, LED #1 (bottom) could light up blue, while LED #2 could pulse green, etc, showing 5 different notifications at once.

Let me toss this around again to see if we can pull it off. To be honest, it slipped my brain when writing the PRD that this was a request.

1 Like
18

So if I understand correctly, regardless of if you did it through the parent device (13. LED Strip Color) or the LED Color Child Device, both always ended up with that 40 yellowish color when you tried to change it to white?

This would be very cool, particularly with individually addressable LEDs.

1 Like
19

That’s a really fun idea, though I’m having a hard enough time remembering what each notification is already :upside_down_face:.

While we are on the topic of notifications, I had thought, what if I want to notify the garage door is open (red, for example) and my wife’s straightener is on at the same time (green). Would it be a workable solution to have the notifications alternate? Notification 1 shows for 3 seconds, then Notification 2 shows for 3 seconds, then back to Notification 1, etc.? Though if you had the individually addressable LED’s this wouldn’t be necessary.

20

Until I go in and manually clear the RGB value in the parent device the hue value stays there and overrides the 13. LED Color.