Comment limiter le déclenchement des détecteurs?

[patrickp78]

Bonjour,

Je me demandais s’il n’y avait pas un autre moyen de limiter le déclenchement répétitif d’un détecteur, autre que celui de la temporisation.
Exemple : j’ai un pyranomètre qui baisse ou lève les volets roulants selon que l’on passe ou pas la barre des 300 W/m2.
Tout fonctionne très bien quand la couverture nuageuse est stable, mais par beau ciel nuageux (+ vent !), les volets n’en finissent pas de changer d’état.
Dans ce cas, limiter ces changements par une temporisation est-elle la seule solution ?
Merci pour vos conseils,
patrickp78

[mcp]

@patrickp78

mais par beau ciel nuageux (+ vent !), les volets n’en finissent pas de changer d’état.

Bonjour,

Justement pourquoi ne pas tenir compte de la météo, conditionner le fonctionnement à la couverture nuageuse et la vitesse du temps, que peuvent remonter les intégrations météo ?

Mcp

[Pulpy-Luke]

Salut,

Tu peux filtrer un peu avec une moyenne sur une petite durée, par exemple je fais ça avec mon capteur de température :

sensor:
  - platform: filter
    name: Sonde jardin temperature moyenne5min
    entity_id: sensor.sonde_jardin_temperature
    filters:
      - filter: time_simple_moving_average
        window_size: 00:05
        precision: 1

Filter

[patrickp78]

@mcp

pourquoi ne pas tenir compte de la météo,

Parce que la météo a TOUJOURS un temps de retard avec la situation en temps réel !
Un temps de retard ou carrément un constat différent.

[steche]

Il faut que tu introduises de l’hystérésis dans ton traitement comme cela est fait dans les thermostats, comme c’est fait dans ton frigo, ton congelo …

L’hystérésis, c’est quand un système ne réagit pas de la même façon à l’aller et au retour.

Dit simplement ça évite que ça fasse ON / OFF / ON / OFF en permanence.

Exemple très concret (le plus parlant)

Un thermostat réglé à 20 °C avec une hystérésis de ±0,5 °C :

• Le chauffage s’allume quand la température descend sous 19,5 °C

• Il s’éteint seulement quand ça dépasse 20,5 °C

Sans hystérésis, à 20 °C pile, le chauffage cliquetterait sans arrêt.

[BBE]

Sans ton automatisation dur à dire, mais personnellement je pense qu’il y a trois solutions (qui peuvent être complémentaires et applicables en même temps)

• la temporisation (au dessus/en dessous du seuil depuis x minutes par exemple)
• le filtrage du sensor (par exemple avec une moyenne glissante) pour limiter les micro-variations
• l’hystérésis (notion très employée en automatique) : avoir un seuil différent à la montée et à la descente pour ne pas bagotter si la valeur reste proche du seuil:
  • activer si luminosité > 310W/m2
  • désactiver si luminosité < 290W/m2

[edit] @steche a été plus rapide

[Bob]

@patrickp78

mais par beau ciel nuageux (+ vent !)

Je préfère le bleu du ciel breton
Tu fermes tes volets en plein jour ?
Parfois j’ai du mal à comprendre certains sujet
Et la nuit, c’est en fonction de la lune ?
Hop, je sors
Bob

[BBE]

Tu ne sais pas quel est le besoin à la source…

Il a peut être ce volet devant une plantation d’orchidées spécifiques qui ne supportent pas la lumière au delà du raisonnable…

[patrickp78]

@steche

Il faut que tu introduises de l’hystérésis

Merci pour l’info. Je veux bien essayer ça aussi, sauf que… avec un suppositoire, on savait comment faire, mais là !!!

@Pulpy-Luke

Tu peux filtrer un peu avec une moyenne sur une petite durée,

C’est en place avec un passe-bas, je teste, merci !

@Bob

Tu fermes tes volets en plein jour ?

