I was expecting it to be like a red dimmer, but with more scenes. In zwaveJS, the scenes for each button are represented by scene-001, scene-002 and scene-003 with the taps and holds and being the event of that scene. So, I was expecting this would just also have scene-004 and scene-005.
Yeah, it was in the junk email. Thank you.
Thinking some more about this:
I’ve been playing around with the zooz version of this, trying to see if it can do what I want with associations. The answer seems to be “yes, but only if nothing else controls the associated device”, which is a hard stop given that these are motion controlled lights. I got way into the weeds (sending raw zwave packets), and I don’t think it’s possible with that device.
I can think of a couple of ways inovelli could avoid this problem on your versions:
Use multi-command encapsulation to allow the dimmer to receive both basic set and multilevel set commands for the extra scene buttons. These would not control the hardwired load, but would update the internally stored state, and depending on configuration, perhaps also update the appropriate indicator bars. You would probably want to provide three association groups for each button, much like the three groups you have for the red series dimmers today, and the config parameter for deciding which events to forward to associated devices would also need to be replicated for each scene button.
Essentially, you’d have four red series dimmers in a single switch, three of them operating in “no local load” mode.
1 Like
I haven’t tried this myself - I also got a Zooz controller in the meantime, and was thinking of associating it with my iBlinds since they’re a little flakey - but would it work to associate the lights to the switch, then send the commands from motion events to the controller rather than the lights themselves? That’s similar to what I’m doing (in SmarThings) for lights, having motion or scenes command the (no-load) switch on the controller and the plugs and lights all follow the status of that switch via their own automation.
The problem is that the zooz scene controller (their version of this forthcoming inovelli product) doesn’t support any commands that allow you to “set” anything other than the locally controlled load. I’m still waiting for their engineers to get back to me (via a support ticket), but based on how the switch itself reacts to various zwave commands, it’s not possible (unless they add support via firmware update).
In trying to do this, I read through the raw zwave protocol documentation from SI Labs. The “right” way to do something like this is using the “MULTI_CHANNEL” command class, which allows a zwave device to define up to 127 additional “endpoints” that can essentially do anything a zwave device can do.
The zooz scene controller doesn’t support the MULTI_CHANNEL command class. I thought perhaps I could use the INDICATOR_SET command from the INDICATOR command class, but as far as I can tell it completely ignores that command.
From a “how does inovelli do this right” point of view, my suggestion would be to support the multi_channel and multi_channel_association command classes, and use those to allow the controller to send and receive basic set and multilevel set commands for each of the three scene buttons, separate from the commands sent to the main device (which would control the local load). The scene controller would then keep an internal state of the level of each of the three scenes, and use that to determine what commands to send to associated devices on which button pushes (basic set on, basic set off, start dimming up/down, multilevel set …, etc) according to logic that is somehow both powerful and intuitive. I’m not very good at getting both of those, but I’ve got confidence in the Inovelli team figuring out a good solution.
You already use the multi channel commands for the LZW36 fan/light switch, so this would be basically the same.
You would then also have configuration parameters for each scene button for determining which types of commands would get sent to associated devices. Perhaps this is where you could handle configuration of different button behaviors, too.
I’m brainstorming here, but off the top of my head these are the things I might potentially want it to be able to do as far as “when I push button X send command Y to the associated device(s)”
For pushing buttons:
- Whenever I push the scene button, send a basic set on
- Whenever I push the scene button, send a basic set off
- Whenever I push the scene button, send either a basic set on/off depending on the current state (toggle switch)
- When I push the scene button, send the central scene notification to the hub, but no message to associated devices. Instead, “activate” the dim up/down buttons to control that device/scene by zwave association.
For holding/releasing buttons:
- When I push the button, start fading up, and stop when I release.
- When I push the button, start fading down, and stop when I release.
- Alternate between those two behaviors every time I push and hold the button
You’d also definitely want the ability to control whether zwave-issued commands get forwarded to associated devices or not. Otherwise you’d never be able to get a bidirectional association like I can do with two red dimmers without an infinite loop of messages ping-ponging back and forth. Of course, you’ll only be able to have a bidirectional association with another device that supports multichannel associations, but that’s out of your control.
I’ve read through this thread and am excited for the device as I think it might address my use case, but I’m not sure.
I have a location that does not have a neutral. I want to use this switch with all 5-buttons triggering some action (in Home Assistant). The top buttons will trigger a ceiling fan (through a Bond Bridge). And the bottom two buttons will trigger the light in the fan (again through the Bond Bridge). The one thing I’m unsure of is that at this installation location, I’m not using a load. It was wired to control an outlet, but I bypassed it as I want the outlet to be always on.
Since I see above that without a natural, this will require a load…can I wire the outlet back in as the load but via the switch configuration have the bottom buttons not actually switch the outlet?
And yes, I wish like my other fan there was a neutral in this box so I could use the Fan+Light switch, but alas…
Short answer, no. The switch portion of this device is a dimmer, and you can’t wire a dimmer to a receptacle. There are safety reasons behind this prohibition and at least in the US, it is prohibited by the NEC.
1 Like
If you don’t need a load wire, you can likely rewire the other end of the cable that goes into this box so that it carries line + neutral instead of line + load. Does it go to the outlet? If so, that’s great, because the outlet definitely has both line and neutral.
That’s a good point. I reread your post and noted you don’t care about controlling the outlet. I also noted that you would prefer to use the fan/light combo switch, but don’t have a neutral at the switch box. However, you can use the same logic for the fan/light switch if that is what you prefer. As @mbbush pointed out, you can get a hot and neutral to the switch box if you wire the receptacle to have both receptacles unswitched. Now that you have the hot and neutral at the switch box, you can either use this 5-button scene controller OR the fan/light switch.
Note that there have been some issues with the fan/light switch and that Inovelli is not selling them until that’s resolved. So for the time being, you might be better off with the 5-button controller. You don’t need to use a physically wired load. At least as advertised, all five buttons can be used for scenes.
1 Like
Thanks Matt and Bryan! I think I’ll look at making that change at the outlet. This will give me several options for switches /controllers.
And thanks for the heads up on the fan/light switch issues. I have one that was a little hit-or-miss early on, but after a firmware update, it seems more reliable. Or it could just be in my head 
Any movement on this? Are they still only pre-order? And what happened to the black dimmers? Have they been discontinued? The website looks like a ghost town. The fancy exploded views are gone.
Working as hard as we can my friend – we’re waiting on some commitments from a couple B2B companies (should come this week or early next). Once we have those, we can have a bit more leverage with the manufacturer to speed things along.
We will open back up pre-orders likely when we have a solid date and more testing has been completed.
Yeah, black dimmers were discontinued a while ago: Black Series Discontinuation Announcement (and Sale!)
As for the ghost town of a website, yeah… appreciate the reminder lol. Hopefully one day the chip shortage will ease up. It’s been an interesting year to say the least.
4 Likes
thank you for the reply. I patiently wait.
2 Likes
Thanks for sharing. I’m ready to pre-order right now whenever it’s available.
Hi Eric, any word on solid dates?
5 Likes
I suspect that based on the news in other threads pertaining to 700 series chipset availability this product shipping will be quite delayed? I’m sooooooo excited about it and really hope that some 700 series chips get moving soon!
1 Like
Sorry, meant to post an update when I was tagged… ugh, my bad.
The update is that I think we will honestly just start refunding everyone. I’m still waiting on confirmation on a few things, but tbh, things do not look good from a Z-Wave standpoint, so I’d rather just refund everyone and then open the project back up when we have a more definitive answer.
Here’s where we’re at in terms of options:
- Z-Wave 700 Series (original scope): It’s been confirmed to us by Silicon Labs and our manufacturer that 700 Series is not an option for us in 2022. This also includes our fan/light switch, which is a huge blow to us. We’re told that if we want to go 700 Series, it will be a very limited batch and even so, they are recommending we just scrap the idea of using 700 Series.
- Z-Wave 500 Series: We’re told that 500 Series chips will become available to us starting in mid-Q2, with more supply opening up in Q3/Q4. We don’t really think this is a feasible solution for this product as it’s older technology and we likely wouldn’t be able to put everything we want on the product. In other words, we’d be releasing a product we don’t really believe in, which is a non-starter.
- Z-Wave 800 Series: We’re being sold heavily on moving to 800 Series, which will begin Q4 of this year or Q1 2023. This is definitely something we’re considering as we planned on updating our 500 Series to 800 Series when the chips are ready. However, there is no confirmed date from SiLabs on when this will launch and if it’s anything like 700 Series, I don’t really want to be a beta for this technology given the issues we’ve had with 700 Series hubs
- ZigBee 3.0: We were planning on launching a ZigBee version of this switch once the Z-Wave version was completed, but given the Z-Wave version likely isn’t going to kick off now until end of the year or beginning of next year, we may have an opportunity to fast track it via ZigBee. This is where the negotiations are right now.
The initial company preferred ZigBee, but was convinced to do Z-Wave by a former employee. If this converts to ZigBee, we may be able to convince them to partially fund this project. In addition, there has been another company that’s approached us that wants this to be WiFi or ZigBee.
Long story short, if I don’t get any traction by March 1st, I’m just going to refund everyone as it’ll have been almost a year at that point and I’m already embarrassed enough lol.
Edit: On a positive note, at least we provided some inspiration for Lutron:
In fact, their entire new line looks pretty familiar:
4 Likes
Given the amount of issues with the 700 series I’m not surprised. Seems like it was a bad design.
1 Like