Automations slow to respond... possible solutions? hardware improvements?

I have times where my automations will be quite slow to respond… something as simple as a contact sensor that turns on a light… I open the door and it can sometimes take up to 10 seconds for the light to turn on… both of the devices in this automation are zwave connected directly to HA.

I have done zwave repair and that doesn’t seem to help. The slowness is intermittent… most of the time automations are immediate as they should be, but when it is running slow it is frustrating…

I only have around 30 zwave devices.

I THINK my main hangup is probably the fact that I’m running HA in a VM inside ESXI server and the whole thing is sitting on an HDD. I’m contemplating moving this setup over to SSD. I know this will improve system speeds overall, but is there really a lot of read/write that occurs for automations? Would HA see a significant speed improvement by moving to SSD?

The VM is Ubuntu server with 1 3.5 GHz CPU and 4GB of RAM. This seems to be more than enough. From watching system resources, HA uses very few resources… I’m thinking my only bottlenecks could be the HDD and the Zwave stick, but I can’t imagine the stick being the issue as it is supposed to be capable of supporting far more devices.

I’m just curious if anyone has run into similar issues of HA being slow at times, and what you’ve done to resolve it? Bonus points if anyone has been in a similar scenario as me with a home server.

Before you do any change, try some other, easier things.
First of all, is everything on wifi? zwaves are on wifi connection i think, right?
Can you trigger the zwaves manually? Not through HA, just manually, from your mobile or their app, if any.
If the response is also slow, then it could be something on your wifi.

Are other automations (not zwaves - just others… like a notification) slow? Can you trigger some of them manually from HA and see how long they respond?

Try to find what is wrong with your system or network before you do a change, because it can be useless or painful.
Feel free to ask anything.
Cheers.

Im running ha in a ubuntu VM inside ESXi also. Also have a zwave stick plugged in and use it for lighting automations.

Most of the time my garage light is on before I can get the door fully open. Generally, things respond as if they were hard wired.

That being said I have a small network with most sensors connecting directly to the hub.

Have you looked at how many hops some of the slow to respond sensors have to make?

Details of my setup are here:

Wifi and zwave are two different protocols working on two different frequencies for communication.

This would be a good test. Next time its slow to respond, try to manually trigger the automation. This would tell you if its the zwave network that is slow or the automation.

Also, your HDD is likey alot faster than the SD card in a pi and a pi can run a lot of automation without issue. I wouldn’t focus to hard on the HDD unless it is possibly having health issues. Check the SMART data.

1 Like

No, zwave is not wifi, that’s why I assumed it would be the more reliable test. My wifi and zigbee devices can be slow at times, but that’s most likely due to interference from neighboring signals.

Since they are zwave devices connected directly to HA, that is the only way to trigger the devices.

A simple notification would be a good test. I could setup a button to generate a notification from an automation. Thanks for the idea! I’ll give that a try and see if there is any delay.

1 Like

That is part of my concern as well. I think some of my zwave devices might have to make a lot of hops.

Is there an easy way to check the network map for zwave? I’m not aware of how to do this.

Also, if I do find any nodes that have to make a lot of hops back to the main controller, what’s the best solution for this?

Lastly, are you on HDD or SSD? For my own curiosity.

Here is one option. Do a search on the forum for more options.

I think ‘healing’ the network can help with this. Not 100% sure on that though. Location can be a limiter and distance between nodes.

SSD.

This is an easier to get installed z-wave mesh network graph:

Network healing should occur every night by default. So it is unlikely to help without relocating or adding a few devices.

The other thing to check is your OZW log (bottom of the integrations page). It’s a pain to read but may show a sensor is spamming the network and slowing everything down.

On a small network with 6 devices mostly connected directly to the zstick in a raspberry pi I never got switching latency lower than 3-4 seconds. I’ve since moved to wifi devices and find the latency less than a second.

I’m getting this too. Some of my scripts/automations will take a full 90 seconds to run through. I’m running in 4gb of RAM, on an SSD. One of the scripts in question is this:

movie_time:
  alias: Movie Time 
  sequence:
    - service: light.turn_off
      data: 
        entity_id: group.all_lights
    - service: light.turn_on
      data:
        entity_id: light.living_room_light
        brightness: 2
    - service: light.turn_on
      data:
        entity_id: light.bathroom1
        brightness: 2
    - service: light.turn_on
      data:
        entity_id: light.bathroom2
        brightness: 2

It SHOULD be simple right? I have about 8 bulbs to turn off, and they all turn off in serial, then come back on in order.

Note: since the actions happen in sequence (do, wait for ack, do, wait etc…), you’ll never be able to do this faster than the network can communicate. If a packet is lost, you’ll be waiting for that timeout before proceeding. The speed of the server won’t (shouldn’t) affect this … :P.

I’ve had a little bit of success with using groups of devices, (in my case, the all lights group)… it seems it happens in parallel in that case.

It’s likely that group.all_lights takes some time to complete depending on how your lights communicate and how many.

You can also have multiple entities in the turn on call which not sure if it will help or not. I believe it just loops over the list of entities. But it’s cleaner code.

   - service: light.turn_on
      data:
        entity_id: 
         - light.living_room_light
         - light.bathroom1
         - light.bathroom2
        brightness: 2

@eric10k93 - sorry for reviving, but I just passed this thread for other reasons… But have you tried associations?

In z-wave, as I understand it, whenever a device changes state or a button is pressed, it communicates on an “association group N” (where N is some number). In the case of a button, it typically sends out a “BASIC SET” command on the association group its configured for. Most (if not all) z-wave lights will likewise be controlled by these BASIC SET commands (which is what HA actually sends).

If you associated the button, and a light (or more lights), the BASIC SET will go “directly” (mesh network and all) from the switch to the lights in question. HA won’t play a role.

I have no z-wave lights (yet), so I can’t try it out. I have zigbee lights and z-wave switches, so I’m a bit behind … yet… :slight_smile:

I honestly am not super familiar with the inner workings of Zwave tech, so I can’t say I have looked into this. Everything has been running much smoother for me since I moved everything to an SSD.

I also have a mixture of Zwave, Zigbee, and wifi in most cases… So there are few instances where I could test a direct Zwave connection.

For anyone who finds this issue. And is running into slow response times from their automation. It is due to the fact that the current integration uses cloud polling. The device provides MQTT option, which would provide a more robust and quicker response time, however that doesn’t seem to be implemented by the current integration which is unfortunate.

There are two options I am exploring:

  • Using HomeKit integration which would operate locally and close to real-time.
  • Using Matter integration which would operate locally and close to real-time as well.

Nick