GE Z-wave dimmer not updating status

Configuration
1

Hey all, problem child here. :slight_smile:

So while working through my issue for turning the light off after being < x brightness for y minutes I found another problem. The GE z-wave dimmer I have isn’t updating it’s status really at all (or VERY slowly). The light has been off for 15+ minutes now (yes minutes!), but it’s still showing on in HASS. I know there is a minor delay because it’s not a “plus” device but this has been excessive. Anything I can tweak to help resolve this? This if my only dimmer, the regular switches update in seconds. Relevant config:

zwave:
    usb_path: /dev/ttyACM0

customize:
    light.light.dining_room_light_level_11_0:
      friendly_name: Dining Room Light
      scan_interval: 10

Am I missing something obvious? Thanks so much!

2

That’s because the dimmer is on but it has no voltage going to it. Click on the light name in the panel on HA, it will expand and show you a dimmer slider bar. Your bar will be all the way to the left, meaning off. This is how dimmers work in HA ui. If you click off from the UI, it lowers the slider to 0. If you click it again, it will turn off the switch. If you click it again, it will turn on the switch at 0 percent. Then you adjust the slider. Its a pain in the ass to be honest. I’m pretty sure there is a thread that discusses ways to get around this, I personally haven’t dealt with it because I don’t use the UI to turn things on and off.

1 Like
3

Oh now that’s annoying… So what happens with the automation then? Does a light.off do both flip the switch and move the slider all the way to the left?

4

In the automations you specify the brightness of the light when it turns on.

5

If you haven’t already, it could be worth exploring the settings in ozwcp. If you installed on RPi with AiO here are the ozwcp notes. I have several zwave switches that have needed tweaking for them to show and operate the way I expected. I don’t have any dimmers though so I don’t know what settings specifically, if any could be changed to achieve the desired behavior.

6

@petro I’m mostly turning them off with the automations. They get turned on my the switch.

@Kbeesnees that’s a great suggestion, I didn’t even think of that. Thanks! I’m quite familiar with the ozwcp actually. :slight_smile:

7

BTW, just out of curiosity, what configuration did you ultimately decide would work for the task discussed here? I looked back and saw an improvement that could be made to my suggestion.

1 Like
8

@Kbeesnees lol, good question. I ran into this new issue while testing options for that config so I haven’t actually gotten back to it. This dimmer is the same one I was trying to automate. If you have another suggestion though I’m all ears!

9

Not trying to derail this thread for you so I’ll try not to keep getting off topic. :yum: The change I found is minor but if, “and (states.light.dining_room_light_level_11_0.attributes.brightness | float <= 50) }}” is added to the end of the trigger like in the code below, it won’t trigger every time the state has changed and it has been the designated amount of time. It will only trigger when brightness is below 50% AND it has been the set amount of time.

input_slider:
  - off_delay:
    name: Off Delay
    min: 0
    max: 20
    step: .5

automation:
  - alias: 'Turn off dining room light when at <50 brightness for set duration'
    trigger:
      - platform: template
        value_template: '{{ (as_timestamp (now()) -as_timestamp (states.light.dining_room_light_level_11_0.last_updated))|float >= (states.input_slider.off_delay.state|float * 60) and (states.light.dining_room_light_level_11_0.attributes.brightness | float <= 50) }}'
    condition:
      condition: template
      value_template: '{{ states.light.dining_room_light_level_11_0.attributes.brightness | float <= 50 }}'
    action:
      service: light.turn_off
      entity_id: light.dining_room_light_level_11_0

Replace the trigger template with this if you don’t want to be able to adjust the amount of time it waits. 300 is the seconds which equals 5 minutes.

{{ (states.light.dining_room_light_level_11_0.attributes.brightness | float <= 50) and (as_timestamp (now()) -as_timestamp (states.light.dining_room_light_level_11_0.last_updated))|float >= 300 }}

Hope you’re able to find something in OZWCP that makes the switch responsive.

1 Like
10

Thanks much! I have to go get my daughter from a dance in a few but may try to play with OZWCP when I get back! Otherwise I have all weekend to play.

11

Same, I’ll try to stay on the forums this weekend to offer any help I can. Enjoy the time with your family.

1 Like
12

@petro So I manually turned the switch on ~5 minutes ago (to full brightness) and the status still hasn’t change in HASS. I tried to also change the polling_interval for the zwave config to 60 seconds but still nothing.

@Kbeesnees I didn’t find anything relevant in OZWCP.

Any other thoughts/suggestions?

EDIT: Ugh, there is no consistency. I did this 3 or 4 times leaving 5+ minutes each time and ONE TIME it updated in HASS. The others never did. I was turning it on to full bright from the switch. After the one updated I dimmed it to nearly off and it’s still saying full brightness in HASS. :frowning:

EDIT 2: I’ve noticed some other polling issue. My z-wave thermostat has been “heating” for at least 20 minutes now but still shows idle on the HASS dashboard. Perhaps a larger issue here?

13

You need to set polling_intensity for each device you actually want to poll.

1 Like
14

@jwelter just tried that, set it to a 1 for the dimmer. Still not updating. :frowning:

15

Try this:

(note the customization needs to go inside the wave section - per device. This works with my GE dimmers)

zwave:
  usb_path: /dev/ttyACM0
  config_path: /srv/homeassistant/src/python-openzwave/openzwave/config
  polling_interval: 10000
  customize:

    light.office_level_3_0: 
      polling_intensity: 1
      refresh_value: 2
      delay: 3
4 Likes
17

Can you try to lower your polling interval just to try? I had issues with the default 60 seconds and not registering events at all. Setting to 10 seconds brought 100% reliability.

Also note – you need to wait 60 seconds after a HASS restart before testing; and may want to do a wave heal first. Z-Wave seems to be delayed or high latency during the first 60 seconds of a HASS restart/start.

1 Like
18

That’s useful to know, thanks! Going to try a 10 second interval and see what happens. Stay tuned!

19

@jwelter alright, I think we are on the right track here. Multiple (manual) changes are registering updates in HASS within 60 seconds or so. It’s coming up on bed time though (old fart :stuck_out_tongue: ) so going to pick back up on this tomorrow for more testing. Really appreciate your help!!

20

No problem, someone on here helped me get it working so I’m just passing the knowledge along :wink:

1 Like
21

Just wanted to follow-up on this since I know it’s been a while. @jwelter 's config change resolved this for me. Thanks so much!