Battery powered Z-wave devices stuck in "Initializing (Cache)" state when restarting HA

Configuration Z-Wave
1

Hi all.

I noticed that every time I restart HA, all the battery-powered Z-wave devices I have are stuck in “Initializing (Cache)” mode.
For some of them, I have to manually wake them up or press their zwave button, and the status proceeds to the right one (Complete, then sleeping), but for others I have to re-bring the z-wave device close to the hub (in my case, a Aeotec stick) and wake them up.
Sometimes not even this works.

Is there a way to solve this problem, without physically interacting with the battery powered Z-wave sensor, but remotely?

Thanks

2

Just wait. It can take a couple hours for them to go complete. The devices are still working, they just don’t report back to the gateway immediately. I have a motion detector and 4 door sensors that are battery powered and they go from Initializing to Sleeping once they wake up and report back to the gateway without me interacting with them.

1 Like
3

Thanks squirtbrnr.
Unfortunately that does not seem to solve the issue, as for some of them I have waited more than 24h, without any change…

Has this ever happened to you?

4

Do they still work in that state?

If a motion detector senses motion does it successfully send the signal?

If it does then I’m not sure why you would worry about it. I have a couple of zwave devices that go to that state but I’ve never had an issue with them actually working when needed. eventually they show complete.

5

I tried - not they do not work. I have a flood sensor by Foxx and it does not signal anymore if I restart.

There must be a way to force them to relink.

6

Do you have any mains powered zwave devices?

Maybe your zwave network isn’t powerful enough to reach all of your battery powered stuff.

I bought a zwave outlet just so I would have at least one mains powered repeater device to improve network performance.

Saying you need to bring the device closer to the z stick to get them to finally work tells me that might be it.

1 Like
7

Thanks, finity. I changed the battery with a brand new one, and now at least the sensor is communicating with the controller.

Nonetheless, I have a combustible gas sensor pretty close (~2m), but that does not see the battery-powered sensor as neighbour. Could it be that a z-wave plus device does not see as neighbour a normal Z-Wave device?

In the same room I also have a z-wave extender, this one not Z-Wave plus, but normal Z-Wave, and not even this one see the battery-powered sensor as a neighbour.

Is it normal?

8

i’m not that knowledgeable at the specifics of the zwave protocol.

i’m sorry i can’t be more help at this point

9

I had to add the neighbors manually for one of my battery powered our sensors, I copied the neighbors bit of another and just amended the numbers to the devices that were close.

10

I have two Aeotec wallmote ZW129 switches and I have the exact same issue. It seems that when HASS is restarted these two battery devices stay in Initializing (CacheLoad) mode. In order to complete I need to wake up both manually. Even though they stuck at initializing the devices work just perfect since the associations are saved on the device.

The only neighbor that it is found by these two is the Aeotec ZWA001 LED Bulb 6 Multi-White which is correct(it is in the same room)

It seems that in general the battery devices do not wake up automatically unless you set a timer,which for these two devices I have is not set in order to save the battery.

Any one has any other idea fore for this since if the wallmote devices might work OK but I will never now the exact battery available .

11

Hi All

I have the same issue, after restart i have to manually trigger the sensor, then it shows Sleeping.

Anyone have a fix, like automation trigger, or config trigger?

12

There’s nothing to fix, this is how they are supposed to operate.

13

I suppose he means that after a reboot the battery powered devices just don’t show up.
After manually triggering them (pushing the button inside) they start to appear.
At least, that’s the case for me.

14

As mentioned already, “Initializing (Cache)” state is quite normal for battery devices after the Z-Wave network has started. They will not go to “Sleeping” until they send a wake-up notification to the controller. The wake up time varies, default is every hour, I set most of mine to once a day. Some devices will never wake up unless you physically tell them to, I have an Aeon Minimote and a First Alert fire alarm that are always initializing, yet they work as normal.

I suppose he means that after a reboot the battery powered devices just don’t show up.
After manually triggering them (pushing the button inside) they start to appear.
At least, that’s the case for me.

This sounds like a different problem. Are you actually rebooting your entire system without stopping HA, or are you restarting/rebooting from the HA UI?

15

I’m rebooting from the UI.
However, I should say that problems starting occurring mostly after switching from a pi to a NUC.
Rebooting the whole container from the portainer interface does help though.

16

I am fairly new to HA and Z-Wave. Want to make sure I understand the limitations here…

I have some battery powered Z-wave devices, in particular a door sensor. It seems to report it’s status fine. I have a template_binary_sensor that looks for access_control==22. But if I reboot HA, the access_control always shows as 254, whether the door is open or closed, presumably because the device is sleeping? I also get errors like the following in the home-assistant.log:

[homeassistant.components.sensor.template] Could not render icon template zwave_cooking_area_door_battery, the state is unknown.

If I then physically change the state of the sensor it sends it’s correct status which is good. But is there any way to get the current state of the device programatically without forcing a state change? I guess this is only an issue after an HA restart.

17

The state will only update when the sensor reports while they are sleeping there’s no way to pull the status until the device wakes up from sleep mode. The range can be from 5mins to 24-48 hours depending on the device and configuration.

Basically for all battery operated sensors, you wait till they update, you can’t force it programatically.

18

Or you can try to change the entity that you are getting the report from. Instead of using the access control sensor you should try to use a binary sensor or something from the device that more accurately reports the state of the desired monitored condition. A binary sensor should always report the correct state even if the device is sleeping or in the inilializing state.

19

Battery powered devices should have a value called Wake Up Interval. This specified how often the device wakes up and checks in with the controller. You can adjust that value. As others have mentioned some devices set the wake up interval to 0 meaning it has to be woken up manually (via some button press etc. should be documented in the manual)

A word of warning. Setting the wake up interval to a low value will kill the batteries quickly.

1 Like
20

I wanted to try a template sensor with 3 states to cover this situation, where the third state would be “unknown”. I used the template sensor code below. When I do this, the icon for this sensor up in the top row of the UI just shows the word “on” of “off” or a “-” (for unknown). If I click on that, I do see the correct icon in the info pane. So my question is how to make the icon shown in the top row of the UI to reflect my customized icon from the icon_template?

- platform: template
  sensors:
    zwave_cooking_area_door:
        friendly_name: Cooking Area Door
        value_template: >
          {% if is_state('sensor.vision_zd2105us_5_recessed_door_window_sensor_access_control', '22') %}
          on
          {% elif is_state('sensor.vision_zd2105us_5_recessed_door_window_sensor_access_control', '23') %}
          off
          {% else %}
          unknown
          {% endif %}
        icon_template: >
          {% if states('sensor.zwave_cooking_area_door') == 'on' %}
          mdi:door-open
          {% elif states('sensor.zwave_cooking_area_door') == 'off' %}
          mdi:door-closed
          {% else %}
          mdi:help
          {% endif %}