iBlinds v3: Hide Binary Switch CC

[habhomegit]

Feature Request
This feature request is related to a problem our users are having when using Home Assistant. I've searched the JS documentation for the possibility of implementing a solution to no avail. If there is already a solution in place please forgive my lack of knowledge.

I am the CTO at HAB Home Intel the maker of the iblinds product. Our users are having some issues with the driver implementation. Mostly related to the fact that our product works with Horizontal blinds tilt where fully open/ON is 50% not 99% Here are a few issues that it would be nice if we could fix/override by using the device configuration file:

From my little knowledge, it appears that the device driver supported commands are constructed by interrogating the device during the inclusion process for supported Command Classes. In the case of our iblinds v3 device (because all controllers are not created equally) we support the Binary CC, Multilevel Switch CC, and Window Covering CC for controlling the horizontal tilt position. The Binary CC works as expected Close/Off = 0 and On/Open sends a 0xFF (255) and the device opens to 50%. For Multilevel Switch CC sending a level value of 0..99 works well, however, if an ON command is sent using a value of 0x63 (99) that is perfectly acceptable for the majority of multlevel switch devices like lights and even roller shades but in our case the 0x63(99) closes the blinds in the opposite direction. We need the blind slats to tilt to 50% to fully open.

Solution Request
It would be nice if there was support to override certain command class specifics in the device configuration file.

• Having the ability to ignore a certain supported command class (in our case ignore binary command class because the multilevel switch CC is preferred when it is also supported by the controller) . Also, In HA the Cover Device gets out of sync because we only send back the REPORT from the requested GET command. For example If the users uses the value slider a multilevel swtich command is sent followed by a multilevel GET, our device only sends the multilevel REPORT. This causes the Binary and Multilevel UIs to become out of sync.

