Network gets slow when using Ikea dimmer about zigbee-herdsman HOT 11 CLOSED

I don't think messages of the dimmer are the issue, but that the automation made based on the dimmer are an issue. Due to Koenkk/zigbee-herdsman-converters@ad29b2b it publishes more frequent -> if your automation responds to all of them using e.g. a dim command on a zigbee bulb, there will be a lot of commands.

from zigbee-herdsman.

I see, thanks. Wasn't thinking of that. Was thinking that z2m must be the issue because this is what I changed.

So the issue that I had to reflash my device way most probably something different, I had an error there but did not save it (sry). Can't find it in the logs any more.

This is my automation. Would it be better to use the sensor entity of the dimmer? I think this would probably change to often too? Or maybe adding some delay to the action at the end would help. But there is probably a more elegant way to do this.

- alias:  ikea rotate - plus
  initial_state: 'on'
  trigger:
    platform: mqtt
    topic: 'zigbee2mqtt/ikea dimmer'
  condition:
    - condition: template
      value_template: "{{ trigger.payload_json.action in ['rotate_right', 'rotate_right_quick'] }}"
    - condition: state
      entity_id: light.wz
      state: 'on'             
  action:         
    - service: light.turn_on
      data_template:
        entity_id: light.wz
        brightness: "{{  states.light.wz.attributes.brightness | int + 25 }}"

from zigbee-herdsman.

From the zigbee2mqtt side you can use the debounce: https://www.zigbee2mqtt.io/information/configuration.html#device-specific-configuration

from zigbee-herdsman.

Perfect solution, thanks!

from zigbee-herdsman.

another workaround would be to add some kind of repeat number like LIRC does. It sends the remote code with a sequence number. It would be easier to pick the first message or every message with sequence modulo something.
I don't like the debounce param :)

Nov 10 22:37:29 lirc/status/tv/v- 0
Nov 10 22:37:29 lirc/status/tv/v- 1
Nov 10 22:37:29 lirc/status/tv/v- 2
Nov 10 22:37:29 lirc/status/tv/v- 3
Nov 10 22:37:29 lirc/status/tv/v- 4
Nov 10 22:37:29 lirc/status/tv/v- 5

@h4nc @Koenkk would that make sense ?

from zigbee-herdsman.

Seems like debounce works fine, lag is gone. Don't know if lire would make more sense. @Koenkk ?

from zigbee-herdsman.

i guess the elapsed attribute could also be used in HA automation: don't treat msg with a
small elapsed.

from zigbee-herdsman.

But would this mean the broker has to deal with all those messages. Isn’t it better to avoid this on the z2m side with debounce?

from zigbee-herdsman.

I feel debounce is a cleaner solution, it doesn't add any extra stuff to the payload keeping it clean. @h4nc would you mind making a PR to update the docs? https://github.com/Koenkk/zigbee2mqtt.io/blob/master/docs/devices/ICTC-G-1.md

from zigbee-herdsman.

my point of view here is that I don't want z2m to mask/merge/do anything-supposedly-smart with my zigbee messages and attributes.
I don't like the cache setting either, it's just here to circumvent a limitation of HA.

from zigbee-herdsman.

@lolorc I understand your point of view, but for me debounce is good enough as it solves my issue

would you mind making a PR to update the docs?

@Koenkk done

from zigbee-herdsman.