The other day, @[email protected] posted an awesome article about Zigbee network performance and it brought attention to something I was unaware of, which is that my devices aren’t supposed to shout all day, everyday about doing mostly nothing. I immediately followed the advice in the article and tried to debounce everything. But then everything stopped working like it should 😂 Can the community pool your collective knowledge and walk me through debouncing so I can not get MQTT spam but still have all my motion, presence and temperature sensors work please?

  • CondorWonder@lemmy.caEnglish
    2·
    8 months ago

    I’m curious too. As I understand it (and based on my observations after playing with it), it doesn’t change how often they send data to the controller, but instead changes how often the controller passes the data on. It doesn’t help the network, just the MQTT/Home Assistant side, but it can mean they flood the database less, if they’re tracking a value (like temperature). If they’re following a state (open or close) then I find they would miss the important messages and just not work well.

    In my case I’ve found a few Tuya devices that seem like they have bad firmware and flood the zigbee network - human presence sensors and co/voc/climate sensors. I experimented with denouncing them, but I still ended up retiring most of those devices as they degraded my network performance and other devices couldn’t communicate very well. If it actually prevented the devices from flooding the network it would make a lot more sense to use.

    I still have database filters to not record the main entities (for the mmWave presence sensors that I’m still using) and instead use a template on them to record their state as I found my database grew in size very quickly otherwise.

    • sabreW4K3@lazysoci.alOPEnglish
      1·
      8 months ago

      found my database grew in size very quickly

      Hold me! I’m dealing with that and haven’t figured out how to fix it. How does the templating thing work? All my devices are Tuya devices, so you can imagine how quickly my database balloons up.

      • CondorWonder@lemmy.caEnglish
        4·
        8 months ago

        First thing - exclude recording of the devices. My method was to use a glob so I name devices/entity IDs specifically and they don’t get recorded (in my case I used f_ as in “filtered” so devices become like “F Source Presence”), but you can add specific entities or use your own glob. In configuration.yaml I have this:

        recorder:
  exclude:
    entities:
      - sensor.excluded_entity_1
    # AND/OR this (then of course rename entities as needed)
    entity_globs:
      # exclude all sensor entities that start with f_
      - sensor.f_*

        Then I created templates for my presence sensors, that just copy the state so I get history (yaml here, but can do through UI now too in the Helpers section, the import part is the template in the state key below):

        template:
  - binary_sensor:
      - name: Real presence
        unique_id: my_presence
        state: >-
          {{ states('binary_sensor.f_source_presence}}
        availability: >-
          {{
            not (
              states('binary_sensor.f_source_presence') == 'unknown' or
              states('binary_sensor.f_source_presence') == 'unavailable'
            )
          }}
        device_class: presence

        You could also use a statistics sensor to get a moving average for numeric values and get history from them too (and reduce the noise by reducing the precision and having a larger time window). This is also available through the UI - Helpers.