Hubitat or HomeAssistant for inovelli?

[nappyjim]

Does Hubitat offer any advantages over HomeAssistant as it relates to inovelli switches?

In my basement I have 2 sets of lights, so I have a scene setup (thru node red in Home Assistant) where I press up twice on either light paddle and both sets of lights will turn on.

Sometimes, pressing up twice, the first set turns on and then 3 seconds later, the 2nd set does.

Is that latency a limitation of the Zwave protocol or is that more home assistant? My Z wave signal is strong.

I’m still at the beginning stages of my smart home, so if I’m going to switch, now would be the time.

[djordan2112]

I run Hubitat, and have no problems with my Inovelli switches. I do not have any experience with HomeAssistant, but you may be able to solve your issue by using associations. Here is a good rundown of how they work. As I am not familiar with HomeAssistant I can’t offer adivce on how to set them up.

Z-Wave Groups, Scenes & Associations

[jtronicus]

@nappyjim

Is that latency a limitation of the Zwave protocol or is that more home assistant?

The issue is likely a combination of HA and the OZW/zwave component. OZW is currently not able to send commands to multiple devices simultaneously (I am not sure if Hubitat can), and has to issue individual commands to each light. My guess is that OZW is transmitting a lot of packets when you trigger the scene, which is causing a delay.

A couple questions:

• Are you using the current zwave component in HA, the new Openzwave beta component, or something else (such as zwave2mqtt)?
• are the lights you are turning on smart bulbs, or dumb bulbs connected to the switches?
• If you are using smart bulbs, which ones are you using?
• Are your switches actually switches, or are they dimmers?

[nappyjim]

@djordan2112 I never thought about doing an association as opposed to a scene. I may try that and see if its quicker.

@jtronicus I am using the older Z wave implemention in HA. I believe its 1.04 or 1.05. I also have another virual machine with OpenZWave beta installed on it. I may try the same logic in that setup so to see.

Dumb bulbs
They are inovelli red series dimmers.

In node red I have a scene setup that 1 press up on paddle turns on basement stairs and basement lights. 1 press down turns them off.

If I press the actual stairs switch, those turn off quick but the basement lights take anywhere from 2-6 seconds. And vice versa if I press the actual switch for the basement lights.

Kind of off topic here, but I have a C7 unit coming just cause I want to see how Hubitat is. Can I do any initial setup without the hardware, or do I need the hardware to even start the install?

[jtronicus]

If your intent is to create a virtual 3-way (always controlling both lights from either switch), I recommend setting up associations:

Stairs Switch:

• Group 3 (multilevel switch) -> Basement Lights
• Group 4 (Switch multilevel start/stop) -> Basement Lights

Basement Light Switch:

• Group 3 (multilevel switch) -> Basement Stairs
• Group 4 (Switch multilevel start/stop) -> Basement Stairs
• Parameter 12 (Association Behavior): Set to value 11 or your switches will forward commands back and forth forever

Once associations/parameters are set, you will no longer need the node red automations.

This will allow either switch to control both lights (even if your hub were to go down). You will also want to make sure you never control the Basement light with HA. You will instead control the Basement stairs light in HA and the basement stairs light will automatically forward the command to the basement lights in order to keep everything in sync.

[nappyjim]

@jtronicus My stairs lights are two switches already, both red series dimmers. Just 1 switch for basement lights. Heres a graphic to help explain. Do you suggestions above still remain true?

[dvellek]

@jtronicus

Stairs Switch:

• Group 3 (multilevel switch) -> Basement Lights
• Group 4 (Switch multilevel start/stop) -> Basement Lights

Basement Light Switch:

• Group 3 (multilevel switch) -> Basement Stairs
• Group 4 (Switch multilevel start/stop) -> Basement Stairs
• Parameter 12 (Association Behavior): Set to value 11 or your switches will forward commands back and forth forever

By chance what ramp rate do you use personally? I have both of my switches set at 0 but when I do this my non load switch the lights phase on/off instead of instant.

Also do you use google/alexa to ever turn on the lights, when I use google the LEDs get out of sync.

[nappyjim]

Well now that I’m thinking about it, I could just blank out the basement stairs switch (since the basement lights switch would control the stairs as well).

