Domotiser cuve eau de pluie

Super, merci. Je vais essayer ça.
Mon fichier config me retourne des erreurs. Je ne dois pas être bon dans la syntaxe. J’ai essayé plusieurs varaintes sans succès.

# Loads default set of integrations. Do not remove.
default_config:

input_number:
  watertank_volume:
    name: volume_cuve
    initial: 0
    min: 0
    max: 1000
    step: 1

# Load frontend themes from the themes folder
frontend:
  themes: !include_dir_merge_named themes

sensor:
  - platform: filter
    name: watertank_level
    entity_id: sensor.shellyuni_3c6105e520bb_adc
    filters:
      - filter: time_throttle
        window_size: 00:01
  - name: Volume cuve
    unique_id: watertank_volume
    unit_of_measurement: "L"
    state: >
      {% set quantite = states('sensor.watertank_level') | float %}
      {{(quantite * 200)}}

J’aurais imaginé que le nouveau sensor défini serait sous la « rubrique » sensor au même niveau que platform mais il n’apprécie pas et me retourne une erreur en ligne 16 - la 1ère ligne sensor (juste avant -platform: filter

Je dois être à la rue dans la syntaxe du fichier

il te manque un tiret avant le sensor

- sensor:

Je déterre un fil deterré.

Mon idée pour ma cuve en me basant sur quelques chose de simple est un tube iro avec un câble multipaire genre 20 paires.

L’idée est de couper chacun des fils du plus court au plus long espacé quelques cm.
Si la cuve fait 1m de haut, ça sera donc tous les 5cm.

Quand la cuve se remplira, un gpio sera fermé chaque 5cm de hauteur d’eau.
Il suffit de calculer longueur x largeur x 5cm x le nombre de gpio fermé pour connaît le volume d’eau restant.

Sinon, il existe une autre solution simple, c’est l’usage de 2 compteur d’eau à impulsion.
Une au remplissage et une au puisage.
La différence maxi devra toujours être inférieure au volume maxi en litre de la cuve.

L’idée des fils coupés à différentes longueurs est bonne mais j’ai lu sur un autre forum que les fils immergés se corrodaient assez rapidement et que le système devenait rapidement instable et non fiable.
Pour les compteurs, c’est une bonne idée mais je pense qu’il faut coupler le système avec un capteur de niveau qui permet de réinitialiser à une valeur de référence de temps en temps.
Les compteurs ont forcément une sensibilité et une précision différentes l’un de l’autre. Du coup, avec le temps, le résultat doit dériver. Si on place un capteur de cuve pleine par exemple, on sait que lorsqu’il passe de 0 à 1, la cuve contient X litres (valeur de référence). Et on repart pour des additions/soustraction sur une base saine.

Merci TyTroll. Mais je dois vraiment être une pipe !
J’ai ajouté un - pour avoir ça :

sensor:
  - platform: filter
    name: watertank_level
    entity_id: sensor.shellyuni_3c6105e520bb_adc
    filters:
      - filter: time_throttle
        window_size: 00:01
  - sensor
    name: Volume cuve
    unique_id: watertank_volume
    unit_of_measurement: "L"
    state: >
      {% set quantite = states('sensor.watertank_level') | float %}
      {{(quantite * 200)}}

et File Editor me renvoit une erreur d’indentation sur name: Volume cuve. J’ai essayé de décaler à droite mais ça ne change rien…

bad indentation of a sequence entry (24:9)

 21 |       - filter: time_throttle
 22 |         window_size: 00:01
 23 |   - sensor
 24 |     name: Volume cuve
--------------^

J’ai beau chercher, je ne trouve pas de doc de référence qui pourrait m’expliquer les principales subtilités du YAML et des fichiers de configuration. Je trouve des bribes à droite ou à gauche mais rien qui ne m’aide vraiment… Vous auriez une idée ?

Je vais créer un sujet à part car on sort du coeur de cette discussion qui est le volume de cuve !

1 « J'aime »

Le second sensor n’est pas bon.
Il faut indiquer une ‹ platforme › pour chacun des sensor.
Ce qui donnerait

sensor:
  - platform: filter
    name: watertank_level
    entity_id: sensor.shellyuni_3c6105e520bb_adc
    filters:
      - filter: time_throttle
        window_size: 00:01
  - platform: UNEAUTRETYPEDEPLATEFORME
    name : UNAUTRENOM
    .....

le second sensor ressemble/ est de type ‹ template ›. pour le déclarer il faut plutôt faire

template:
  - sensor:
      - name: "Volume Cuve"
        unique_id: watertank_volume
        unit_of_measurement: "L"
        state: >
          {% set quantite = states('sensor.watertank_level') | float %}
          {{(quantite * 200)}}

Le tout assemblé donne :

sensor:
  - platform: filter
    name: watertank_level
    entity_id: sensor.shellyuni_3c6105e520bb_adc
    filters:
      - filter: time_throttle
        window_size: 00:01
template:
  - sensor:
      - name: "Volume Cuve"
        unique_id: watertank_volume
        unit_of_measurement: "L"
        state: >
          {% set quantite = states('sensor.watertank_level') | float %}
          {{(quantite * 200)}}

PS pour les template sensor, il est également possible de passer par l’interface graphique

Même si le cuivre est étamé ?

Un seul compteur avec une espcam pour lire la consommation qui entre et qui sort.
A moins de trouver un compteur qui remonte une valeur analogique positive ou négatives en fonction si le compteur incrémenter ou decremente.il me semble que les modules itron ever blue ont ce système qui détecte la réinjection de l’eau dans le réseau.

Je ne saurais pas te dire. Je n’ai pas testé moi-même. Mais j’avais lu que le passage de courant, même faible faisait se « bouffer » les fils assez rapidement. C’est comme les sondes d’humidité à planter dans la terre.
https://www.electromaker.io/uploads/images/Blog/Best%20Arduino%20Accessories/best-arduino-accessories-soil-moisture-sensor.jpg
Elles se détériorent très rapidement sauf à monitorer finement la prise de mesure (toutes les heures par exemple) pour ne pas envoyer de courant trop fréquemment.

Après, ca ne coûte pas grand chose d’essayer. Et si c’est mort au bout de 6 mois, tu les remplaces ou tu t’orientes vers une solution plus pérenne !

C’est vrai que la cuve de 1000l la lire une fois par jour peut suffire dans certains cas. Comme les sondes d’humidité dans le potager/arbre.

Top, je commence à comprendre quelques bricoles de plus :wink:

Par contre, modifications faites, je n’ai pas d’erreur de config mais après relance du fichier config, l’entité n’existe pas, ni dans l’onglet Entités, ni dans les Entrées… :innocent:
Je ne vois pas non plus d’erreurs dans le log.

1 « J'aime »

Bonjour @gic,
Si tu tiens vraiment à mettre des sondes, autant prendre quelque chose qui résistera un peu plus longtemps que juste des fils plongés dans l’eau.
Sur Ali tu peux trouver ces sondes (vendu par 3 (2.67€ livraison gratuite mais il ne faut pas être pressé) :
image

J’étais parti sur cela (j’en ai acheté plusieurs pour avoir comme toi les différents intervalles de hauteur) avant de changer d’avis et prendre une sonde Hydrostatique 0-10v avec un Shelly Uni.

Perso, je suis parti sur une sonde de pression. Un peu chère mais les résultats sont top.
En fait, je réagissais au post précédent !

1 « J'aime »

On avance :wink:
Peux tu préciser, quelle entité n’existe pas ?
Poster le code précisement implémenté pour chacuns des sensors?
Peut être tenter un redémarrage complet (et pas juste un rechargement du fichier configuration.yaml)

Ca marche !
En fait, j’avais pris l’habitude de ne relancer que le fichier config mais visiblement, ce n’est parfois pas suffisant. Donc j’ai fait un reboot complet et là, l’entité sensor.volume_cuve est disponible avec la bonne valeur !

Il ne reste plus qu’à trouver le moyen d’arrondir le chiffre affiché pour éviter les fractions de litres qui n’ont aucun intéret !

Merci de vos aides :wink:

Et j’ai trouvé ! En ajoutant un " | round(0)" après « (quantite * 200) »

Tip top !

1 « J'aime »