Règle ouvert / fermé

[MaxXx39]

Bonjour,
Je coince sur un problème d'ouverture/fermeture.

J'ai 2 portes de garages avec 1 capteur sur chaque portes.
Capteur 1
Capteur 2

Je souhaiterai que
SI 1 des 2 porte est ouverte pendant 30min,
alors envoi une notif sur telegram.

J'ai essayé avec le plugin état des ouvertures, mais il ne renvoi pas une valeur (0 ou 1 par exemple) il renvoi un texte.

Je ne sais pas comment gerer mes ouvertures...

[merguez07]

bonjour,
https://forum.eedomus.com/viewtopic.php?f=14&t=4805&p=44134&hilit=porte+ouverte#p44134

[MaxXx39]

Merci du retour,
Mon problème est surtout lié au 2 portes.

J'ai créé un Etat Porte de Garage
Valeur 1 Ouvert
Valeur 2 Fermé

Avec une règle Porte Ouverte
Si Capteur 1 devient = ouvert
OU Capteur 2 devient = ouvert
Alors Etat porte de Garage -> Ouvert

la Ok,

Mais pour le mettre en état fermé?

[opa95]

Bonjour Max
Avec une règle Porte Ferme
Si
Capteur 1 devient = Ferme
ET Capteur 2 est = Ferme
OU Capteur 1 est Ferme
ET Capteur 2 devient Ferme
Alors Etat porte de Garage -> Ferme

Chez moi ça marche

[merguez07]

Mais pour le mettre en état fermé?

Si Capteur 1 est = fermé
ET
si Capteur 2 est = fermé
Alors Etat porte de Garage -> Fermé

[MaxXx39]

Merci de de la proposition,
je vais essayé, j'y avais bien pensé mais sur la doc de merguez07 sur les règles :

Et/ou/et
A et (B ou C) et D

et je souhaitais plutôt
(A et B) ou (C et D)

Mais j'essai,
Merci!

[opa95]

Si tu mets seulement deux règles "est", ça va t'obliger à activer la règle toutes les minutes, si tu combines les "est" et les "devient" tu n'as pas besoin d'activer la règle explicitement : l'action est faite dès que l'une des conditions "devient" se produit, il n'y a même pas à attendre la minute.

[opa95]

J'ai testé la combinaison sur ma box, elle marche.
Je dispose de 6 pseudocapteurs logiques qui me permettent de tester les règles "ET" et "OU" avec n'importe quelle combinaison dans la règle (c'est commode).

[merguez07]

Si tu mets seulement deux règles "est", ça va t'obliger à activer la règle toutes les minutes, si tu combines les "est" et les "devient" tu n'as pas besoin d'activer la règle explicitement : l'action est faite dès que l'une des conditions "devient" se produit, il n'y a même pas à attendre la minute.

Pas tout à fait vrai,
le "est=" déclenche la règle si il y a changement d'état

Autrement dit si la porte est ouverte et qu'on le ferme
Porte est= F déclenche la règle

Sagissant d'une mise à jour d'un état qui, au final ne changera que si les portes changent de position,
Le test avec un "est=" suffit

[opa95]

Sagissant d'une mise à jour d'un état qui, au final ne changera que si les portes changent de position,
Le test avec un "est=" suffit

Exact ça marche aussi, je n'avais pas testé la solution simple.

[thrymartin]

le "est=" déclenche la règle si il y a changement d'état

t'es sur ?
le EST MAINTENANT oui, au changement de valeur, c'est un DEVIENT j'ai déjà assez râlé pour...
mais le EST contrôle l'état courant et en général s'utilise avec une règle horaire,
ou alors, lui, la, il a tort
viewtopic.php?f=18&t=5073

et celui la de eedomus aussi : dans le deuxième exemple (20, entre 13 et 25 pour capteur1 orange ?)
https://doc.eedomus.com/view/Exemples_Crit%C3%A8res

mais comme j'ai pas essayé, juste confirmer que EST se comporte comme EST MAINTENANT qui se comporte comme DEVIENT qui se comporte comme DEVIENT MAINTENANT
Seule différence : pas de critère horaire avec le MAINTENANT
c'est de pire en pire

[opa95]

t'es sur ?
le EST MAINTENANT oui, au changement de valeur, c'est un DEVIENT j'ai déjà assez râlé pour...
mais le EST contrôle l'état courant et en général s'utilise avec une règle horaire,
ou alors, lui, la, il a tort
viewtopic.php?f=18&t=5073

et celui la de eedomus aussi : dans le deuxième exemple (20, entre 13 et 25 pour capteur1 orange ?)
https://doc.eedomus.com/view/Exemples_Crit%C3%A8res
c'est de pire en pire

