HA Slow to update Homeseer Status Lights

Hey all,

Transitioning from a HomeSeer hub to HA. I’ve got HA running, but some things are slower than it was on HomeSeer. Specifically, I have several HS 200+/300+ switches where I use status lights. My hub is a Zooz ZST39 (800 series). On ZWaveJS, devices have a good ping time, almost all between 50-75ms, and most devices directly connected to the hub. All devices are S2 security, “No Security”, and one device (a garage door controller) is S0 Legacy. All devices are ZWave+. There are NO 700 series chips in the network, everything is 500 or 800 chips. When updating the status lights, HA is VERY slow to get them updated and returned. HS updated nearly instantly. Here is an example of my YAML.

This section of code increments a counter, reads the lock and door states, delays 2 seconds, checks the counter, then sends an update to the desired switches. The update is extremely slow, taking more than 20 seconds between when the first switch changes and the last switch changes. I’ve tried moving things to parallel execution, changing logic, changing to multicast, etc. but it is still pretty slow. The trace indicates the logic runs in 0 seconds, the delay is 2 seconds, getting to the ZWave set is 0 seconds, while the whole thing takes around 8-9 seconds (2 of those seconds are expected). Would appreciate thoughts to improving the response time for this.

TIA,
Jason

alias: "Front Door: Update"
description: ""
trigger:
  - platform: state
    entity_id:
      - input_select.front_door_battery
      - input_select.front_door_lock_state
      - input_select.front_door_state
condition: []
action:
  - service: counter.increment
    data: {}
    target:
      entity_id: counter.status_light_front_door_execution_count
  - if:
      - condition: state
        entity_id: input_select.front_door_state
        state: Open
      - condition: state
        entity_id: input_select.front_door_lock_state
        state: Unlocked
    then:
      - service: input_number.set_value
        data:
          value: 5
        target:
          entity_id: input_number.front_door_color
      - service: input_boolean.turn_on
        data: {}
        target:
          entity_id: input_boolean.status_light_7_flash
  - if:
      - condition: state
        entity_id: input_select.front_door_state
        state: Open
      - condition: state
        entity_id: input_select.front_door_lock_state
        state: Locked
    then:
      - service: input_number.set_value
        data:
          value: 1
        target:
          entity_id: input_number.front_door_color
      - service: input_boolean.turn_on
        data: {}
        target:
          entity_id: input_boolean.status_light_7_flash
  - if:
      - condition: state
        entity_id: input_select.front_door_state
        state: Closed
      - condition: state
        entity_id: input_select.front_door_lock_state
        state: Unlocked
    then:
      - service: input_number.set_value
        data:
          value: 2
        target:
          entity_id: input_number.front_door_color
      - service: input_boolean.turn_on
        data: {}
        target:
          entity_id: input_boolean.status_light_7_flash
  - if:
      - condition: state
        entity_id: input_select.front_door_state
        state: Closed
      - condition: state
        entity_id: input_select.front_door_lock_state
        state: Locked
    then:
      - service: input_number.set_value
        data:
          value: 2
        target:
          entity_id: input_number.front_door_color
      - service: input_boolean.turn_off
        data: {}
        target:
          entity_id: input_boolean.status_light_7_flash
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
  - service: counter.decrement
    data: {}
    target:
      entity_id: counter.status_light_front_door_execution_count
  - if:
      - condition: numeric_state
        entity_id: counter.status_light_front_door_execution_count
        below: 1
    then:
      - parallel:
          - service: zwave_js.multicast_set_value
            target:
              entity_id:
                - light.porch_lights
                - light.den_fan_lights
                - switch.office_lights
                - light.stairs
                - light.main_recessed_kitchen
                - light.master_bedroom
                - light.island_lights
            data:
              property: "27"
              command_class: "112"
              value: "{{ states('input_number.front_door_color') }}"
          - service: zwave_js.multicast_set_value
            target:
              entity_id:
                - light.porch_lights
                - light.den_fan_lights
                - switch.office_lights
                - light.stairs
                - light.main_recessed_kitchen
                - light.master_bedroom
                - light.island_lights
            data:
              property: "31"
              command_class: "112"
              value: >
                {% set led1_blink = states('input_boolean.status_light_1_flash')
                %}  {% set led2_blink =
                states('input_boolean.status_light_2_flash') %}  {% set
                led3_blink = states('input_boolean.status_light_3_flash') %}  {%
                set led4_blink = states('input_boolean.status_light_4_flash')
                %}  {% set led5_blink =
                states('input_boolean.status_light_5_flash') %}  {% set
                led6_blink = states('input_boolean.status_light_6_flash') %}  {%
                set led7_blink = states('input_boolean.status_light_7_flash')
                %}  {{(led1_blink == 'on') | int * 1 + (led2_blink == 'on') |
                int * 2 + (led3_blink == 'on') | int * 4 + (led4_blink == 'on')
                | int * 8 + (led5_blink == 'on') | int * 16 + (led6_blink ==
                'on') | int * 32 + (led7_blink == 'on') | int * 64 }}
          - service: zwave_js.multicast_set_value
            target:
              entity_id:
                - light.porch_lights
                - light.den_fan_lights
                - switch.office_lights
                - light.stairs
                - light.main_recessed_kitchen
                - light.master_bedroom
                - light.island_lights
            data:
              property: "30"
              command_class: "112"
              value: 5