J’utilise Adaptive Cover qui a des options de gestion des volets roulants et BSO vraiment très complètes, bien que j’ai dû procéder à quelques aménagements perso faute de suivi de son auteur. J’ai d’ailleurs fait un tuto tellement l’intégration était difficile à appréhender.

Bref et entre autres fonctions, tu peux décider de vouloir fermer un volet, un BSO ou un store s’il fait trop chaud à l’intérieur (ou à l’extérieur), si le soleil tape dans les yeux, s’il fait froid dehors et que la pièce n’est pas occupée (chambre d’amis)…
A moins que tu décides qu’il doive s’ouvrir complètement pour laisser entrer la chaleur du soleil…

Je baisse par exemple un BSO (Brise Soleil Orientable) situé plein Sud à une hauteur variable en fonction de l’élévation du soleil, de façon à toujours protéger une plante des rayons directs du soleil, tout en gérant l’orientation des lamelles pour voir à l’extérieur. De la domotique, en quelque sorte…

[Jeffodilo]

Bonjour,

Je comprends très bien le besoin, car j’ai planché sur le même sujet avec l’aide de l’IA sur un blueprint de gestion thermique pour réchauffer la maison l’hiver ou la préserver l’été mais faute de temps d’observation, c’est en standy.

J’ai introduit aussi une notion hystérésis paramétrable en minutes.

Si ça peut t’aider, il a été codé comme ceci en yaml, les indentations sont sûrement faute, je suis sur mon téléphone…

- variables:
    az_min: "{{ repeat.item.azimuth_min }}"
    az_max: "{{ repeat.item.azimuth_max }}"
    volet: "{{ repeat.item.volets }}"
    temp_int: "{{ states(repeat.item.temp_sensor) | float(0) }}"
    last_change: "{{ as_timestamp(states[volet].last_changed) if states[volet] is defined else 0 }}"
    time_diff: "{{ (as_timestamp(now()) - last_change) / 60 }}"

Puis reprise dans une condition template, hystérésis étant déclaré dans un champ de saisie et stocker dans une variable