• Having the ability to change the ON value for multilevel switch (in our case if the multilevel switch command received is ON / (0xff) 255 then we have our firmware configured to open the blinds to 50%.

Considered Alternatives

• We have implemented a Z-Wave configuration parameter that will remap a multilevel switch command of 99 to 50% but it is not available for our older product versions.

Additional context
We would be happy to send you an iblinds motor for testing at your request.

[AlCalzone]

• Having the ability to ignore a certain supported command class (in our case ignore binary command class because the multilevel switch CC is preferred when it is also supported by the controller)

We can absolutely do that. Our config files allow adding and removing CCs from/to individual endpoints or all of them:
https://zwave-js.github.io/node-zwave-js/#/config-files/file-format?id=commandclassesremove

if an ON command is sent using a value of 0x63 (99)

AFAIK, that's caused by Home Assistant, which uses 255 for lights/dimmers, but 99 for covers. I think the latter makes sense because you usually don't want covers to go to the last non-zero position, but rather open them. Although there seems to be some handling for tilt - I'll check with the devs to see if this is something that can be optimized on the HA side.
We generally don't do device-specific magic in the driver (i.e. this project) unless it can be broadly applied to more devices, so remapping 99 to 50 here is something I don't like to do.

On the other hand, support for the Window Covering CC was just merged recently. When that gets added to HA, it should be able to do the right thing, because it can identify that the device is operating using tilt and not position.

[AlCalzone]

We would be happy to send you an iblinds motor for testing at your request.

Actually, I'll take you up on this offer. Please contact me via e-mail (see my Github profile) so we can talk about the details there.

[habhomegit]

Awesome!! e-mail sent.

[raman325]

@habhomegit do you have Home Assistant set up? If you can upgrade to zwave-js 10.16.0 and get a device diagnostics dump from Home Assistant for the iBlinds device, that would be a huge help for us to add support for the Window Covering CC. You may have to reinterview the device so that zwave-js can pick up the Window Covering CC.

If you need help doing this, let me know and we can do a walkthrough.

[AlCalzone]

@habhomegit As an update:

• This project, and by extension Z-Wave JS UI have proper support for the Window Covering CC now, so opening the blinds is just a matter of pressing "Open" or selecting the correct target value from a dropdown
• Support in HomeAssistant itself is in the works, but this is likely to take a bit longer since cover entities are currently implemented with the assumption that 100% is open.

[raman325]

this can be closed, we added support in HA and the release with support for the Window Covering CC

[danielbrunt57]

@habhomegit I have 7 of these motors, one is V3 and the others are V2. I see three entities now in HA for the V3 motor:
switch.kitchen_blind_1 (open/close), light.kitchen_blind_1 (position), and cover.kitchen_blind_1_horizontal_slats_angle (tilt), but my V2 motors are unchanged. Do they not support the Window Covering CC?

[danielbrunt57]

@raman325 My cover.kitchen_blind_1_horizontal_slats_angle reports status as unknown:

[raman325]

That's expected. The state of a cover device only supports position, as in for a shade or gate while tilt is an attribute. I have proposed to make tilt be valid for state here: home-assistant/architecture#908

[habhomegit]

@raman325 and @AlCalzone thanks for the support and updates to support the Z-Wave Window Covering CC. This is great news!!!

[habhomegit]

@habhomegit I have 7 of these motors, one is V3 and the others are V2. I see three entities now in HA for the V3 motor:
switch.kitchen_blind_1 (open/close), light.kitchen_blind_1 (position), and cover.kitchen_blind_1_horizontal_slats_angle (tilt), but my V2 motors are unchanged. Do they not support the Window Covering CC?

@danielbrunt57 Window Covering CC support rolled out with Z-Wave 700, your V2 motors will still need to utilize MutliLevel Switch CC, as they are based on the 500 Series. The iblinds implementation of Window Covering CC support began with v3 when we transitioned to the 700 Series.

[AlCalzone]

Just to be clear, the default HA controls now seem to control tilt blinds in the 0-50 range (closed to one side ... fully open):

All values above that are available via the slider:

...which is not perfect, but there are architecture discussions going on to improve these things:

• Proposal: Extend `cover` entity to support tilt only devices home-assistant/architecture#908
• Proposal: Support bidirectional close tilt for covers home-assistant/architecture#912

As for the original issue, node-zwave-js version 11 will hide Multilevel Switch CC when Window Covering CC is supported. This is required per the specification, and will solve the issue that there's no cross-sync between these CCs.
The Binary Switch CC will need to be hidden via the config file.

I'll keep this issue open until those things are done.

[danielbrunt57]

@habhomegit I have 7 of these motors, one is V3 and the others are V2. I see three entities now in HA for the V3 motor:
switch.kitchen_blind_1 (open/close), light.kitchen_blind_1 (position), and cover.kitchen_blind_1_horizontal_slats_angle (tilt), but my V2 motors are unchanged. Do they not support the Window Covering CC?

@danielbrunt57 Window Covering CC support rolled out with Z-Wave 700, your V2 motors will still need to utilize MutliLevel Switch CC, as they are based on the 500 Series. The iblinds implementation of Window Covering CC support began with v3 when we transitioned to the 700 Series.

It would be extremely nice if I could upgrade my V2 motors to V3 with a board swap, rather than buying all new V3 kits. If there's anything you can do on that front, it would be greatly appreciated, by not only myself but a lot of other early adopters!

[habhomegit]

@danielbrunt57 we truly value and appreciate our early adopters. However, in order to switch to the v3 version, you will need to replace all three PCBs (main board, connector board, and charge adapter board) as well as the motor, as the v3 utilizes a different motor model too.

To explore potential options for you, please reach out to us via email at support@myiblinds.com. We can discuss the possibility of arranging a discount upgrade program.

[danielbrunt57]

CTO at HAB Home Intel

• Having the ability to ignore a certain supported command class (in our case ignore binary command class because the multilevel switch CC is preferred when it is also supported by the controller)

We can absolutely do that. Our config files allow adding and removing CCs from/to individual endpoints or all of them: https://zwave-js.github.io/node-zwave-js/#/config-files/file-format?id=commandclassesremove

if an ON command is sent using a value of 0x63 (99)

AFAIK, that's caused by Home Assistant, which uses 255 for lights/dimmers, but 99 for covers. I think the latter makes sense because you usually don't want covers to go to the last non-zero position, but rather open them. Although there seems to be some handling for tilt - I'll check with the devs to see if this is something that can be optimized on the HA side. We generally don't do device-specific magic in the driver (i.e. this project) unless it can be broadly applied to more devices, so remapping 99 to 50 here is something I don't like to do.

On the other hand, support for the Window Covering CC was just merged recently. When that gets added to HA, it should be able to do the right thing, because it can identify that the device is operating using tilt and not position.

It's nice to finally see horizontal & vertical slats making some headway after all these years.

[danielbrunt57]

@AlCalzone

The Binary Switch CC will need to be hidden via the config file.

Is this something an end user could/would have to do, or will this be done within zwave-js at some point?

[AlCalzone]

I'll do it in the next major release.

[tommyjlong]

Thanks for digging into this ....

The blind device now has a new control item which is the multi-level switch ON/OFF which does reflect the state that the Zooz switch sent to the blind.

In my case a Binary Switch does indeed get added on the fly to ZwaveJS-UI and a new "switch" gets added to HA, but they don't work. When changing the state directly in ZWaveJS-UI, it fails and a log message says does not support the Command Class Binary Switch! (ZW0302)

Rather than trying to fight it, why not just eliminate the group link and use the Illumino Swich in the HA automation to simply open or close the two blinds?

That's what I will end up doing if there is no other way of course. One advantage I get with the Illumino Switch is that it supports Beaming and can wake up the iBlinds very quickly and start changing its position. In contrast, using a button (WallMote Quad) to control another set of blinds via HA in my experience can take several seconds before the iBlinds start changing.

[danielbrunt57]

I later tried using the switch in HA and got what you reported does not support the Command Class...
I thought you might be able to use either it's state or the state of the Illumino switch though as a trigger for your automation to update the slats angle.
What would be nice is for the blind firmware to internally synchronize the multilevel switch and the horizontal slats angle.
It does not even update the angle with a refresh values command indicating it internally has no idea the angle changed via the switch which is a gross oversight in firmware programming. I think I would concede to this as a losing battle and just find another way...

[AlCalzone]

The multilevel switch @danielbrunt57 shouldn't even appear since the device supports Window Covering CC. This is a bug and Z-Wave JS should not expose it. Don't rely on it, this will stop working at some point. The binary switch shouldn't appear either.

I find it a bit weird that the device sends a Binary Switch report to the controller when another device controls it via Binary Switch CC. I would have expected a Window Covering CC report. I don't really have a good solution outside of:

• not using direct associations to control this
• having the device send a Window Covering Report instead

Maybe @habhomegit have some insight on this behavior?

[danielbrunt57]

The multilevel switch @danielbrunt57 shouldn't even appear since the device supports Window Covering CC. This is a bug and Z-Wave JS should not expose it. Don't rely on it, this will stop working at some point. The binary switch shouldn't appear either.

I find it a bit weird that the device sends a Binary Switch report to the controller when another device controls it via Binary Switch CC. I would have expected a Window Covering CC report.

There is no binary switch report from the blind to the controller, just a multilevel switch report to the controller after the binary switch device controlled it via binary switch CC which causes Z-Wave JS to show it and is reflected back into HA:

It's state can be examined but not changed: {{ states('light.kitchen_blind_1_31') }} is 'on'. That could then be used in an automation to trigger a service: zwave_js.refresh_value to the blind so the tilt angle gets updated. The multilevel switch cannot be used to open/close the blind though. Furthermore, the multilevel switch is removed from Z-wave JS if you do a re-interviw node until such time as the binary switch device controls it again and then it re-appears.

[AlCalzone]

I see, that means we could map the report to the corresponding Window Covering value.

[tommyjlong]

There is no binary switch report from the blind to the controller, just a multilevel switch report to the controller after the binary switch device controlled it via binary switch CC which causes Z-Wave JS to show it and is reflected back into HA

In my case The Illumino Switch is configured to send a Binary Switch to the iBlinds and the iBlinds in turn sends a Binary Switch Report to ZWaveJS (It does not send Multilevel) Here is what the UI sees:

[danielbrunt57]

In my case The Illumino Switch is configured to send a Binary Switch to the iBlinds and the iBlinds in turn sends a Binary Switch Report to ZWaveJS (It does not send Multilevel) Here is what the UI sees:

That's bizarre! After my Zooz ZEN76 switch sends it's binary switch ON|OFF to blind 1, I see a multilevel switch created for blind 1:

[danielbrunt57]

That v3 motor is one of their first v3's (1.5-2yrs old?) and my other two v3's are 6 mths old and have a newer Z-Wave chip and newer firmware available for them:

[danielbrunt57]

I see, that means we could map the report to the corresponding Window Covering value.

I'm not sure of the implications of that but based on this new info, you would have to deal with multi-level &/or binary switch reports. Perhaps you should stay your present course and steer clear of trying to deal with binary/multilevel switches which likely are not supported by the window covering CC? While one user likes the near instant on|off provided by a beaming switch (my Zooz is not instant; it takes like 1-2 seconds to trigger the blind), I think this particular use-case is very limited, and I personally do not need it. Just my 2¢.

[danielbrunt57]

On a different but slightly related note, @tommyjlong you might be interested in this item I just stmbled across today. It started with a python script hass_py_set_state to update states/attributes (hass-setter can also do it) to update HA entities. It was referred to by the desire for the HA state of horizontal slat window coverings to show open|closed vs unknown, The state is meant for positionable blinds (up/down) vs tiltable blinds (horizontal slat tilt) and therefore simply shows unknown for horizontal slat blinds but this process overrides the state. My automation using the python script mehod:

alias: iBlinds State Update
description: ""
trigger:
  - platform: state
    entity_id:
      - cover.kitchen_blind_1
      - cover.kitchen_blind_2
      - cover.kitchen_blind_3
    attribute: current_tilt_position
  - platform: state
    entity_id:
      - cover.kitchen_blind_1
      - cover.kitchen_blind_2
      - cover.kitchen_blind_3
    to: unknown
condition: []
action:
  - service: python_script.set_state
    data:
      entity_id: "{{ trigger.entity_id }}"
      state: >-
        {{ iif( 5 < state_attr(trigger.entity_id, 'current_tilt_position') <
        95,'Open', 'Closed') }}
mode: parallel

[tommyjlong]

I see, that means we could map the report to the corresponding Window Covering value.

I would be happy with that. Multilevel Report mapping one-to-one with window coverings horizontal slats position, and Binary Switch "ON" to horizontal slats position 50% (or even better, to the iBlinds configuration parameter 4 "112-0-4 Default ON Value") and "OFF" to 0%.

[danielbrunt57]

After receiving a Binary Switch On/Off set request from the Illumino Switch, the iBlinds would update ZwaveJS via a Binary Switch Report and in turn HA would update its "switch" state of the iBlinds. I use this HA "switch" update to trigger an automation which in turn would set the HA "cover" position so as to keep the "cover" state of HA in sync.

Since the Illumino switch is a Z-Wave entity in HA, in addition to the group which gives you direct instant ON|OFF, why not simply use the Illumino switch entity's state in HA to trigger your automation to update HA's cover position???

One problem I see with your logic is...what happens if the cover is closed via HA rather than the Illumino switch? Should that occur, the Illumino switch is still on but the blind is now closed and to open the blind via the switch requires the user to toggle it off then back on, (and vice-versa closed->open).

I would be happy with that. Multilevel Report mapping one-to-one with window coverings horizontal slats position, and Binary Switch "ON" to horizontal slats position 50% (or even better, to the iBlinds configuration parameter 4 "112-0-4 Default ON Value") and "OFF" to 0%.

OFF would be either 0% or 99% depending on whether Reverse Direction is true or false.

FEI, I can only group my Zooz switch with kitchen blind 1 which is a v3 motor. Blinds 2 and 3 are v3.1 and Z-Wave JS can't add a group to them. I can add a group between blinds 2 and 3 (which does not really do anything) but not with the Zooz switch...

[tommyjlong]

One problem I see with your logic is...what happens if the cover is closed via HA rather than the Illumino switch? Should that occur, the Illumino switch is still on but the blind is now closed and to open the blind via the switch requires the user to toggle it off then back on, (and vice-versa closed->open).

The way the Illumino switch works, the paddle always returns to the middle/neutral position after being pressed ON or OFF. If the switch itself is in the ON state (because the paddle was earlier pressed ON sometime prior), you can still press the paddle again for ON, and when you do it will still send another Binary Switch ON to the iBlinds.

Since the Illumino switch is a Z-Wave entity in HA, in addition to the group which gives you direct instant ON|OFF, why not simply use the Illumino switch entity's state in HA to trigger your automation to update HA's cover position???

Because of the behavior of the Illumino Switch just described, pressing its paddle ON when the Illumino switch is already ON will not result in an event in HA as HA does not see a state change.

To illustrate, my typical use case is to use the Illumino switch to open the blinds in the morning when I get up, and an HA automation to close the blinds when the sun goes down. So in general the Illumino switch is always ON.

[danielbrunt57]

it will still send another Binary Switch ON to the iBlinds

I've confirmed this is the way my Zooz ZEN76 works also. If Z-Wave JS would actually resend that repeated state to HA, I found a way for you to clear the state each time so that a repeated press will re-trigger in HA. It involves using python_script.set_state as follows:

alias: Test automation
description: ""
trigger:
  - platform: state
    entity_id:
      - switch.s2_on_off_switch
    to:
      - "on"
      - "off"
condition: []
action:
  - service: python_script.set_state
    data:
      entity_id: switch.s2_on_off_switch
      state: " "
mode: single

which clears the state of the switch in HA after it was set to on or off. I tested by using Dev Tools > Service and could repeatedly trigger the automation by repeatedly setting the state back to on(oroff`):

service: python_script.set_state
data:
  entity_id: switch.s2_on_off_switch
  state: 'on'

Unfortunately, the switch is re-sending the switch CC to the group but it does not send a report to its Lifeline unless the value changed. And the blind does not send a report to its Lifeline either when it gets the same CC state via the group association so I fail to see how ZWJS can sync anything since it's left clueless.
We're damned if if we do and damned if we don't!
:(

[danielbrunt57]

I've managed to get my Zooz switch and the blind working in sync at 0% and 50% tilt. I can press the switch on which opens the blind to 50% and the HA cover updates the blind tilt position. I can then execute cover.close_cover_tilt which turns the switch off enabling me to repeat the above sequence. The same works in reverse between 50% and 0%. Other tilt positions may break the automation. You will of course have to have this entity in HA despite not being able to control it:

alias: Test automation
description: ""
trigger:
  - platform: state
    entity_id:
      - light.kitchen_blind_1_31
    to: "off"
    id: "Off"
  - platform: state
    entity_id:
      - light.kitchen_blind_1_31
    to: "on"
    id: "On"
  - platform: state
    entity_id:
      - cover.kitchen_blind_1
    attribute: current_tilt_position
    id: Tilt
condition: []
action:
  - service: python_script.set_state
    data:
      entity_id: switch.s2_on_off_switch
      state: " "
    enabled: false
  - choose:
      - conditions:
          - condition: trigger
            id:
              - "Off"
        sequence:
          - service: cover.set_cover_tilt_position
            metadata: {}
            data:
              tilt_position: 0
            target:
              entity_id: cover.kitchen_blind_1
      - conditions:
          - condition: trigger
            id:
              - "On"
        sequence:
          - service: cover.set_cover_tilt_position
            metadata: {}
            data:
              tilt_position: 50
            target:
              entity_id: cover.kitchen_blind_1
      - conditions:
          - condition: trigger
            id:
              - Tilt
        sequence:
          - if:
              - condition: numeric_state
                entity_id: cover.kitchen_blind_1
                attribute: current_tilt_position
                above: -1
                below: 1
            then:
              - service: switch.turn_off
                metadata: {}
                data: {}
                target:
                  entity_id: switch.s2_on_off_switch
            enabled: true
          - if:
              - condition: numeric_state
                entity_id: cover.kitchen_blind_1
                attribute: current_tilt_position
                above: 49.9
                below: 51.1
            then:
              - service: switch.turn_on
                target:
                  entity_id:
                    - switch.s2_on_off_switch
                data: {}
            enabled: true
    enabled: true
mode: queued

[tommyjlong]

My preference would be (in the following order):

• When there is a change in position, have iBlinds report out to the Controller, against all the relevant CCs (WindowCover, MultiLevel, BinarySwitch). regardless of the source requesting a change. But this is outside scope of this thread
• ZWaveJS support Multilevel and BinarySwitch CC in a way that would still meet ZWave compliance, in order to support users that want to continue to use those CCs. Perhaps this can be done by supporting these CCs it discovers on the fly after the interview stages have completed or through some other means such as user configuration.
• ZWaveJS hide Multilevel and BinarySwitch CC completely including those it discovers on the fly but map their reports to WindowCover horizontal slats angle.

[AlCalzone]

Just to clear up some points:
Multilevel Switch CC MUST be hidden in favor of Window Covering CC due to certification requirements. There exists a 1:1 mapping though if the device only has a single window covering parameter (either position or tilt) - I'll have to implement this when I'm back from my parental leave.

Binary Switch CC is hidden because it causes confusion in the applications by showing additional controls that go out of sync with the Window Covering CC if the device only sends one of the reports. Unfortunately, we cannot easily map this, since Z-Wave JS doesn't implement device-specific behavior like SmartThings etc. did.
So to resolve this, the device would either have to send both Binary Switch CC and Window Covering CC reports when it is controlled via Binary Switch CC, or (preferably) only Window Covering CC.

Because of the behavior of the Illumino Switch just described, pressing its paddle ON when the Illumino switch is already ON will not result in an event in HA as HA does not see a state change.

Can you verify in the Z-Wave JS driver logs? I think the event is still sent to Z-Wave JS, but HA ignores value updates that don't change state.

[danielbrunt57]

Can you verify in the Z-Wave JS driver logs? I think the event is still sent to Z-Wave JS, but HA ignores value updates that don't change state.

My Zooz does NOT send a report if the switch has not changed. I only see a single event when the switch has changed:

2024-01-05T21:00:02.407Z CNTRLR   [Node 091] [~] [Binary Switch] currentValue: true => false        [Endpoint 0]
2024-01-05 13:00:02.408 INFO Z-WAVE: [Node 091] Value updated: 37-0-currentValue true => false
2024-01-05T21:00:02.411Z CNTRLR   [Node 091] [~] [Binary Switch] targetValue: true => false         [Endpoint 0]
2024-01-05 13:00:02.411 INFO Z-WAVE: [Node 091] Value updated: 37-0-targetValue true => false
2024-01-05T21:00:02.413Z CNTRLR   [Node 091] [~] [Binary Switch] duration: {"value":0,"unit":"secon [Endpoint 0]
                                  ds"} => {"value":0,"unit":"seconds"}
2024-01-05 13:00:02.414 INFO Z-WAVE: [Node 091] Value updated: 37-0-duration 0s => 0s
2024-01-05T21:00:02.416Z DRIVER « [Node 091] [REQ] [BridgeApplicationCommand]
                                  │ RSSI: -68 dBm
                                  └─[BinarySwitchCCReport]
                                      current value: false
                                      target value:  false
                                      duration:      0s

[danielbrunt57]

Binary Switch CC is hidden because it causes confusion in the applications by showing additional controls that go out of sync with the Window Covering CC if the device only sends one of the reports. Unfortunately, we cannot easily map this, since Z-Wave JS doesn't implement device-specific behavior like SmartThings etc. did.
So to resolve this, the device would either have to send both Binary Switch CC and Window Covering CC reports when it is controlled via Binary Switch CC, or (preferably) only Window Covering CC.

The blind does NOT send a Window Covering CC when the switch changes, only the Binary Switch CC,
nor does it send a Binary Swich CC when the cover changes, only the Window Covering CC

[danielbrunt57]

At one point, I though this momentary mode setting might be the answer but in Zooz firmware it is a toggle and pressing either paddle button toggles the switch off-on-off-on.

[tommyjlong]

Can you verify in the Z-Wave JS driver logs? I think the event is still sent to Z-Wave JS, but HA ignores value updates that don't change state.

Here is the log from just a single press of Ilumino switch to ON (Illumino switch state is already ON)
Illumino Switch is Node 28. I found no logs on this node. (I ran this a couple of times to be sure, but same result)
The 2 blinds (that the Illumino switch controls) are nodes 21 and 22:

2024-01-05T21:32:14.575Z CNTRLR   [Node 022] [translateValueEvent: value updated]
                                    commandClass: Binary Switch
                                    endpoint:     0
                                    property:     currentValue
                                    propertyKey:  undefined
                                    internal:     false
                                    secret:       false
                                    event source: undefined
2024-01-05T21:32:14.576Z CNTRLR   [Node 022] [~] [Binary Switch] currentValue: true => true         [Endpoint 0]
2024-01-05T21:32:14.576Z CNTRLR   [Node 022] [translateValueEvent: value updated]
                                    is root endpoint:        true
                                    is application CC:       true
                                    should hide root values: false
2024-01-05 16:32:14.577 INFO Z-WAVE: [Node 022] Value updated: 37-0-currentValue true => true
2024-01-05T21:32:14.578Z CNTRLR   [Node 022] [translateValueEvent: value updated]
                                    commandClass: Binary Switch
                                    endpoint:     0
                                    property:     targetValue
                                    propertyKey:  undefined
                                    internal:     false
                                    secret:       false
                                    event source: undefined
2024-01-05T21:32:14.579Z CNTRLR   [Node 022] [~] [Binary Switch] targetValue: true => true          [Endpoint 0]
2024-01-05T21:32:14.579Z CNTRLR   [Node 022] [translateValueEvent: value updated]
                                    is root endpoint:        true
                                    is application CC:       true
                                    should hide root values: false
2024-01-05 16:32:14.579 INFO Z-WAVE: [Node 022] Value updated: 37-0-targetValue true => true
2024-01-05T21:32:14.581Z CNTRLR   [Node 022] [translateValueEvent: value updated]
                                    commandClass: Binary Switch
                                    endpoint:     0
                                    property:     duration
                                    propertyKey:  undefined
                                    internal:     false
                                    secret:       false
                                    event source: undefined
2024-01-05T21:32:14.583Z CNTRLR   [Node 022] [~] [Binary Switch] duration: {"value":0,"unit":"secon [Endpoint 0]
                                  ds"} => {"value":0,"unit":"seconds"}
2024-01-05T21:32:14.583Z CNTRLR   [Node 022] [translateValueEvent: value updated]
                                    is root endpoint:        true
                                    is application CC:       true
                                    should hide root values: false
2024-01-05 16:32:14.583 INFO Z-WAVE: [Node 022] Value updated: 37-0-duration 0s => 0s
2024-01-05T21:32:14.584Z DRIVER « [Node 022] [REQ] [ApplicationCommand]
                                  └─[BinarySwitchCCReport]
                                      current value: true
                                      target value:  true
                                      duration:      0s
2024-01-05T21:32:15.519Z SERIAL « 0x010d00040015052503ffff00c70007                                    (15 bytes)
2024-01-05T21:32:15.521Z SERIAL » [ACK]                                                                   (0x06)
2024-01-05T21:32:15.522Z CNTRLR   [Node 021] [translateValueEvent: value updated]
                                    commandClass: Binary Switch
                                    endpoint:     0
                                    property:     currentValue
                                    propertyKey:  undefined
                                    internal:     false
                                    secret:       false
                                    event source: undefined
2024-01-05T21:32:15.523Z CNTRLR   [Node 021] [~] [Binary Switch] currentValue: true => true         [Endpoint 0]
2024-01-05T21:32:15.524Z CNTRLR   [Node 021] [translateValueEvent: value updated]
                                    is root endpoint:        true
                                    is application CC:       true
                                    should hide root values: false
2024-01-05 16:32:15.524 INFO Z-WAVE: [Node 021] Value updated: 37-0-currentValue true => true
2024-01-05T21:32:15.524Z CNTRLR   [Node 021] [translateValueEvent: value updated]
                                    commandClass: Binary Switch
                                    endpoint:     0
                                    property:     targetValue
                                    propertyKey:  undefined
                                    internal:     false
                                    secret:       false
                                    event source: undefined
2024-01-05T21:32:15.525Z CNTRLR   [Node 021] [~] [Binary Switch] targetValue: true => true          [Endpoint 0]
2024-01-05T21:32:15.525Z CNTRLR   [Node 021] [translateValueEvent: value updated]
                                    is root endpoint:        true
                                    is application CC:       true
                                    should hide root values: false
2024-01-05 16:32:15.525 INFO Z-WAVE: [Node 021] Value updated: 37-0-targetValue true => true
2024-01-05T21:32:15.525Z CNTRLR   [Node 021] [translateValueEvent: value updated]
                                    commandClass: Binary Switch
                                    endpoint:     0
                                    property:     duration
                                    propertyKey:  undefined
                                    internal:     false
                                    secret:       false
                                    event source: undefined
2024-01-05T21:32:15.525Z CNTRLR   [Node 021] [~] [Binary Switch] duration: {"value":0,"unit":"secon [Endpoint 0]
                                  ds"} => {"value":0,"unit":"seconds"}
2024-01-05T21:32:15.525Z CNTRLR   [Node 021] [translateValueEvent: value updated]
                                    is root endpoint:        true
                                    is application CC:       true
                                    should hide root values: false
2024-01-05 16:32:15.526 INFO Z-WAVE: [Node 021] Value updated: 37-0-duration 0s => 0s
2024-01-05T21:32:15.526Z DRIVER « [Node 021] [REQ] [ApplicationCommand]
                                  └─[BinarySwitchCCReport]
                                      current value: true
                                      target value:  true
                                      duration:      0s

[tommyjlong]

So to resolve this, the device would either have to send both Binary Switch CC and Window Covering CC reports when it is controlled via Binary Switch CC, or (preferably) only Window Covering CC.

Yes this is why I made this my most preferred solution.
I ask iBlinds a couple of years ago (when only Multilevel and Binary Switch CCs were in play) about reporting out both CCs when triggered by only one of the CCs, and they were kind enough to respond saying they would look into it, but also said they meet the Zwave standards by only reporting on the CC that made the set request.

[danielbrunt57]

I ask iBlinds a couple of years ago (when only Multilevel and Binary Switch CCs were in play) about reporting out both CCs when triggered by only one of the CCs, and they were kind enough to respond saying they would look into it, but also said they meet the Zwave standards by only reporting on the CC that made the set request.

and I think you now have your answer - "not possible"/"not going to do that".

If you want HA to stay in sync with the blind position, instruct the user to go to the blind and briefly press the button(s) on the blind(s) header (which still has a delay), or use the Illumino switch and have HA control the blind with the more noticeable delay.

iBlinds is better than having to go each blind and pull cords mutiple times a day!!
I have mine automated to open at sunrise, close at sunset with the kitchen (3 blinds: 1 South East, 1 South, 1 South West) adjusting tilt based on sun altitude & azimuth, outside brightness and outside temp: warm days tilt to block sunlight and cooler days (like now) tilt for maximum sunlight.

[tommyjlong]

I've come up with a solution that works for me (apologies for not coming up with this sooner).

After studying the Illumino Switch some more, I found a way to use its Central Scene capability to where a 1-tap of the paddle to ON causes both a BinarySwitch CC ON to be sent to the iBlinds, and an "ON" Scene to be sent to ZWaveJS/HA. Similarly for OFF.
I can now use the Central Scene in an HA Automation to request ZWaveJS to do a Windows Covering refresh for the Horizontal Slats Angle value, and this will also update the slat position in HA.

go to the blind and briefly press the button(s) on the blind(s) header (which still has a delay)

I tested that on my iBlind and see that it causes ZWaveJS to auto-create a Multilevel entity. The Windows Covering Horiz Slats position is not updated, so a fix that uses a 1:1 mapping would help this out. I would just add that I myself don't particularly need the 1:1 mapping fix, but others might.

my parental leave.

Congrats!

[danielbrunt57]

I found a way to use its Central Scene capability to where a 1-tap of the paddle to ON causes both a BinarySwitch CC ON to be sent to the iBlinds, and an "ON" Scene to be sent to ZWaveJS/HA. Similarly for OFF.
I can now use the Central Scene in an HA Automation to request ZWaveJS to do a Windows Covering refresh for the Horizontal Slats Angle value, and this will also update the slat position in HA.

Thanks!
Here's my automation to accomplish your solution:

alias: Zooz Switch - Control Kitchen Blind 1
description: ""
trigger:
  - platform: state
    entity_id:
      - event.s2_on_off_switch_scene_001
    id: "On"
  - platform: state
    entity_id:
      - event.s2_on_off_switch_scene_002
    id: "Off"
condition: []
action:
  - choose:
      - conditions:
          - condition: trigger
            id:
              - "Off"
          - condition: state
            entity_id: event.s2_on_off_switch_scene_001
            attribute: event_type
            state: KeyPressed
        sequence:
          - service: cover.set_cover_tilt_position
            metadata: {}
            data:
              tilt_position: 0
            target:
              entity_id: cover.kitchen_blind_1
      - conditions:
          - condition: trigger
            id:
              - "On"
          - condition: state
            entity_id: event.s2_on_off_switch_scene_002
            attribute: event_type
            state: KeyPressed
        sequence:
          - service: cover.set_cover_tilt_position
            metadata: {}
            data:
              tilt_position: "{{ states('number.kitchen_blind_1_default_on_value') }}"
            target:
              entity_id: cover.kitchen_blind_1
            enabled: true
    enabled: true
mode: queued

[AlCalzone]

[...] but also said they meet the Zwave standards by only reporting on the CC that made the set request.

I'm not entirely sure this is necessary when the lifeline destination is NOT the one that issued the command. The specifications have an example where this is not the case - but they use Basic CC, so this might be an exception to the rule:

[danielbrunt57]

I really have virtually zero knowledge of ZWave standards but if I am following figure 7.1 correctly, it's only showing an example of the frame flow following a Multicast Basic Set(0xFF) from Node A (multicast meaning all nodes?) and I would surmise that in the case of the controller (call it Node A) issuing a non-multicast Basic Set to the iBlinds Node that this flow logic totally does not apply, or am I just out-to-lunch?

[AlCalzone]

Multicast is a select list of destinations. Broadcast would be all nodes. I really don't know why they chose multicast for the example. Maybe because that doesn't allow a report back to the controlling node.

Anyways I don't understand the specs in a way that forbid sending a multilevel switch or window covering report to the lifeline destination, when a different node used Binary Switch to control. Maybe it's required somewhere else, but AFAIK only the report back to the controlling node must be the same CC as the controlling command.

[danielbrunt57]

It can send unsolicited battery level reports, correct? They why not Basic CC?? What if the device has local dimming and local switch capability?? It has to be able to send them, right? So why should a window covering which may or may not have local control capability be any different? "Hey, you told me to change the tilt to 0% and I confirm I've done it. By the way someone changed the switch postion here. It is now off." and vice-versa "Hey, you told me to change the switch to on and I confirm I've done it. By the way someone changed the tilt postion here. It is now 50%." Someone's design is asinine! It all makes zero sense. I think somebody was out to lunch when brains/logic were being handed out! If they had done what was right and necessary and failed Z-Wave certification after stating their case logically then the Z-Wave Allaince was out to lunch.

"Anyways I don't understand the specs in a way that forbid sending a multilevel switch or window covering report to the lifeline destination, when a different node used Binary Switch to control"
Like I already stated, what if there was local control physically within the device for binary switch or multilevel switch/window covering? Who's to say it was physically locally controlled or not? (the "not" being a result of what you told me do with that other class)

I think the programmers for iBlinds were out to lunch and just plain forgot they they should sync binary switch with multilevel and and are now pointing their finger at the zwave certification specs (which they probably don't fully understand) and are hoping that everyone just believe them.

< end of rant >

[danielbrunt57]

I've retired all but the last of my 6 original iBlinds motors (the first was from their Indiegogo kickstarter 5 years ago) and have upgraded to v3 motors. The first v3 was a test over a year ago and can only run FW "3.8" as it is Z-Wave chip hardware version 1. It has never hiccupped like the old ones were constantly doing so I started upgrading the other five about 6 months ago. The new ones are FW "3.12" and Z-Wave chip hardware version 2.