You do that by just wiping out the RGB piece and hitting save preferences? Then the parameter 13 white value works or that ends up the same yellowish color until you clear it also?
To my knowledge, there’s no way of doing this today. Like you said, the individually addressable LED’s would solve it since you could just choose different LED’s to use. Alternatively, if you have multiple switches in the same box, you could use the garage door notification on switch 1, and wife’s straightener on switch 2…but that’s going to be very dependent on the specific setup you’ve got and where you are when you want to see these notifications, etc.
Correct. When I wipe out the RGB piece and save it shows the true white color.
I understand they can’t do this currently, but thought if the addressable LEDs was not possible, maybe with some firmware adjustments a switch could cycle through any notifications that were ‘on’.
Are you using a black series or red series device? If you are using a red series, you might want to use a “solid” notification as it seems to accomplish what you are looking for. I have also fixed the issue on the LZW31-SN driver though, if you want to test it. I still need to add it to the other drivers and will do that soon.
Agreed. I have been using auto-off in particular more and more to simplify automations. With Zwave it’s also very handy with direct associations and no hub involvement.
Is there an ELI5 for the differences between Zigbee / Matter / Thread? From what I’ve seen, Thread is the successor to Zigbee? I want to get a couple of these 2-1s to help control Hues faster but I don’t want Zigbees if Thread will be better and also compatible. Is the whole future of smart home in flux at the moment or something because of these unknowns?
In order to explain the differences between Zigbee, Thread, and Matter, we will have to break up Zigbee into two parts. Part one of Zigbee is the actual wireless protocol itself. This part is the part of Zigbee spec where they chips send signals to each other to talk and form the mesh network. Basically the “How Zigbee devices talk to each other” Part two is the application layer. This is the part where they standardize what commands do what things. This is the “What do Zigbee devices say to each other.” All Zigbee devices that report battery life should all be reporting it the same way, and thats what part two takes care of.
Normally this isn’t really brought up, because the Zigbee spec includes both and you have to use both to be a Zigbee device. (Side note, same it true for Zwave)
Now when we are talking about Thread, we are talking about “How do thread devices talk to each other” like the part 1 of Zigbee. Thread will create a mesh network of devices thats actually very similar to Zigbee, but Thread is compatible with the TCP/IPv6 stack used by, well the entire internet really. But that is all thread does. There is no “what to say” part of thread, it it only how devices talk to each other. Thread is just another way to connect to a network, like wifi or an ethernet cable. You could in theory have a gaming console that connects to the internet over thread instead of wifi, because they both talk to the internet and other devices using IP. (Thats probably not a good idea, thread is built for low power low bandwidth when gaming you could want high power and high bandwidth like wifi, but it works in theory)
Matter on the other hand is like part 2 of Zigbee. It is the “what to say” with the goal of bringing all devices to the same standard. Like generic instructions, any Matter compatible smart bulb should report its battery the same way and respond to the same power on/off/brightness commands. That way it doesn’t matter what hub you use, they all know “what to say” to control the bulbs. Matter operates over IP, so any device with an IP stack (again, the entire internet really) can use it.
Thread and Matter will likely be used together a lot in the future, because thread allows a low power and reliable way to access the network and Matter allows them to standardize allows people to know that the device they bought will work with their Echo or Google Home or whatever. The two don’t have to be used together though. The Nanoleaf light products use thread right now, but they talk to the Homepod using the Homekit protocol rather than Matter.
As for what to buy, if your goal is to control a Hue bulb with a smart switch, go with a Blue series Zigbee switch. I don’t believe Hue plans to update their existing bulbs directly to thread anytime soon.
As for this white switch, Im going to assume that it would be using both thread and matter? @Eric_Inovelli
TD:DR ELI5.
Thread is how you are taking to someone. Over the phone, in person, email, sms etc.
Matter is what language you are talking in, English, Spanish, German, Esperanto etc.
Zigbee/Zwave are both.
Your tried questions, i very much like and use power monitoring. It the only way I have to know if some devices are on so i can do automations. Like my DC ceiling fans with integrated lights that are rf remoted controlled. With power monitoring, i know when the light on, and what speed the fans is.
It has been a month since this thread… Hum, the Thread thread. At this point is this just a firmware project, or is there hardware difference from the Zigbee switch?
Hi, Hope you can find time to update progress. I am sure you are dealing with supply chain hell for your other lines, but hope this is still in forward mode.
One point if not already considered, the switches should be thread routers and not just thread end points, so that they propagate and deepen the thread mesh. I hope they are as they are wired, but did not see in the specifications. (This is separate from thread border router - which is what HomePod/AppleTV/Ipad are). Hope this can be clarified.
I will probably need a 80-100 of the white switches (incl aux switches) for a whole house project and look forward to the launch! Congrats on the products thus far.
The initial hope was to upgrade the blue series 2-1 to Matter. This will require a special cable vs OTA updated. @Eric_Inovelli is recommending waiting until the blue series is upgraded to the MG24 or the Jonagold is released.
Just guessing but with apple already building in Matter support with ios 16 and Matter having a lot of homekit underpinnings in regards to local control and security coupled with the supply chain issues not being alleviated quickly, I would suspect Inovelli never waste time with a homekit specific release and goes straight to thread/Matter instead of thread/homekit with the move to MG24.
would agree with @ppsf though any always-on thread-enabled switch should be a thread router and not a thread endpoint. With what I have gathered from inovelli I can’t imagine they would overlook that opportunity.
Just had a look at the specs for MG24 that stu1811 mentioned and that Eric referenced.
It certainly has Tx and Rx with decent power levels, hence definitely will be router assuming firmware allows it. Also if you see the protocol support, its both thread and BLE, here meets Apple HomeKit requirements for Thread+BLE for commissioning.
So happy days ahead.
I would vote for HomeKit with thread certification and then let matter follow as the HomeKit market with the apple ecosystem is likely more premium that any other market that meets the Innovelli brand and pricing well. Further
HomeKit scene control gives excellent options in a very user friendly UX and hopefully there is a way to access all the good features of the switch through HomeKit.
Thread/Matter should give inovelli the same first-party access to homekit and scenes that thread/homekit will and have the added benefit of working with all other ecosystems. Time will tell. With all the inevitable supply-side delays before the next updated iteration of the switch is a purchasable product the next steps and focus will hopefully be more clear.
I’ll pop in real quick – sorry, this week has been insane and I haven’t really been available to answer community threads. Hopefully next week I can get caught up!
Yeah it’s been a real fun time over here lol. Luckily, it’s getting all sorted out, slowly, but still moving forward. I plan to make an announcement shortly once the various deals behind the scenes are settled (investor, B2B, partnership, etc – a lot happening!)
Awesome, I will keep this in mind – I’m wondering if it is similar to Zigbee in that we’ve specified it to be a router as well. Considering it shares the same chip, I think we should be good, but I’ll for sure pass it on to the team.
–
As for the update – the brief version is that we have given the PRD (Project Request Doc) to the manufacturer for review and they think it will be an easy project. That’s the good news.
The “bad” news is that there’s a new COO (to be announced) who we’ve brought on that has a ton of experience with IoT as well as relationships in the industry and he’s basically wanting to go through these different opportunities and figure out which ones make the most sense.
If I’m being honest, one of my issues personally has always been getting too excited about things and trying to bite off more than I can chew. I know deep down these opportunities will sell and that has actually been the problem all along… our stuff sells too well. This is a problem bc we can’t keep up with demand and things go out of stock. Couple that with growing lead times (they’re luckily getting better – but they were insane in 2021) and we just simply don’t have the cash to purchase 52 weeks of inventory and are stuck in this, “what do we do?” scenario where we have to prioritize SKU’s and discontinue others (even if they’re selling well).
His job is to balance us out, really look into the ROI’s on projects and figure out financing for these opportunities. The good news is he’s a low hanging fruit kind of guy and this project would definitely be low-hanging as the switch is already developed.
–
A separate issue we’re having is really trying to break through to Apple to understand what their plans are for Thread/Matter. It took me talking to 5 different people for them to tell me anything and even that information was so basic, it really didn’t help me understand the full picture (it was simply letting me know that Bluetooth is required along with Thread). They won’t disclose anything around Matter which makes me nervous. If we spend all this time/money getting HomeKit certified, and they switch over to Matter, what does that mean for us?
Thanks, exactly right. I wish I had more insight, but everyone is pretty tight lipped
Dang, I should’ve just read the entire thread before typing out my response above lol – you said it way better than I did!
Question for you (and everyone else) – do non-HK certified devices work on HK? My guess is no, but figured I’d ask. If they do, I could definitely see the business case of coming out with a Thread Certified device and use the community and/or other unofficial avenues outside of us to promote the switches working in HomeKit, while we work on ensuring certification with HK, be it Matter or Thread.
My fear is that we waste time/money in HK Certification only for them to change the certification later when Matter is released and who knows if they’ll support prior certified versions. I’ve seen big companies do some real shady stuff (not saying Apple will, just in general, we’ve been burned before) and bc we’re a small company, customers turn on us bc they think it must be something wrong with the switch.
Curious here as well (I really just need to buy a HK device haha) – I’m guessing HK is similar to Alexa/GH in that it supports basic features (on/off/dim) but any of the advanced features would be done via some other hub and bridged over. Are there a lot of advanced firmware products out there that tie into HK?
I have Red Series devices on HomeKit thanks to HomeBridge, which is easily do-able on Hubitat, Home Assistant, probably still SmartThings (haven’t tried in a while…), and likely other platforms. So, yes, but unofficially. There is an in-app warning that the device isn’t certified and may not work correctly, and this particular setup requires a HomeBridge server. I’m not sure if there are any devices that work as-is (e.g., directly over Bluetooth or whatnot) without official certification, but that would likely be more difficult, even if not impossible. That part I’m not sure of.
But for enthusiasts, it’s certainly already possible! (I’m not even a HomeKit enthusiast; it’s mostly for the rare Siri voice control moment. Hubitat does all of the real lifting for me, and HomeKit is just an extra … one with an awkward UI and limited automation options IMHO, but I digress…)
Can’t wait for the release of the very capable Blue series, and eventually this new one that hopefully supports HomeKit, Thread & Matter out of the box!
I pre-ordered a few Blue series dimmers to control lights for a renovation project, and can’t wait to test them out. I have a couple of questions, after seeing that this design was directly based on the upcoming Blue series with the SILabs ZigBee MG21 chip, and I assume most likely this one will use the newer MG24 with OTA firmware update capability.
For the Blue series ZigBee dimmer switches, I understand that the firmware will be only upgradable via some hard-wired pin(s). Q: Will this be possible for the more tech-savvy switch owners via JTAG, or some other kind of flashing device?
My reasons for asking:
I’d like to approach future-proofing my home by upgrading to devices supporting Thread + Matter.
From what I understand, this may depend on having Bluetooth Low Energy (BTLE) support in the device already.
Open-Source firmware options are always a great way to breathe new life into older devices that might otherwise end up in the landfill, creating an e-waste problem.
Right to Repair is important to me when considering which devices to purchase.
I read through the wiring diagrams for the Gen 2 switches, and this very helpful post about relay vs. mosfet switching & traveler wire communication to Aux smart switches. Q: When is 12-3 required, and when is it used for smart switch communication between devices?
My reasons for asking:
We’re at the electrical rough-in step of our home renovation project, and need to decide how to wire up the junction boxes.
We have to make a choice for what wiring to use, and how to connect the boxes before the drywall goes up.
The two blue light boxes will each have a standard 120V AC dimmer compatible wall sconce. The two switches below will control each separately. The 3-way option will need two other switches wired up near the entryway to this room. So, wiring for those would go up and over (probably through the ceiling), either from each of the two top circular light boxes, OR from each of the two rectangular switch boxes.
I need to figure out which wiring to use, and how it’s going to be hooked up if we go with one of the 3-way switch options.
Wire them as you would a standard 3-way with a line/load in the same box for the switch box underneath the light.
i.e. 2-wire line to the box under the light - 2-wire load up to the light - 3-wire over to the other switch by the door.
With the line coming into the box below the light AND a 3-wire over to the other switch, you’ll either be able to use another switch or an Aux (both using two of the three conductors).
But if some reason it makes sense to start the line in the other box, still wire it normally like a dumb 3-way, with the line in the door boxes and the load in the boxes under the lights. Really doesn’t matter all that much. You’ll still have a 3-wire between the two switch boxes.
If an electrician is wiring, he may have a preference where he wants to feed the load from.
Thanks! It definitely seemed like wiring with the 12-3 romex between switch boxes opens up the most possibilities, even using a standard 3-way “dumb switch” as a fallback for one or both boxes.
Looking at those wiring diagrams again, it seems like the 3rd red traveler wire isn’t even needed in some cases, like the 2 Inovelli switches wired as a 3-way. The only cases where the terminal labeled “traveler” is connected appear to be when using 3rd party “companion” / “Aux” switches. Of course, those wiring diagrams are all for the 2nd gen “Red” and “Black” series… which I’m making a huge assumption about being valid for the unreleased “Blue” & “White” series switches, because they may not fully apply. If this video is any indication, perhaps the caveats / limitations wiring up 2x Inovelli switches in 3-way w/Neutral mode may no longer apply to the newer series.
There is an in-app warning that the device isn’t certified and may not work correctly, and this particular setup requires a HomeBridge server. I’m not sure if there are any devices that work as-is (e.g., directly over Bluetooth or whatnot) without official certification, but that would likely be more difficult, even if not impossible. That part I’m not sure of.