- condition: template
    value_template: >
      {{ az_min <= azimuth <= az_max
      and lux_val >= lux_semi_val
      and lux_val < lux_hiver_val
      and states(volet) != 'open'
      and time_diff >= hysteresis

[patrickp78]

@Pulpy-Luke

Tu peux filtrer un peu avec une moyenne sur une petite durée,

J’ai mis en place un filtre passe-bas qui lisse effectivement bien les valeurs. Par contre, j’ai beau chercher, je ne trouve pas d’explications suffisantes à l’utilisation des variables window_type et time_constant (entre autres).
Aucune info dans le descriptif de l’intégration sur leur emploi et leur unité.
J’en suis resté aux valeurs par défaut mais on aura compris que c’est loin de me satisfaire…
Si quelqu’un a quelqu’info…

Merci d’avance,
patrickp78

[Pulpy-Luke]

Salut,

Pourtant c’est bien dans la doc… Windows_size (et pas type) et time_constant

window_size :

Taille de la fenêtre des états précédents. Les filtres basés sur le temps, tels que time_simple_moving_average, nécessitent une période (taille en temps), tandis que d'autres filtres, tels que outlier, nécessitent un nombre entier (taille en nombre d'états). Les périodes sont au format hh:mm et doivent être indiquées entre guillemets.
Donc en gros pendant combien de temps ou sur combien de valeurs le filtre se base pour faire son boulot

time_constant:
Voir lowpass filter. Ceci est vaguement lié au temps nécessaire à un état pour influencer la sortie.

Et tous les types de filtres sont listés, formule de calcul comprise

Filter

Dans mon exemple, il s’agit de la moyen glissante sur 5min

[patrickp78]

Merci @Pulpy-Luke , j’avais bien lu tout cela… Reste cette expectative qui me ronge inlassablement à l’idée de manquer le TGV pour avoir mal compris les horaires !!!

Plus sérieusement, dans le cas du filtre pass bas que j’ai pris avec tous ses défauts ( ) :

• window_size : 1 (taille de la fenêtre des états précédents)
  Cela signifie qu’il ne tient compte que du dernier état ?

• time_constant : 10 (Time period are in hh:mm format)
  Donc 10 c’est quoi, des heures ou des minutes ? Donc 90, ça ferait 01:30 ?

Trop scolaire sans doute, trop scolaire…
Cela dit, je suis pleinement satisfait du filtre, quand bien même il reste à jouer avec pour l’optimiser… ce qui ne pourrait se faire que dans la window-size du 15 au 20 août prochain, vu le peu d’entrain du soleil à revenir sur la région !

[BBE]

@patrickp78

Dans ton exemple c’est quoi ton fonctionnement désiré ?

Parce que filtrer comme tu le fait va surtout retarder tes changements d’état…

Alors qu’un hystérésis comme :

• ouverture quand lum < 250
• fermeture quand lum > 450

T’aurais aussi fermé les volet à 11h45, ouvert à 12h20, fermé à 13h ouvert à 13h30 et t’aurais évité l’aller retour de 14h45 (comme ton filtrage) mais en réagissant plus vite que ta valeur filtrée qui décale la réaction de quasi 15min…

[patrickp78]

Ça pourrait être mieux effectivement !
Je ne suis pas contre le fait d’essayer, curieux de tout que je suis !
Encore faut-il avoir la recette…
Scolaire, je vous dis, scolaire !

Bref, il s’agit bien de ça ?

Threshold

[Pulpy-Luke]

@patrickp78

window_size : 1 (taille de la fenêtre des états précédents)
Cela signifie qu’il ne tient compte que du dernier état ?

C’est le nombre de valeur à prendre en compte, donc 1 = à tous les coups, 10 c’est un 1 fois sur 10

@patrickp78

time_constant : 10 (Time period are in hh:mm format)
Donc 10 c’est quoi, des heures ou des minutes ? Donc 90, ça ferait 01:30 ?

Là c’est carrément marqué dessus … format HH:MM donc 10 si juste 10 c’est 10 minutes … pareil que 00:10 si tu veux lever le doute…

[patrickp78]

@BBE

Alors qu’un hystérésis comme…

En fait, ça ne marche pas dans le cas présent car l’entité dans Adaptive Cover attend une valeur en W/m2, non pas un ON ou OFF.

Il va donc falloir que j’affine le filtre Pass-Bas pour avoir une réponse plus rapide.

[BBE]

Tu te crées ton propre sensor template que tu fais valoir arbitrairement 0 ou 500 en fonction du sensor de base ..

Et c’est lui que tu câbles dans ton intégration.

C’est moche, mais au moins pour tester…

[patrickp78]

@BBE

Tu te crées ton propre sensor template

Au final je vais opter pour l’hystérésis qui semble effectivement mieux adaptée que le pass-bas.
J’ai juste un soucis avec la valeur à appliquer.

Définition :
hystérésis flottante ( Optionnel , valeur par défaut : 0,0 )
La distance que doit avoir la valeur observée par rapport au seuil avant que l’état ne change.

Si seule la limite inférieure est configurée, le capteur est activé lorsque la valeur du capteur d’entrée est inférieure à cette limite.
Si seule la limite supérieure est configurée, le capteur est activé lorsque la valeur du capteur d’entrée est supérieure à cette limite.
Si les deux limites sont configurées, le capteur est activé lorsque la valeur du capteur d’entrée est comprise entre les limites inférieure et supérieure.

S’agissant de mon capteur pyranomètre, ce qui est défini comme une distance, c’est bien une valeur en W/m2 ?

Exemple : si je mets une limite supérieure à 300 (W/m2) et aucune limite inférieure, je vais donc passer en ON si ≥ 300 et en OFF si < 300 avec une hystérésis à 0.
Comment ça se passe maintenant si je mets 10 en hystérésis ? Ça provoque un ON si ≥ 310 et un OFF si < à 290 ?

Difficile de tester ça avec ce temps pourri. En écrivant ce post, mon raisonnement à l’air de coller mais je préfère m’en assurer…
Merci pour vos conseils,
patrickp78