[Bug]: localtuya is flooding the DB of events #517

m4r1k · 2025-01-27T18:13:46Z

LocalTuya Version

2025.1.1

Home Assistant Version

2025.1.4 Docker

Environment

Does the device work using the Home Assistant Tuya Cloud component?
Is this device connected to another local integration, including Home Assistant and any other tools?
The devices are within the same HA subnet, and they get discovered automatically when I add them

What happened?

Hello there,

I just reported on the HA community how LocalTuya is flooding the DB of events.
https://community.home-assistant.io/t/how-to-keep-your-recorder-database-size-under-control/295795/303?u=m4r1k

42970497|47|localtuya_device_triggered
41694080|45|localtuya_device_dp_triggered
6170957|6|localtuya_states_update

The events are described here: https://github.com/xZetsubou/hass-localtuya/blob/master/documentation/docs/ha_events.md?plain=1

But I think there should be a config on a per-device basis to record all this many events.
Also, I've seen an increase in the number of events from the 2025.1 version.

Steps to reproduce.

unclear

Relevant log output

Diagnostics information.

No response

The text was updated successfully, but these errors were encountered:

xZetsubou · 2025-01-27T21:07:10Z

The is an old issue #372 tho I haven't give it much attention yet so yes I would recommended to exclude it from recorder for now, this could happen if you have a sensors that update every seconds.

Cook23 · 2025-02-19T08:05:25Z

For every new version I make the same modification:

to remove it locally you can comment out a line in localtuya module. from home assistant directory. config/custom_components/localtuya/coordinator.py open the file and search for this line

self._handle_event(self._status, status)

then comment it out or remove you can comment it out by adding "#" at the beginning of the text # self.....

If not "event" and "event_data" table of database grow by several gigabytes every day.

This recording of events by "self._handle_event(self._status, status)" should definitively be an option disabled by default.

xZetsubou · 2025-02-19T08:15:44Z

this method handle the whole device not only one entity, Now the issue even If I give the user the option to turn it on it's still an issue it's still an issue and If HA doesn't give an option to filter it hard coded, then I'll need to create filter my self it's fine it's not big deal I'll look into it soon.

Cook23 · 2025-02-19T10:28:32Z

Yes but I don't know the reason of these writes in "event" tables of database for every entities. In fact I don't know the use of "event" tables.

For me it's completely useless. The only data I use come from the "state" and "statistics" tables of database. If I truncate these "event" tables nothing change, home assistant still running flawlessly without any difference. I imagine "event" tables have some use but I didn't see it.

It's possible to choose what is recorded in "state" tables from recorder settings but these settings have no effect on event tables.

So I only see "event" tables as a major flaw that cause my home assistant eat my memory and became unfunctionnal in just few weeks.

xZetsubou · 2025-02-22T09:29:43Z

I made some changes I was hopefully that there was a way to exclude events from HA recorder hard-coded.

TBF, I'm not sure if it will fix this issue totally or not however I still recommend to exclude integration events from recorder in configuration.yml I'll update the events page in docs.

What I'm not sure of does home-assistant record the events that not being listen to? so I there is no listener for any of LT events or wildcard * would HA still even fire an event!?, unfortunately HA discord made dev channel read-only which makes it now hard to find quickly answer for these questions, If home-assistant doesn't filter these by knowing if the event actually listened to or not, then another fix may needed but let's text now how does things go.

note: event: localtuya_device_triggered not longer exists and states_update renamed to status_update

Cook23 · 2025-02-22T10:08:29Z

I made some changes I was hopefully that there was a way to exclude events from HA recorder hard-coded.

TBF, I'm not sure if it will fix this issue totally or not however I still recommend to exclude integration events from recorder in configuration.yml I'll update the events page in docs.

What I'm not sure of does home-assistant record the events that not being listen to? so I there is no listener for any of LT events or wildcard * would HA still even fire an event!?, unfortunately HA discord made dev channel read-only which makes it now hard to find quickly answer for these questions, If home-assistant doesn't filter these by knowing if the event actually listened to or not, then another fix may needed but let's text now how does things go.

note: event: localtuya_device_triggered not longer exists and states_update renamed to status_update

Even if excluded from recorder it's still recorded in "events" databases. According my tests exclude from recorder only act on "states" and "statistics" databases.

All my local tuya measurements variables was excluded (to avoid flooding "states" database) and "events" is still flooded. All measurements data was processed and filtered by node red and only output variable from node red was allowed in recorder. None from local tuya.

xZetsubou · 2025-02-22T10:29:39Z

According to HA recorder docs it should do that,

I would want to see how much it improved after the changes, if it's still an issue we can look more into it.

github-actions · 2025-03-02T10:29:30Z

This issue was closed because it was resolved on the release: 2025.3.0

m4r1k · 2025-03-02T12:02:49Z

Situation massively improved, thanks for the effort!

localtuya_device_dp_triggered is still firing a lot.

Do you think the situation can be further improved?

Cook23 · 2025-03-14T08:18:58Z

@xZetsubou

Situation improved but I still generate 2 GB of data in event and event_data table in one week so I still need to comment this line:

    self._last_update_time = int(time.monotonic())
    #self._handle_event(self._status, status)

I still didn't understand why it's needed to write the events. everything works well with this line commented out.

xZetsubou · 2025-03-17T22:03:00Z

I'll dig more into this later

everything works well with this line commented out.

Well commenting out this line disables the feature :)

Cook23 · 2025-03-18T08:24:25Z

Well commenting out this line disables the feature :)

Ok but which feature ? Everything is still working perfectly. I still dont understand the purpose of these writes in DB. It's used for what ?

Cook23 · 2025-04-21T06:47:21Z

@xZetsubou

I strongly believe the best is to add an option to not write in "events" table of databases at all. With the line "self.handle_events" commented out tables "events" is only 100 MB after one month compare to 2 GB / weeks.

Everything in HA still working fine and I still have no idea about what is the purpose of these writing in database table.

JohnnyPr1nce · 2025-05-15T03:19:20Z

Hello friends, I'm also using another integration named Xiaomi Mito Auto to help me manage my MiHome devices. While browsing the ReadMe, I found they mentioned that

Since the HA support service response has been for some time, this component no longer triggers events starting from v0.7.18. see the README here

I haven't found any HA official announcement about HA support service response, yet. So I just looked into that corresponging version's changelog and found these two commits remove event for services and remove notification for services.

It seems they did something similar to commenting out self._handle_event(self._status, status) by just deleting some code related to hass.bus.async_fire. After that, no hass.bus.async_fire is being used in their project.

I'm not sure what feature will be influenced by commenting self._handle_event(self._status, status) out. But do hope this reference may be helpful. @xZetsubou

m4r1k added the bug Something isn't working label Jan 27, 2025

xZetsubou added the enhancement New feature or request label Jan 27, 2025

xZetsubou mentioned this issue Feb 22, 2025

breaking_change(events): removed/rename events and improve events handler #564

Merged

xZetsubou added the master/next-release Fixed in master branch, Will be ready in the next release label Feb 22, 2025

github-actions bot added stale and removed master/next-release Fixed in master branch, Will be ready in the next release stale labels Mar 2, 2025

github-actions bot closed this as completed Mar 2, 2025

xZetsubou reopened this Apr 23, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[Bug]: localtuya is flooding the DB of events #517

[Bug]: localtuya is flooding the DB of events #517

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

[Bug]: localtuya is flooding the DB of events #517

[Bug]: localtuya is flooding the DB of events #517

Comments

LocalTuya Version

Home Assistant Version

Environment

What happened?

Steps to reproduce.

Relevant log output

Diagnostics information.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!