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

NOTE: This is not officially kicked off, but rather in the exploratory phase. Thank you @jerryacrocker for your initial question regarding the choice of ZigBee over Thread. It lead me down a crazy rabbit-hole regarding Thread and BLE.

Hardware/Firmware sections are a copy/paste from our Blue Series and are placeholders for now – I haven’t done research as to what is supported or not supported with Thread yet.

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!

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


  • 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 reach a new market. While we have already been developing a ZigBee line that will eventually turn into Matter, we were approached with the question of why we went ZigBee instead of Thread.

This led me down a rabbit-hole of trying to figure out what Thread was and why it was relevant. I knew it was what Google Home Hubs had built in (and I think Nest smoke detectors), but come to find out it’s what Apple is now using for some of their new HomeKit products (ie: the new HomePod).

In talking with our ZigBee manufacturer, they mentioned that the current ZigBee chip could also be used for Thread, so really the only change that needs to be made is a firmware one. Seems like a no-brainer to release both versions so that the ZigBee version can reach Amazon, Philips and current hub users (SmartThings, Hubitat, etc), whereas the Thread version can reach Google and Apple users.

We’re excited to start this journey and offer another option for people who are looking for an Apple or Google compatible product.

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.

Jonagold - Hardware Requirements
We will be using our current dimmer switch hardware with a few modifications. If you’re really interested in seeing what’s under the tent and how we kick off these projects, here’s the internal PRD (Project Request Document) that we presented (COMING SOON).


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.
    • 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: use the latest Thread chipset (should be the same one that will be used for Matter and compatible with Apple HomeKit and Google Nest)
  • 3-Way / 4-Way Ready: should work in multiple different settings in a 3 & 4 Way setting
    • 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
  • Thread Distance Estimator: should be able to estimate the signal strength of the Thread signal and notify via the LED bar
  • Instant On: when tapped 1x (and scenes aren’t used), switch should turn the bulb on instantly (no delay)
    • Configurable delay in 100ms increments (see tech doc)
  • CFL & LED Compatibility: minimum buzz and flickering
  • 600W: increase the wattage to 600 like GE’s
  • 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.
  • 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.
  • Auto-Detect Neutral/Non-Neutral: Switch should detect whether or not it’s connected to a neutral wire or not

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: 15 scenes (if possible – not sure if Thread supports this yet)
    • 14 Scenes via Tapping the Paddle up or down and holding/releasing
    • 1 Scenes via Tapping the Config Button
  • Aux switch compatibility: Should work with aux switches when scene control is triggered
  • Notifications via RGB Bars: RGBW Bars should be able to change colors based on events set up by customer (ie: if window sensor is opened, RGBW bar changes to red)
    • User can choose to sync the bars or have them show separate notifications
  • 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: Wink)
  • Internal Relay Disable: internal relay should be able to be disabled locally and via ZigBee
  • 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 switch should be able to be associated to other Thread devices
  • Smart Bulb Mode: mimic our Red Series smart bulb implementation but for Thread

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: Not Started
  • R&D Analyzation: Not Started
  • Initial Timeline Released: Not Started

Timeline (Estimated)

The initial timeline will be shown below and will be updated bi-weekly (if needed).

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


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?

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

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.

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

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.


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

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

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


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

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.


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

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

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:


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

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.


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.

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

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.

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.