Attaquez la BDD locale HA depuis NodeRed

Entraide Home Assistant
1

Hello,

Besoin : supprimer des données erronées renvoyé par mon ZLinky (style conso de 150000 w)
lorsqu’elles arrivent via node red

=> event de detection de données erronées : OK
=> Requete de suppression de la donnée erronée : OK (testé via SQLLiteWeb)

Mais j’suis incapable de configurer l’accès à la BDD Home assistant :frowning:
(home-assistant_v2.db sous config/

J’ai tout essayé j’arrive pas à configurer correctement le noeud ‹ sqllite › sous node-red… :frowning:

Je pige encore moins les noeuds liè la BDD testDB666, configuré comme /config/test666.db
Mais je la trouve nulle part…

Bref, je n’y arrive pas et je sais pas vraiment quel est le pbr…
Peut etre que le path que je renseigne pour la BDD est foireux, peut etre que je m’y prends mal et qu’il faut utiliser une autre config/noeud

Le forum saurait il m’aider ???
Mercii d’avance :slight_smile:

2

Salut

Commence par nous aider :slight_smile:
Lorsque tu crées un sujet, il faut mettre ta configuration.
Sinon on est obligé de sortir la boule de cristal :rofl:
Mon pronostic : si tu as HA et Node red sur la même machine, ç’est surement une histoire de configuration Docker.

3

Effectivement j’ai oublié de la rajouter :smiley:

HA tourne sur une VM

Ma config donc :

System Information

version core-2024.9.3
installation_type Home Assistant OS
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.12.4
os_name Linux
os_version 6.1.74-haos
arch x86_64
timezone Europe/Paris
config_dir /config
Home Assistant Community Store
GitHub API ok
GitHub Content ok
GitHub Web ok
HACS Data ok
GitHub API Calls Remaining 5000
Installed Version 2.0.1
Stage running
Available Repositories 1465
Downloaded Repositories 35
Home Assistant Cloud
logged_in false
can_reach_cert_server ok
can_reach_cloud_auth ok
can_reach_cloud ok
Home Assistant Supervisor
host_os Home Assistant OS 11.5
update_channel stable
supervisor_version supervisor-2024.11.2
agent_version 1.6.0
docker_version 24.0.7
disk_total 90.9 GB
disk_used 29.2 GB
healthy true
supported true
host_connectivity true
supervisor_connectivity true
ntp_synchronized true
virtualization oracle
board ova
supervisor_api ok
version_api ok
installed_addons Z-Wave JS (0.6.2), File editor (5.6.0), Node-RED (17.0.3), Log Viewer (0.17.0), Terminal & SSH (9.14.0), Samba share (10.0.2), Zigbee2MQTT (1.33.1-1), Mosquitto broker (6.3.1), Tailscale (0.11.1), Z-Wave JS UI (1.11.2), Home Assistant Google Drive Backup (0.111.1), SQLite Web (4.2.2)
Dashboards
dashboards 2
resources 21
views 16
mode storage
Recorder
oldest_recorder_run 4 novembre 2024 à 06:02
current_recorder_run 4 novembre 2024 à 10:37
estimated_db_size 4206.23 MiB
database_engine sqlite
database_version 3.45.3
4

Salut,

C’est plus une réponse « globale » qu’une réponse à ta demande mais je pense que prévoir une mécanique comme celle-ci va plus te poser de problème que te soulager :

  • Le système de BDD de HA n’est pas fait pour avoir 2 accès concurrents au même fichier. Quand HA écrit (dans une table), c’est pas un souci quand il est tout seul, mais quand ton NR le fait en même temps que HA (voire la supprime juste avant) => :bomb:
  • 4go de données, c’est trop, tu as un souci de config du recorder. En plus au moment de l’ecriture, c’est plus long, donc plus de chance d’avoir le conflit mentionné au dessus.
  • Prévoir une méthode pour les anomalies futures, est-ce utile ? Lors de mise en place du linky, je peux bien imaginer qu’il y a des decalages, mais après ça me parait plus compliquer. Et puis est-ce systématiquement le même moyen de corriger ?
  • Nodered, c’est un processus lourds, donc à mon avis pas le plus simple

Bref, à toi de voir, perso ça me parait être une piste glissante

1 « J'aime »
5

Merci pour tes réponses

  • Le système de BDD de HA n’est pas fait pour avoir 2 accès concurrents au même fichier.

je comprends ta remarque mais je ne ferai pas d’update fréquent / massif en BDD
Le pbr arrive 1/2 fois par semaine « aléatoirement »; Le mieux serait de régler le pbr à la source mais pas réussi…
Les accès concurrents ne posent pas de pbr meme sur un SGBD simple comme SqlLite

  • 4go de données, c’est trop, tu as un souci de config du recorder.

en phase, me suis jamais penché sur le recorder… Ca fait 2 ans que je dois m’y mettre

  • Prévoir une méthode pour les anomalies futures, est-ce utile ?

mon Zlinky est en place depuis pas loin de 2 ans… J’avais jamais eu le pbr, il est apparu il y a quelques semaines… Et chaque erreur rend le graph totalement illisible à cause de l’echelle dynamique
Si mon scenario rode ned ne s’execute jamais dans le futurn, ca me convient tout à fait… Mais pas envie de devoir lancer une requete SQL à la mano chaue fois que je me rends compte que mon graph est illisible à cause d’une seule mauvaise donnée…

Sinon autre solution mais j’ai encore creusé.
J’utilise 2 sensor…
Celui de base du ZLinky qui renvoit en Kw, et un dérivé que j’ai défini en W

- name: zlinky_conso_w
  unit_of_measurement: "W"
  icon: mdi:lightning-bolt-outline
  state: "{{ (states('sensor.zlinky_conso') | float * 1000) | round(0) }}"

Il faudrait que j’empeche tous les states de sensor.zlinky_conso > 10
Mais meme en faisant 2-3 tests via « filter », j’ai pas réussi…

  • platform: filter
    name: « zlinky conso_w-filter »
    entity_id: sensor.zlinky_conso_w
    filters:
    • filter: outlier
      radius: 7000
6

ça c’est pas vrai dans ton cas. Là ton NR va attaquer le fichier (accès stokage), avec son propre moteur SGBD, tout comme HA va continuer à utiliser le sien de son coté.
Donc tout ce qui existe comme mode interlock ou transactionnel, n’est pas exploitable