Any timelines are restocking the Red Series? Looking for Dimmers, mainly, since I know fan controls are probably discontinued at this point. It’s been nearly a year, and buying 1’s and 2’s off eBay and forums stinks! I’d love to complete my whole-house install.
The previous Red series dimmers have been discontinued due to supply problems. The new 800 Series is currently estimated for March/April, according to Eric’s last update.
2 Likes
OK, so here is my frustration.
I’m using both Red Series Dimmers and Switches throughout my house. I use the LED notifications for various things, and currently I have to pass 2 different values to achieve the same effect, based on whether I’m addressing a Dimmer or a Switch. It’s pretty inefficient and frustrating, so I’ve decided to streamline and replace all of my Switches with Dimmers, and convert them to On/Off via configuration, so I can pass one value and update everything that needs to be updated. However, I can no longer get any of these dimmers reliably or cost effectively.
Do we know yet if the 800 Series are going to be configuration-compatible with the Dimmers and the LED Calculator values, or am I going to have to set up a 3rd set of values for these new switches to receive the same effect?
1 Like
I’ve had mine since July 12th, 2022 and they have not unpaired once. But they are Zigbee bulbs, and anybody without a strong Zigbee network may experience this with just about any device.
I can echo this frustration. I have switches, dimmers and lzw36’s. So I’ve got to set switches, dimmers, and the top and bottom led’s on the fan switch separate. I use a script in HA to run through the sequence.
My hope would be that the new 800 Series will use the same parameters as the 500 Series dimmers so they can all be set through a single multicast command.
The 800 series Reds have a lot more in common with the Blue series than the 500 series Reds. The older Reds are a different manufacturer than the Blues and new Reds. Model numbers that start with “V” have virtually identical parameters and functions (with a few exceptions). Model numbers that start with “L” have different parameters and don’t support as many functions (like individual LED notifications)
I mean as far as common settings go.
For example setting the LED bar a solid color.
On a switch it’s 112-0-5 yet on a dimmer it’s 112-0-13. So commands have to be directed at 2 different parameters. If the 800 series has this setting in parameter 112-0-25 then it’s one more broadcast command that needs to be sent out instead of just adding a device_id to the one that’s already being sent out.
I understood what you meant. But I’m not sure you understood what I meant
All the new Inovelli devices that start with “V” in their model name use a common set of parameters. Doesnt matter if it’s Blue or Red. The old (and discontinued) devices that start with “L” in their model name use different parameters
I’m not understanding what you mean because I’m not understanding how it can be possible.
The new 800 red series is zwave. The blue series are zigbee. Zigbee devices do not have parameters. Now the old “L” and new “V” zwave devices will both have parameters regardless of 500 or 800 and regardless of the manufacturer.
Settings (parameters) for the led bar (and other features) has nothing to do with which radio (zigbee or zwave) it has
Are you splitting hairs with me? Ok, so zigbee terminology calls them “attributes” but the concept is the same. I’m using the term parameters as a common term that defines the configuration settings available to the device. Zwave and Zigbee both have configuration settings (also known as “preferences” in Hubitat). And in the case of Inovelli “V” models they use the same set of configuration settings across both Blue (Zigbee) and Red (Zwave). The V models all use the same front-end with virtually the same configuration settings and features but a different radio (zigbee or zwave) on the back-end
They all have config parameters but they differ between manufacturers and are not all the same between old “L” and new “V”. Likewise, Zooz and GE Zwave parameters are not the same
1 Like
This may help clarify…
Here is an example command to change the default LED color of the LZW31-SN.
service: zwave_js.multicast_set_value
data:
property: "13"
value: 165
command_class: "112"
target:
entity_id:
- light.kitchen_light
- light.dining_room_light
- light.sunroom_light
- ........
alias: Switches - Blue LED
Assumingly the new 800 series red will also have the functionality to change the default LED color. This is available on the new Blues as well. But how that’s changed by the user is going to be vastly different because of the 2 radios being used. Obviously it’s not going to respond to me attempting to send arguments to a cluster on an endpoint through ZHA. Nobody would expect that to work. In order to change that default LED color on the 800 red’s a zwave command will need to be sent.
What we are saying here is that we would like that command to be the same from the old switches to the new switches. We would have the ability to just add the entity_id to the list provided and have the new 800 series change the default LED just like the old ones.
It would look like this:
service: zwave_js.multicast_set_value
data:
property: "13"
value: 165
command_class: "112"
target:
entity_id:
- light.kitchen_light
- light.NEW_800_RED SERIES
alias: Switches - Blue LED
There are already automations in place, blueprints created, node-red pallets created. If the new switch requires us to send the command to let’s say 112-33 instead of 112-13 then ALL of that needs to be recreated and called completely separately. This means another set of blueprints need to be released, a new node-red pallet developed, users will have 1 automation for the old switches and another automation for the new switches. It’s not an “optimum” user experience. And it also means it’s slower to respond since multiple commands are having to be send seperately.
For the service calls we’d end up with this (2 separate service calls):
service: zwave_js.multicast_set_value
data:
property: "33"
value: 165
command_class: "112"
target:
entity_id:
- light.NEW_800_RED SERIES
alias: Switches - Blue LED 800 series
service: zwave_js.multicast_set_value
data:
property: "13"
value: 165
command_class: "112"
target:
entity_id:
- light.kitchen_light
alias: Switches - Blue LED 500 Series
This may be a non-issue in hubitat because I believe the drivers expose the preference to the UI, you can go into rule machine and select the preference to change default LED color and then the driver translates that and sends it off to the switch. So as long as the same preference is being manipulated, you could have both switch types and the associated drivers would send it to the right spot correct? Something similar could be achieved in HA if the preference were exposed as an entity (as they are with the blues but not with the 500 series reds), but we would not be able to take advantage of multicast by manipulating the entities.
It does. But all the new “V” models have more processing capability and a lot more features than the old “L” models. So there are a lot more parameters and thus they aren’t going to be the same. Even the old “L” models weren’t 100% consistent with parameter numbers because they didn’t have all the same features. The good news is that going forward with the new “V” models Inovelli is trying very hard to be consistent with parameter numbers across the different “V” models, but they aren’t going to match with the old “L” models.
Well that sounds like a Home Assistant issue. In the Hubitat and SmartThings drivers there is very little difference. All the front-end code is the same, Essentially, the only difference is the final command sent to the radio. I basically took all the same code from the Blue driver for the Red-800 driver and changed the “zigbee.writeAttribute” commands to “zwave.ConfigurationSet” commands … nothing “vastly different”
After all is said and done. The new “V” models are going to give you what you are asking across both Blues and new Reds (V models with 800-series chips). But it’s not going to match the old “L” models. So if you build a new blueprint for the “V” models you’ll be able to send a multicast to them. But you’ll still need to send a different multicast to the old “L” models
Except the value you pass to the Red Dimmers is different than the value you pass to the Red Switches or Red Fan Controllers to achieve the same LED effect.
This is one of those cases where I’m not sure the designers of the product actually use the product beyond it’s basic capabilities.
That is true of almost any brand. Look at all the Zooz and GE switches. They have different parameters depending on which switch model it is. I don’t have any Lutron or other brands, but I’m pretty sure its the same with them as well.
Inovelli employees definately use their product in their personal homes and recognize that having consistency across models is desirable (but not always 100% possible). That is why all the NEW models going forward are DESIGNED to use a consistent user interface (as much as possible). But due to all the enhanced new functionality with the “V” models (like individual LED control and individual up/down dimming rates and individual on/off ramp rates) it was not feasible to make it match the limited functionality of the older “L” models.
1 Like
@Jonesie - I can definitely see the frustration here in terms of setting the values across multiple products and it being different. I think @mamber summed it up the best in that consistency is what we strive for, but it’s often difficult when more and more features are added (some that we wouldn’t have even thought of back when the Gen 2’s were launched).
I think the one thing I think we did overlook was Home Assistant initially with the Gen 2’s. It wasn’t as prevalent back when we first launched them (in fact, I think we were afraid to even attempt testing on that platform bc it seemed like every other day there would be an issue – glad things have changed!) and as mamber said, Hubitat and SmartThings don’t require special calculators to get the various notifications/animations to work. In other words, the end user would never know there’s different values passed on.
Now that Home Assistant has really caught on, we’ve adjusted how the Gen 3’s work and plan to stay consistent moving forward and most of our beta testers are using Home Assistant and can (and do) call out any UX issues.
Hopefully that gives some context – I personally use SmartThings as I do not have a coding background and use almost all the advanced features (bindings, notifications, parameter changes, scene control, etc) on just about all my switches (30ish) which are the Gen 3 Blue Series (and 1 800 Series). It’s just that all the calculations are done on the Edge Driver level so I don’t have to finagle with a calculator.
Again, I hope moving forward we can stick with a consistent framework for the more advanced hub/gateways.
5 Likes