You know what would be useful? A link to the article you’re referring to. I’m guessing https://smarthomescene.com/guides/how-to-build-a-stable-and-robust-zigbee-network/
- but that doesn’t contain the word ‘debouncing’, so >shrug<
this post was submitted on 01 Apr 2024
18 points (100.0% liked)
homeassistant
11706 readers
10 users here now
Home Assistant is open source home automation that puts local control and privacy first. Powered by a worldwide community of tinkerers and DIY enthusiasts. Perfect to run on a Raspberry Pi or a local server. Available for free at home-assistant.io
founded 1 year ago
MODERATORS
My bad, didn't think it would be important.
In the article, it talks about Tuya and their off key implementation of Zigbee and then links to this article https://smarthomescene.com/reviews/moes-linptech-presence-sensor-zss-lp-hp02-review/#zigbee-network-spam
In that article:
The only “workaround” I can think of is to use a better coordinator (EFR32MG21) and have many routers deployed in your network, so this device doesn’t crash it.
I have that coordinator and luckily my network is robust, but it's not snappy and I have to restart it every few days so I'm trying to think of things to mitigate the shiteness.
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.
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.
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.
Random one, but do you think it's possible to use the new label system to create the filter group?
Not according to the integration documentation: https://www.home-assistant.io/integrations/recorder/
The recorder integration only supports: domains, entities, events, and entity globs right now. I think that’s a good idea though, should check or create an enhancement request!
I went to create an enhancement request, but it's just creating a thread on their forums 😮💨
Iirc that’s where they start ERs yes - it’s easier to see, vote, and comment on them there compared to GitHub. It’s also the source for the month of WTF where it seemed like a lot of the easier ERs get addressed.
Guess I'll have to finally sign up to their forums
Thank you so much
Maybe I'm missing some context here, but 'debouncing' is just accounting for the fact that every switch, when pressed, will bounce on and off the contact for a few milliseconds. If you didn't account for this, then turning your light on would cause it to flicker on and off rapidly until the switch settles.
Your zigbee devices phoning home all day while not being used shouldn't have anything to do with debouncing.