Then that way I just have a single switch for stairs in the kitchen and a single switch for basement lights in the basement. Then associate those two.

Im not sure about ramp rate, Ill have to check. (I just got into this smart home stuff about 2 months ago when we started looking for a house to buy, we currently rent)

[jtronicus]

You can create a virtual 4-way (any of the three switches control both lights) like this:

Stairs Master Switch:

Group 3 (multilevel switch) -> Basement Lights, Stairs Slave
Group 4 (Switch multilevel start/stop) -> Basement Lights, Stairs Slave

Basement Light Switch:

Group 3 (multilevel switch) -> Stairs Master
Group 4 (Switch multilevel start/stop) -> Stairs Master
Parameter 12 (Association Behavior): Set to value 11 or your switches will forward commands back and forth forever

Stairs Slave Switch:

Group 3 (multilevel switch) -> Stairs Master
Group 4 (Switch multilevel start/stop) -> Stairs Master
Parameter 12 (Association Behavior): Set to value 11 or your switches will forward commands back and forth forever

[jtronicus]

@dvellek

By chance what ramp rate do you use personally? I have both of my switches set at 0 but when I do this my non load switch the lights phase on/off instead of instant.

My Ramp rate is set to 0 on all devices. I havent noticed any issues, but the bulbs I use are a little weird when it comes to dimming. With the current firmware, the ramp rate/dimming speed cannot be changed for associated devices (the switch always tells associated devices to use the “default” dim speed.)

If you truly want a ramp rate of 0 on everything, and one of the switches has no load, you may be able to do this as a workaround:

Load switch:
Group 3 (Multilevel set) -> No-load switch
Group 4 (Multilevel start/stop) -> No-load switch

No-load switch:
Group 2 (basic set) -> Load switch
Group 4 (multilevel start/stop) -> Load switch
Parameter 12: Set to 11

@dvellek

Also do you use google/alexa to ever turn on the lights, when I use google the LEDs get out of sync.

I do use google to turn lights on/off. However, I did not expose the no-load switch to Google. As long as Google controls the load switch, the load switch will force the no-load switch to stay in sync. If you control the no-load switch with google, the command will not get forwarded, and the leds get out of sync

[nappyjim]

What is parameter 12 and what are the setting options? I dont see it on parameter sheet

[nappyjim]

@jtronicus I took out one of the basement stairs switches so I just had one switch for the stairs and one for the basement. I set them up as you suggested, both in groups 3 & 4, controlling each other. Set parameter 12 of the basement lights to 11.

Works great!!

Do you have any links or can you explains the the association groups better. What would happen if I didnt associate group 3 on either switch, for example.

[jtronicus]

Association group 1 (Lifeline): This is the device your switch communicates status updates to. It is set automatically when you include the dimmer, and should almost always point to your hub.

Association group 2 (Basic Command Class): This is used to send basic on/off/dim commands to another device. Almost all devices support this type of command. It can be used to send on, off, or a dim level, but does not support dimming duration, and does not allow you to hold the button down to gradually dim a device.

Association group 3 (Multilevel Switch Command Class): This is also used to send on/off/dim commands, but includes additional features. This command class supports dimming duration. It also allows you to do gradual dimming by holding the buttons down (however, the Inovelli dimmers moved this functionality to Association group 4). Not all devices support this command class. For example, the Inovelli Switches (not dimmers) do not support this, so you should use Association Group 2 instead of 3 if you were trying to control them.

Association Group 4 (Multilevel Switch Command Class). This is the same command class as group 3, but is only for the gradual dimming functionality you get when holding down the buttons on the dimmer.

The Inovelli dimmers also support a form of command forwarding. Whenever you control the dimmer (either from your hub, the physical buttons, or from another zwave device), it will attempt to forward that command to any devices in Association groups 3 and 4 based on the source of the command and the value set in config parameter 12:

Parameter 12	Command will be forwarded when received from
0	No commands will be forwarded
1	Physical button presses
2	3-way addon module button presses
3	3-way & physical
4	zwave (either from hub or from another device)
5	zwave & physical
6	zwave and 3-way
7	zwave, physical & 3-way
8	timer (auto-off timer in parameter 8)
9	timer & physical
10	timer & 3-way
11	timer, 3-way & physical
12	timer & zwave
13	timer, zwave & physical
14	timer, zwave & 3-way
15	all