mode: parallel
max: 10

You’ll need to capture a zwavejsui debug log file. It will show all the zwave messages going back and forth between the controller and may provide insite as to why this is taking so long.

Thank you for the suggestion. I took a look and here is what I found:

  1. This section seems to be repeating a lot. Not sure if it is a problem:
2023-07-04 11:54:07.285 INFO MQTT: MQTT client reconnecting
2023-07-04 11:54:07.286 ERROR MQTT: Mqtt client error getaddrinfo ENOTFOUND core-mosquitto
Error: getaddrinfo ENOTFOUND core-mosquitto
at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:107:26)
2023-07-04 11:54:07.293 INFO MQTT: MQTT client closed
2023-07-04 11:54:10.293 INFO MQTT: MQTT client reconnecting
2023-07-04 11:54:13.692 ERROR MQTT: Mqtt client error getaddrinfo ENOTFOUND core-mosquitto
Error: getaddrinfo ENOTFOUND core-mosquitto
at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:107:26)
2023-07-04 11:54:13.707 INFO MQTT: MQTT client closed

Dr. Google didn’t really turn much up on this issue. One thing it suggested was adding localhost to the /etc/hosts file. I checked and it is in there. I’m also running HassOS as a VM on Proxmox (HomeSeer was also running as a VM on Proxmox going out the same path). Other automations don’t seem to have speed issues (such as scene processing to other switches).

  1. I’m also getting this error. This happened just before the zwave signal went out. Again, not sure if it is related or a problem in my code. If it is my code, might be an issue with a type conversion:
2023-07-04 11:54:36.366 ERROR APP: Unhandled Rejection, reason: TypeError: Cannot read properties of undefined (reading 'call')
2023-07-04 11:54:36.370 ERROR APP: Unhandled Rejection, reason: TypeError: Cannot read properties of undefined (reading 'call')
2023-07-04 11:54:36.373 ERROR APP: Unhandled Rejection, reason: TypeError: Cannot read properties of undefined (reading 'call')

  1. This seems to be the section where the parameter update went out.