Je viens de retester la configuration "est"
Test1 est égal à 1
ET Test2 est égal à 1.
Alors Test -> 1

Lors de l'appui sur test1, il ne se passe rien
Dès l'appui sur test2 (ou dans l'ordre inverse) Test passe à 1 : la durée en seconde de Test est identique à celle de Test2.
Le "est" active bien la règle lors du changement d'état, au moins pour un capteur activé à la main; je n'ai pas essayé pour un vrai capteur d'ouverture.
Ca serait quand même bien d'avoir un tableau du comportement exact des diverses actions.

[merguez07]

Ca serait quand même bien d'avoir un tableau du comportement exact des diverses actions.

c'est un peu ce qu'il y a dans le document dans ma signature, mais je te l'accorde, ça reste perfectible

[clarinette49]

Perso je trouve qu'on est un peu limité du côté des équations logiques, je m'explique :
En logique câblée pas de pb ça réagit immédiatement selon le câblage logique que l'on fait.
Dans un automate programmable il en sera quasiment de même car l'automate scrute les entrées à une fréquence élevée.
Mais sur la box on sera limité par la fréquence de scrutation si on ne veut pas surcharger celle-ci.

[merguez07]

t'es sur ?
le EST MAINTENANT oui, au changement de valeur, c'est un DEVIENT j'ai déjà assez râlé pour...
mais le EST contrôle l'état courant et en général s'utilise avec une règle horaire,
ou alors, lui, la, il a tort
viewtopic.php?f=18&t=5073

oui je suis sur et la réponse donné dans le lien cité n'est pas tout à fait correcte
En tout état de cause le EST ne fonctionne pas comme le EST MAINTENANT

Je m'explique
Si LAMPE = ON puis passe à OFF
Si on a une régle sans déclencheur horaire
l'ordre de forçage d'état de LAMPE déclenche la régle
LAMPE EST EGAL à OFF valide la régle
Le critère LAMPE EST EGAL à OFF est valide tant que la LAMPE est sur OFF
Si on rappui sur la commande OFF de la LAMPE
l'ordre de forçage d'état de LAMPE déclenche la régle
LAMPE EST EGAL à OFF valide la régle
Le critère LAMPE EST EGAL à OFF est valide tant que la LAMPE est sur OFF


Si LAMPE = ON puis passe à OFF
Si on a une régle sans déclencheur horaire
l'ordre de forçage d'état de LAMPE déclenche la régle
Le critère LAMPE EST MAINTENANT EGAL à OFF est valide le temps d'un test
Si on rappui sur la commande OFF de la LAMPE
l'ordre de forçage d'état de LAMPE déclenche la régle
Le critère LAMPE EST MAINTENANT EGAL à OFF est valide le temps d'un test

En gros l'utilisation du EST et EST MAINTENANT en utilisation monocritère le résultat est identique

