Home-Assistant on BlocNotes

Fix Home-Assistant statistics and energy erroneous values

Tue, 30 Sep 2025 00:00:00 +0000

Introduction

I have been experimenting with solar panels, Home Assistant and my electricity meter lately. This French meter from the utility is called Linky. It provides a small power supply (130 mW) and a serial link hidden via amplitude modulation.
To avoid using batteries, I built a prototype that harvests this power, demodulates the serial link, and feeds the data into an nRF52 development kit. It works well enough that I never bothered turning this messy setup into a proper PCB.

However, every now and then—despite CRC checks—I get an erroneous reading that messes up the Home Assistant Energy panel. Here’s how to fix incorrect statistics in the Home Assistant database.

Preparation

Before editing the database, it is strongly recommended to stop Home Assistant to avoid concurrent access that could corrupt the database.

Connect to the system running Home Assistant
Install SQLite3 if needed. For example, on Debian-based systems: apt install sqlite3
Locate the home-assistant_v2.db database file in Home-Assistant data folder and create a backup

Open the database for editing

Open the database using SQLite and set a more readable output mode:

$ sqlite3 home-assistant_v2.db
# Then enter the commands
sqlite> .header on
sqlite> .mode column

Find the data id

Identify Home Assitant’s internal identifier, it is called metadata_id. Replace easf02 with Home-Assistant’s Entity ID you are looking for.
Using LIKE '%PARTIAL_ENTITY_STRING% allows for easier search by matching any string containing PARTIAL_ENTITY_STRING

sqlite> SELECT id, statistic_id FROM statistics_meta WHERE statistic_id LIKE '%easf01%';
id  statistic_id            
--  ------------------------
6   sensor.linky_easf01     
15  sensor.linky_easf01_cost

In this case id = 6 is the one we want to fix, and id = 15 is the associated cost.

Search for erroneous data

We let’s ask the database for any sudden jump in the data, e.g change greater than 10,000 Wh. Adjust metadata_id = 6 and the threshold (> 10000) as needed.

WITH ordered_stats AS (
  SELECT
    id,
    created_ts,
    sum,
    metadata_id,
    LAG(sum) OVER (PARTITION BY metadata_id ORDER BY created_ts) AS previous_sum,
    LAG(created_ts) OVER (PARTITION BY metadata_id ORDER BY created_ts) AS previous_created_ts
  FROM statistics
  WHERE metadata_id = 6
)
SELECT
  id,
  datetime(created_ts, 'unixepoch', 'localtime') as date,
  ABS(sum - previous_sum) AS difference
FROM ordered_stats
WHERE ABS(sum - previous_sum) > 10000 ORDER BY id DESC LIMIT 5;

In a nutshell, this query:

Selects statistics data for the entity and associates each value with the previous one.
Displays the five most recent entries where the difference between consecutive values exceeds the threshold.

Example result:

id      date                 difference
------  -------------------  ----------
229351  2025-08-18 14:00:10  20676793.0
38711   2025-01-28 12:00:10  20020401.0

Looks like we found the 20.6 MWh spike reported in the Energy panel :-)

Update the value

Since Home Assistant records cumulative sums, we need to subtract the erroneous difference from all entries starting from the anomaly. Use the following query:

UPDATE statistics SET sum = sum - 20676793.0 WHERE metadata_id = 6 and id >= 229351;

Replace 20676793.0 and 229351 with your actual values.

The statistics_short_term sum should also be adjusted by the same value:

UPDATE statistics_short_term SET sum = sum - 20676793.0 WHERE metadata_id = 6;

Once done, exit SQLite by pressing Ctrl + D. The database is now fixed, and the energy panel displays accurate values!

Fixed Home-Assistant energy panel

Automate shutters with an ESP and Home Assistant

Sun, 12 Jul 2020 18:50:41 +0000

I recently did a proof of concept on shutters automation by hacking the remote control: the idea is to wire the ESP in parallel with the remote control buttons.
My remotes are Bubendorff 41677 but it should work with a lot of other remote controls.

Wemos & the remote control

After poking with a multi-meter it appears that two test points are connected to the right signals:

TP103: Up
TP102: Down

The signal is active low: there is a pull-up resistor and it must be grounded to simulate the activation. A 680 Ohm resistor is used in series with each button of the remote to prevent current overshoot and maybe reduce power consumption, so I also used them:

Schematic

You might not see the resistors on the top picture as I only had SMD 0603 on hand; look carefully :)

On the first attempt, I used the great ESPHome project to simulate pressing the pushbuttons. I just created 3 virtual switches as a proof of concept but for correct integration, a cover component can be used.
I split the configuration into two files: one generic and the other only specifying the shutter name (room) and timings.

Per device file, called shutters-office.yaml in this example:

substitutions:
  # Used for HASS identifier
  name: office
  # Used for friendly name
  switch_name: "bureau"
  # Time from fully closed to fully opened
  full_time: "16s"
  # Time from fully closed to slightly opened
  partially_open_time: "5s"
  # Time for the "button pressed" event
  on_time: "150ms"

<<: !include shutters-common.yaml

Then the generic file called shutters-common.yaml:

esphome:
  name: shutters_${name}
  platform: ESP8266
  board: d1_mini

wifi:
  ssid: "MY SSID"
  password: "MY PASSWORD"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Shutter fallback hotspot"
    password: "12345678ABCDEF"

captive_portal:

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:

switch:
  # Define with GPIOs are used
  - platform: gpio
    id: up
    pin:
      number: 12
      inverted: yes
    restore_mode: ALWAYS_OFF
  - platform: gpio
    id: down
    pin:
      number: 14
      inverted: yes
    restore_mode: ALWAYS_OFF

  # Define template simulating the push on the button
  - platform: template
    name: Shutter ${switch_name} open
    turn_on_action:
      - switch.turn_on: up
      - delay: ${on_time}
      - switch.turn_off: up

  - platform: template
    name: Shutter ${switch_name} close
    turn_on_action:
      - switch.turn_on: down
      - delay: ${on_time}
      - switch.turn_off: down

  # Define template for slightly opening the shutter
  - platform: template
    name: Shutter ${switch_name} slightly open
    turn_on_action:
      - switch.turn_on: down
      - delay: ${on_time}
      - switch.turn_off: down
      - delay: ${full_time}
      - switch.turn_on: up
      - delay: ${on_time}
      - switch.turn_off: up
      - delay: ${partially_open_time}
      - switch.turn_on: up
      - delay: ${on_time}
      - switch.turn_off: up

As there is no feedback information on the shutter state the “slightly opened” state is achieved by fully closing the shutter then opening it for a small amount of time.
Once the ESP8266 or ESP32 is flashed the only thing remaining is to add it to Home-Assistant, thanks to Configuration => Integrations => Set up a new integration => Search for ESPHome => enter the ESP IP address. Et voilà, you are good to go and create powerful automations in Home-Assistant.

On the next version, I used a more clever strategy to command shutters from 0 to 100%, and a LoRaWAN board to allow battery-powered operation - to be published soon.