2023-07-04 11:54:38.487 INFO Z-WAVE: [Node 031] Value updated: 112-0-27 2 => 2
2023-07-04 11:54:38.488 INFO Z-WAVE: [Node 056] Value updated: 112-0-27 2 => 2
2023-07-04 11:54:38.489 INFO Z-WAVE: [Node 023] Value updated: 112-0-27 2 => 2
2023-07-04 11:54:38.490 INFO Z-WAVE: [Node 020] Value updated: 112-0-27 2 => 2
2023-07-04 11:54:38.491 INFO Z-WAVE: [Node 016] Value updated: 112-0-27 2 => 2
2023-07-04 11:54:38.491 INFO Z-WAVE: [Node 025] Value updated: 112-0-27 2 => 2
2023-07-04 11:54:38.794 INFO MQTT: MQTT client reconnecting
2023-07-04 11:54:40.630 INFO Z-WAVE: [Node 031] Value updated: 112-0-31 127 => 63
2023-07-04 11:54:40.631 INFO Z-WAVE: [Node 056] Value updated: 112-0-31 127 => 63
2023-07-04 11:54:40.632 INFO Z-WAVE: [Node 023] Value updated: 112-0-31 127 => 63
2023-07-04 11:54:40.632 INFO Z-WAVE: [Node 020] Value updated: 112-0-31 127 => 63
2023-07-04 11:54:40.633 INFO Z-WAVE: [Node 016] Value updated: 112-0-31 127 => 63
2023-07-04 11:54:40.634 INFO Z-WAVE: [Node 025] Value updated: 112-0-31 127 => 63
2023-07-04T15:54:40.808Z CNTRLR [Node 031] failed to decode the message, retrying with SPAN extension...
2023-07-04 11:54:42.292 INFO Z-WAVE: [Node 031] Value updated: 112-0-30 5 => 5
2023-07-04 11:54:42.293 INFO Z-WAVE: [Node 056] Value updated: 112-0-30 5 => 5
2023-07-04 11:54:42.294 INFO Z-WAVE: [Node 023] Value updated: 112-0-30 5 => 5
2023-07-04 11:54:42.294 INFO Z-WAVE: [Node 020] Value updated: 112-0-30 5 => 5
2023-07-04 11:54:42.295 INFO Z-WAVE: [Node 016] Value updated: 112-0-30 5 => 5
2023-07-04 11:54:42.295 INFO Z-WAVE: [Node 025] Value updated: 112-0-30 5 => 5
2023-07-04 11:54:42.526 ERROR MQTT: Mqtt client error getaddrinfo ENOTFOUND core-mosquitto
Error: getaddrinfo ENOTFOUND core-mosquitto
at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:107:26)
2023-07-04 11:54:42.533 INFO MQTT: MQTT client closed
2023-07-04 11:54:44.663 INFO APP: GET /health/zwave 200 0.641 ms - 2140

Looks like 2 seconds between calls. Three calls plus the 2 second self-inflicted delay does add to 8 seconds total, so I see where the 8 second runtime is coming from, but that still doesn’t account for the long delay before the switch updates. When I set the config parameters using the same HS routine or to just one node from within the ZWaveJS control panel, there is excellent sub-one second response time.

First. Is ZWaveJS and HA up to date? Reason I ask is latest added support for exposing ZWave configuration classes through the UI as entities instead of zwavejs set configure variable calls. (which may be the root of your delay)

If your switches setup the way I think they do you should be able to just send the correct command. Have you checked one of those 200+ switches to see if yiu have a bunch of disabled entities representing your indicator leds?

HA is up-to-date; ZWaveJS was at 1.3.4 and updated to 1.4. Both have the same issue. Concur with the possibility of the set calls being a delay, but I wouldn’t know how to reference this another way (sorry, still stuck thinking in HS instead of HA and don’t know how to do lots yet).

On the disabled entities, assuming I would go to Settings → Devices & Services → Entities, then I just checked. I do not see any entities representing indicator LEDs in there. If there is another place to look for that, let me know.

May be a Zwave JS_UI thing. Here’s what you’ll see if you have it: (This is after ive enabled the entities for a Zooz Zen 32 - but similar concept)

Im pretty sure the delay is due to how you’re making the service calls (but I haven’t dug in enough to determine alternatives yet) Seeing as you made it this far - look up ‘zwave bulk set partial config parameters’

Your other option may be ZwaveJS_UI if that’s what’s bringing the alt entities to the table. (I think it’s part of core ZwaveJS too - but again haven’t dug into how to make sure you have that yet) I used to have all manner of hell setting the indicator lights on my Zen32s. When this became available for me this last build of HA - I switched over to using this method and haven’t looked back - Im sure someone like freshcoast could tell me whats going on under the hood but for certain it’s WAY more responsive.

I did (finally) find what you were referencing with respect to the “disabled” entities. You were correct, the entities are disabled in the configuration for the switches. I’m still thinking if going through the API for the indicator LEDs will be better than going direct. I may clone the YAML and rewrite it to reference the entities to see if there is an improvement. Do you know if there is an “easy” way to enable them? There are “a few” switches with disabled entities that will need to be enabled. :wink:

I’m still thinking you’re right about the calls, though. While I’m fine working with entities, there is a computed component missing that I would prefer to use. Maybe that’s just part of the thinking in moving from HS to HA. But I’m still thinking the whole thing goes into a queue somewhere and broadcast one-at-a-time, which is why it is taking so long. I’m wondering about using the “Broadcast” switch on the multicast to see if that might improve things, but I’m not sure how to use it and what its intended effect is. Might just try it to see if there’s an improvement.

Try it before you make a decision.

You’re in a new platform and you don’t know what the platform is doing for you under the hood. I compute a bunch of values before I set my indicators too. But the new method (using the entity instead of roll my own calls) was orders of magnitude faster.