Reduce updating data frequency for Shelly devices

Configuration
1

Hi, I have some shelly devices (e.g. 3EM) on Hassio, using shelly integration. Everything works very fine, but I notice that the status of the sensor (e.g. Power, current, voltage) is updating very fast, and for this reason Influx database is growing very fast. Is there a way to reduce the update of the sensor?

I do not want to delete old data (e.g. < 1 year). I want to mantain the data, but having a low sensor frequency update .

Thanks

2

If you are using the standard Shelly integration (not Shelly4HASS), the updates are driven by the device itself using CoIoT, so any changes to the update frequency would need to be done by the device. Alternatively, you could setup some sort of network-level packet filtering to drop some of the incoming UDP packets… but that’s rather ugly :slight_smile:

3

Using ColoT, in which way can I edit frequency?

4

I just checked my Shelly EM, and it doesn’t offer any way to control the update frequency. If your 3EM uses the same software, then you don’t have any way to control it.

5

You could gather the webfrontend of the Shelly devices at whatever interval you like?!
That’s how I do it to control my solar battery charge process. 30s update interval is too slow, so I check http://shellyipadress/status and parse the info found there.

6

I was just looking what’s responsible for my Hass DB size and found my one Shelly Plug (Plus) created 14% of the rows in the states table!

The power (instantaneous Watts consumed) seems to be changing every 2 seconds. Some of that might be due to the device it is monitoring – it’s power usage seems to be fluctuating rapidly between a few values.

I’m using the out-of-the-box Shelly integration in Hass, so I guess it is speaking COAP. I’ve gone through the plug’s built in web server. I don’t see a way to change the update frequency.

So I’m looking for ideas.

7

I have seen a settings in the shelly status page, you can even change it like this:
http://SHELLYIP/settings?coiot_update_period=180

I would say this should the correct setting, but even then, updates are still coming in much too often. My database is growing like crazy because of this (I have several PlugS1)

2 Likes
8

Any updates on this issue? Can HA skip some events when saving changes to the DB from Coiot notifications?

I also experience this issue. About 30% of my DB records are Shelly 2.5 power consumption and temperature sensor updates. For comparison, my Shelly I3 device also uses Coiot but generates 80% fewer updates.

9

You can create a new sensor, which contains the data the way you want (in this example sensor.my_sensor is throttled to one update per minute):

sensor:
  - platform: filter
    name: "My Sensor filtered"
    entity_id: sensor.my_sensor
    filters:
      - filter: time_throttle
        window_size: "00:01"

And exclude the original sensor from the database:

recorder:
  exclude:
    entities:
      - sensor.my_sensor
3 Likes
10

I have also been struggling with an inflated recorder DB size, so I started to hunt down sources that generate lots of data.
For me, one of the sources with too frequent updates was the Shelly plugs.
The URL mentioned above setting helped me, too. E.g. to set 60 seconds updates:

http://IP_ADDRESS/settings?coiot_update_period=60

I have also worked on the correct SQL query to find the problematic devices.
The following one worked quite well. It takes the last 10,000 rows in the states table and counts which entity inserted how many of those. It also shows the last value, earliest and latest report time, and update period. These can help pinpoint what fills up the states table.

SELECT
    COUNT(*) AS "# of state changes",
    entity_id,
    last_state,
    DATETIME(first_update, 'unixepoch') AS first_update,
    DATETIME(last_update, 'unixepoch') AS last_update,
    CAST(ROUND(AVG(update_period)) AS INTEGER) AS update_period
FROM (
    SELECT
        states.state_id,
        states_meta.entity_id,
        LAST_VALUE(states.state) OVER (PARTITION BY states_meta.entity_id ORDER BY states.state_id ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING) AS last_state,
        FIRST_VALUE(last_reported_ts) OVER (PARTITION BY states_meta.entity_id ORDER BY states.state_id ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS first_update,
        LAST_VALUE(last_reported_ts) OVER (PARTITION BY states_meta.entity_id ORDER BY states.state_id ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING) AS last_update,
        (last_reported_ts - FIRST_VALUE(last_reported_ts) OVER (PARTITION BY states_meta.entity_id ORDER BY states.state_id ROWS BETWEEN 1 PRECEDING AND CURRENT ROW)) AS update_period
    FROM (
        SELECT *
        FROM states
        WHERE last_reported_ts IS NOT NULL
    ) AS states
    INNER JOIN states_meta ON states.metadata_id = states_meta.metadata_id
    WHERE states.state_id > (SELECT MAX(state_id) - 10000 FROM states)
)
GROUP BY entity_id
ORDER BY "# of state changes" DESC;