Par contre si la règle comporte deux critères non liés au même état (par exemple PORTE 1 EST EGAL à FERMé ET Porte2 EST MAINTENANT EGAL à FERMé :
- si on ferme la porte 2 la règle sera déclenchée et validée si la porte 1 est fermée
- si on ferme la porte 1 la règle sera déclenchée mais jamais validée quelque soit la position de la porte 2

[thrymartin]

Perso je trouve qu'on est un peu limité du côté des équations logiques.../...

En fait, on a tout un tas d'astuces pour contourner le problème, y a toujours une solution, ce qui est dommage, c'est que ce gourbi nécessite de savoir ce qui tourne rond ou pas rond pour ne pas partir sur des solutions semblant évidentes mais qui ne vont pas fonctionner...

Ca serait bien de corriger ça avant que de proposer une nouvelle box... On va dire que toute l'organisation des règles, macros, etc. est le 'langage' de l'eedomus
ben j'ai jamais vu un langage buggé : en fait, quand ça marche pas, ça vient toujours de nous, alors que la... non
d'un autre côté, ça fait vivre le forum

et dans tous les cas, la saturation du système est intrinsèque à la Box : j'en ai déjà parlé, tout le monde s'en ... comme d'hab, mais bon

pendant que toutes les 1 à 2 sec. la box elle même est interrogée, suite à une panne de courant, t'as tout un tas de truc qui se synchronisent, parce qu'ils démarrent tous en même temps
du coup, t'as plein d'appels en même temps et le pire c'est que ce qui sauve c'est la mauvaise gestion ou la mauvaise performance du z-wave qui n'est pas capable de faire ton rêve : comme en filaire, la réaction immédiate, alors peu à peu, ça se désynchronise... et ça aère un peu le travail de la box...

il y aurai pourtant une amélioration de la box à faire pour tout aérer dès le départ en désynchronisant tout ce qui peut l'être afin d'occuper des espaces de repos : optimiser serait plus intéressant que de promettre une nouvelle box ou un z-wave hyper +++
Pareil pour les couacs du z-wave : tu demandes toutes les 30' et ça va mettre plus de 30 sec à réagir, soit, ya les 3 essais puis c'est mort, faudra attendre les 30' suivantes : et c'est pas venu à l'idée que si ça atteint 32', donc que c'est mort, ça se relancerait au lieu d'attendre le créneau suivant ? (je parle des périf qui sont bien sur accessibles et pas ceux qui ont planté)

bon c'est dommage, mais on arrive peu ou pro à retrouver nos petits et faire fonctionner à peu près comme on l'entend, et même si ça console pas, ya pire...
mais ça serait bien qu'un jour ce soit abouti... et qu'on se demande pas si tel périf va répondre, si telle règle écrite apparemment logiquement va fonctionner, ou qu'on discute de la différence entre DEVIENT et DEVIENT MAINTENANT comme on discuterai du sexe des anges...

Bon, jj'ai besoin de vacances moi
ahah, justement, ça vient !

[thrymartin]

[quote="merguez07"][/quote]

Dans ton exemple le EST se redéclenche au renouvellement de valeur (c'est Off et tu rappuies sur Off) => ce que je cherchais à obtenir avec un EST MAINTENANT dont c'était en principe le rôle dans la description du premier lien.
Alors que le EST MAINTENANT se déclenche au changement de valeur, UNIQUEMENT (ça j'en suis sur à force de l'avoir torturé dans tous les sens pendant des jours = DEVIENT=DEVIENT MAINTENANT

tu disais la haut que le EST se déclenche au changement de valeur... donc c'est "entre autre"

Mais je note ce que tu dis : sans critère horaire, la règle EST ne boucle pas comme décrit dans le premier lien
ce qui est illogique note bien, si c'était un langage de programmation quelconque, ça bouclerait, si on n'y mettait pas un frein quelconque et la pile se remplirait, et ça planterait.
Mais au moins, utilisé correctement, ça remplirai sa fonction

La, comme je le dis à Clarinette, il faut ruser, puisqu'on appelle un chien un chat et faut leur faire croire qu'ils sont des pangolins ... oui oui, je sais, j'ai besoin de vacances

[merguez07]

tu disais la haut que le EST se déclenche au changement de valeur... donc c'est "entre autre"

oui la réponse était vis à vis de la situation évoquée mais si on veut être puriste on doit distinguer la notion de déclenchement de régle et le critère
En effet ce n'est pas le critère qui déclenche la règle mais un ordre de changement d'état (que l'état change ou non)
le EST valide ensuite le critère (ou pas)

[opa95]

Dans ton exemple le EST se redéclenche au renouvellement de valeur (c'est Off et tu rappuies sur Off) => ce que je cherchais à obtenir avec un EST MAINTENANT dont c'était en principe le rôle dans la description du premier lien.
Alors que le EST MAINTENANT se déclenche au changement de valeur, UNIQUEMENT (ça j'en suis sur à force de l'avoir torturé dans tous les sens pendant des jours = DEVIENT=DEVIENT MAINTENANT

tu disais la haut que le EST se déclenche au changement de valeur... donc c'est "entre autre"

Pour que ce soit plus clair, il suffit d'éliminer les "MAINTENANT" et de conserver les "EST" ou "DEVIENT" qui ont des comportements voisin, mais pas identiques (et c'est bien!).

ce qui est illogique note bien, si c'était un langage de programmation quelconque, ça bouclerait, si on n'y mettait pas un frein quelconque et la pile se remplirait, et ça planterait.

Parce que tu n'as pas pratiqué suffisamment la programmation événementielle qui va justement introduire les freins comme l'eedomus.

[thrymartin]

Parce que tu n'as pas pratiqué suffisamment la programmation événementielle qui va justement introduire les freins comme l'eedomus.

peuh ?
tu peux faire des erreurs de programmations en créant des boucles et ça va pas planter ?
ah j'ai du rater une marche, quel langage ?
dans la liste des langages evenementiels, j'en connais quelques uns, et on peut largement les faire planter si on code avec les pieds

(ça intéresserait aussi les programmeurs de mon logiciel pro puisque j'ai trouvé un bug qui le fait boucler au point ou le processeur est tellement occupé que c'est difficile de l'arrêter même avec le gestionnaire de tâches)