The default value for parameter 12 is 15, meaning it will forward any command it receives from any source to all devices in Association group 3/4. If we dont change this parameter value when setting up a virtual 3-way, we will get an infinite loop. Dimmer 1 will forward command to dimmer 2, which will forward it back to dimmer 1, which will forward to dimmer 2, etc.

Setting Parameter 12 to value 11 on all devices in the virtual 3-way except the “master” device will prevent the infinite loop. If Dimmer 1 is the master:

• Pressing the physical button on Dimmer 2 will cause the command to be forwarded to Dimmer 1 via zwave. Dimmer 1 will forward the command back to Dimmer 2, but thats as far as it goes (Dimmer 2 will not forward commands received via zwave). At this point, devices are in sync.
• Pressing the physical button on Dimmer 1 will cause the command to be forwarded to Dimmer 2 via zwave. Since Dimmer 2 does not forward zwave commands, it stops there and all devices are in sync.
• Setting Dimmer 1 via zwave from the hub will cause the command to be forwarded to Dimmer 2 via zwave. Since Dimmer 2 does not forward zwave commands, it stops there and all devices are in sync.
• Setting Dimmer 2 via zwave will NOT cause the command to be forwarded to Dimmer 1. Devices will not be in sync. This is why you only want to control the “master” dimmer, and let it forward the commands to keep devices in sync.

An added benefit to this method is that the devices all communicate directly with each other without going through the hub first. This causes everything to both run faster, and it will still work if the hub goes offline.

[jvm33]

@nappyjim

Sometimes, pressing up twice, the first set turns on and then 3 seconds later, the 2nd set does.

This is a guess, but . . .

This may be a driver issue to make up for Hubitat’s lack of support for the Z-Wave “Switch MultiLevel Version 4” command

The MultiLevelV4 command reports to the controller the Devices value and, if the device is transitioning, the target Value and time it will take to reach the target value.

Without the MultiLevel V4 command, Hubitat only receives a “current Value” report. Depending on the driver implementation, it may wait a short while – i.e. 3 seconds – and then query for the value of the dimmer just to be sure it has the “final” value. Only after that does it report that the dimmer has changed. This may explain the 3 second delay - It turns out that 3 seconds is a “common” default transition time in many device so some drivers build this in as a transition time. With MultiLevel V4, Hubitat doesn’t have to do the second query as it receives the target value on the first report and can instruct other devices right away.

This is only a guess as to what may be happening.

[nappyjim]

@jtronicus

So you know how you had me set both the basement light switch and the stairs switch to control each other in groups 3 & 4 (post 6/14 on Nov 18) Then for the basement light switch, you had me change parameter 12 to an 11.

Is there a reason I changed that switch to an 11 and not the stairs switch?
Could I have changed the stair switch to an 11 instead?
Can I change both the switches to 11?

Everything works Im jus circling back to try to gain better understanding. Thanks

[jtronicus]

@nappyjim

Is there a reason I changed that switch to an 11 and not the stairs switch?
Could I have changed the stair switch to an 11 instead?

There are a couple different ways you could set things up. Basically, pick one switch to be the “parent” switch, and all other switches will be considered “child” switches. The parent switch needs the parameter set to 15, and all children need the parameter set to 11. This setup supports up to 6 devices (1 parent and up to 5 children).

• The parent switch associates with all children on groups 3 and 4, and has parameter 12 set to 15.
• The children switches only need to associate to the parent switch, and will need parameter 12 set to 11.
• When you want to control the lights with your zwave hub, you only need to control the parent, and the parent will keep the children in line sync.

With this arrangement:

• If you press a button on a child switch, the child switch will update the parent, and the parent will update all other children.
• If you press a button on the parent switch, the parent will update all children.
• If you control the parent via zwave, the parent will update all children.
• If you control a child switch via zwave, the child will NOT update the parent or any other children (switches will be out of sync).

You can pick any switch to be the parent, but there can only be 1 parent.