J’arrive correctement à notifier les valeurs et à effectuer des calculs avec.
trigger.from_state.state
trigger.to_state.state
J’ai un appareil qui me remonte deux informations simultanément (pH et désinfection de l’eau).
Question : J’en doute réellement mais est-il possible de récupérer la valeur précédente et l’actuelle sur les deux trigger en même temps ?
Ce serait pour calculer l’évolution des deux entité en même temps et affiner mon algorithme
Voici un automatisme de démo
alias: Test - Trigger double
description: ""
trigger:
- platform: state
entity_id:
- sensor.spa_flipr_red_ox
to: null
- platform: state
entity_id:
- sensor.spa_flipr_ph
to: null
condition: []
action:
- service: notify.mobile_app_huawei
data:
message: >-
Analyse deux trigger simultané <br> Valeur avant {{
trigger.from_state.state }} <br> Valeur après {{ trigger.to_state.state
}}
mode: single
Et les capture écran indiquant que le second trigger ne peut pas être traité
Salut,
ça ne marchera pas.
les 2 triggers sont indépendants. Ca va exécuter la logique si un OU l’autre change… tu n’aura pas les from/to des 2 triggers en même temps.
Un façon de faire ça c’est de créer des Sensors Template donc la valeur change en fonction d’un trigger. Ce n’est pas à faire dans les automatisations, mais dans le fichier de configuration.
Ensuite, tu peux faire une automatisation qui envoie des notifications quand tu le veux vraiment, avec les 2 valeurs calculées.
Ceci est un lien direct vers la doc de « trigger based template sensors »:
Pas mal, je vais tester mais j’ai l’impression que je ne pourrait remonter que l’un ou l’autre.
L’idée est d’en traiter le premier, puis le second et une fois les 4 valeurs obtenu d’exécuter une action si
ph et ox monte
ph monte et ox descend
ph descend et ox monte
ph et ox descend
Je suis également en train de tester les moyenne sur l’oxydation grâce à un sujet existant sur le forum. C’est prometteur. Je regarde ce que donne filter par rapport à average.
Plus d’info sur Moyenne sur 30 minutes d'un capteur - #16 par Haz
Dans tous les cas, tu aura qu’un trigger de déclencher. Un trigger est un évènement et en informatique les évènements sont forcément séquentiel.
Il faut que tu fasse autrement pour arriver à ton besoin/envie
Est-il possible de sauvegarder les valeur from_state et to_state dans deux variables pour le premier trigger puis de faire la même pour le second ?
Si je met un délais de 10 seconde sur l’un des deux ils sont correctement traité de manière séquentiel.
Reste à trouver comment sauvegarder les données du premier trigger pour les utiliser plus loin dans l’automate quand le second tigger est validé.
Exemple en mettant un délais sur le pH et une notification avec des variables (que je ne sais pas créer ni définir)
probablement qu’un template pourrait aider mais je manque d’exemple pour m’en inspirer.
alias: Test - Trigger double
description: ""
trigger:
- platform: state
entity_id:
- sensor.spa_flipr_red_ox
to: null
- platform: state
entity_id:
- sensor.spa_flipr_ph
to: null
for:
hours: 0
minutes: 0
seconds: 10
condition: []
action:
- service: notify.mobile_app_huawei
data:
message: >-
Analyse deux trigger simultané <br> Premier trigger pH<br>
Valeur avant {{ variable_3 }} <br>
Valeur après {{ variable_4 }} <br>
Deuxième trigger Ox <br>
Valeur avant {{ variable_1 }} <br>
Valeur après {{ variable_2 }}
mode: single
Parce que je ne connait pas encore toutes les possibilités offerte par HA…
J’avais vu ton message il y a quelques semaines et j’étais loin d’imaginer que ça pourrait être applicable pour mon cas.
Je vais étudier tout ça sérieusement, merci pour le conseil… en espérant que ce soit reproductible sur mon usage
Je pense avoir trouvé une solution intéressante. Je suis en train de tester les requêtes SQL là où je suis plus à l’aise et je crée une intégration SQL pour remonter la valeur qui m’intéresse.
Exemple de code pouvant remonter l’avant dernière valeur de manière indépendante des déclencheurs (trigger)
Pour l’intégration pensez à supprimer le premier commentaire SQL pour ne pas être éjecté par l’intégration
-- Remonte l'avant dernier enregistrement d'un capteur
SELECT s.state
FROM states s, states_meta m
WHERE s.metadata_id = m.metadata_id
-- Nom de l'entitée à suivre
AND m.entity_id = 'sensor.spa_flipr_ph'
-- Remonte plus loin que l'avant dernier enregistrement jusqu'à trouver de la donnée
AND s.state <> 'unavailable'
ORDER BY
last_updated_ts DESC
LIMIT 1,1
Je valide la méthode mais attendez au minimum 30s ou 1min avant d’appeler les sensors issus d’une intégration SQL.
C’est le temps qu’il faut à HA pour inscrire en base les nouvelles valeurs.
Sans ce délais, vous remonterez l’ancienne valeur n-1. C’est à dire la valeur n-2 après l’ajout des nouvelles données.
Gros bonus : contrairement à from_state et to_state qui ne peuvent pas être appeler manuellement, ces données sont des sensors et peuvent être reprises partout y compris dans les tableaux de bord.
J’ai réussi sans trop d’effort à remonter plusieurs valeurs n-1 en même temps dans la même notification.
Pour résumer voici les étapes à effectuer
Créez autant d’intégration SQL que de valeur n-1 à traiter (dans mon pour le pH et le Red Ox)
Une intégration SQL doit remonter une seule valeur, un tris descendant par le timestamp metadata_id et un LIMIT 1,1 permet de cibler la bonne valeur. Le faire sur l’index ne protège pas des ajouts manuel
Ajoutez un délais minimum de 30s sur le trigger pour laisser le temps à HA de mettre à jour la BdD
Affichez plusieurs données en les appelant une par une dans la même action (ici un message)
Contrairement (je me répète) à from_state et to_state, ces données sont également accessible dans la console de développement pour vos tests.
Elles peuvent également être visualisées en graphique
Au top… Étrange que personne ai mis en avant cette méthode sur le forum anglophone… À moins que ce soit une fausse bonne idée ???
En effet, dès que les demandes sont plus spécifique SQL en effet ça ne manque pas.
Merci pour les liens, je vais les compulser à la recherche d’astuce pouvant m’aider.
Mon besoin était de remonter l’avant dernier état, presque partout ça renvoi vers l’usage de from_state et to_state
Au final, interroger directement la base est bien plus facile et me semble plus robuste et malléable.
Je trouve ça bizarre qu’on puisse pas (facilement) avoir les valeurs d’avant (l’avant dernier valeur ou bien celle d’hier a 19h par exemple ) d’un capteur dans HA !
Choix d’un nom ici OX 
