Programmation

Oui c’est prévu un nom pour les lignes de programmation.

Bonjour,

Une petite question par rapport à la programmation également:

J’ai programmé une alerte email lorsqu’une sonde de température extérieure est inférieure ou égale à 1°C. Le problème est que je suis arrosé d’emails en ce moment car le froid est là…

Pour se sortir du problème, il faudrait une sorte d’hystérésis sur l’alerte en utilisant un switch virtuel. Le problème c’est qu’il faudrait pouvoir avoir une condition double (ET logique) entre la température réelle, et le switch virtuel.

A moins que quelque chose m’ait échappé…

Bonsoir,

tu peux utiliser un switch virtuel (sw) si la température est inf à 1°C et mettre en action  » on au bout de tempo », moi j’ai mis 120 s et tu testes sur une 2e commande le switch virtuel et tu envoies un mail si sw=1.

• Cette réponse a été modifiée le il y a 5 années et 10 mois par ProfT.

Bonjour,

Vous pouvez effectivement gérer des alertes en utilisant des SW de cette manière par exemple pour 3 types d’alerte :

Si tempExt < 1° >>>> Sw1 = ON tant que condition vrai            // Température extérieur < 1°
Si InpFeu = ON >>>> Sw2 = ON tant que condition vrai           // Détection incendie sur Input 1
Si InpAlarm = ON >>>> Sw3 = ON tant que condition vrai       // Détection Intrusion Alarme sur input 2

Si SW1 == ON >>>> Envoie Mail « Warning ! Temp extérieur < 1°… »   >>>> actif suivant SW7 = OFF     // si aucun mail déjà envoyé
Si SW2 == ON >>>> Envoie Mail « ALERT FEU : feu détecté … »        >>>> actif suivant SW7 = OFF     // si aucun mail déjà envoyé
Si SW3 == ON >>>> Envoie Mail « ALERT Alarme : Intrusion …. »      >>>> actif suivant SW7 = OFF     // si aucun mail déjà envoyé

Si SW1 = ON >>>> SW7 = ON si condition vrai pendant tempo 10s     // Tempo à régler pour laisser le temps d’envoi de 1 ou 2 mail
Si SW2 = ON >>>> SW7 = ON si condition vrai pendant tempo 10s    // Tempo à régler pour laisser le temps d’envoi de 1 ou 2 mail
Si SW3 = ON >>>> SW7 = ON si condition vrai pendant tempo 10s    // Tempo à régler pour laisser le temps d’envoi de 1 ou 2 mail

Vous pouvez autoriser la Relance des Alertes Mail soit en Auto au bout d’une tempo longue comme ceci

Si SW7 = ON >>>> SW7 = OFF si condition vrai pendant tempo 600s    // On Relance les mails d’alertes au bout de 10mn par exemple

Ou bien Manuellement depuis votre portable si vous avez un accès au WES de l’extérieur via votre BOX, vous pouvez envoyer une requête HTTP  Wifi pour remettre SW7 à OFF pour autoriser de relancer les messages d’alerte

Cdt

Merci pour vos indication très utiles.

Je vais essayer de jouer avec les délais et les switches, mon idée étant de déclencher une alerte e-mail quand la température descend en-dessous de 1°C, sans envoyer d’autre e-mail tant que la température reste en-dessous, jusqu’à ce que le température remonte au-dessus de 2 ou 3°C, quitte à envoyer un e-mail de fin d’alerte.

Ça me parait très faisable.

Oui c’est faisable

Votre programmation peut être le suivant. Il faut utiliser 2 Switchs Virtuel. Les SW1 et SW7 de mon exemple peuvent être changé bien sur.
Par contre il faut bien respecter tous les tests d’état > actif suivant SWx = xx suivant les lignes > sinon cela bloquera suivant les cas

Si tempExt < 1° >>>> SW1 = ON tant que condition vrai                                                                                    // SW1=1 si Temp < 1° sinon SW1=0
Si SW1 == ON >>>> Envoie Mail « ALERTE ! Temp extérieur < 1°… »   >>>> actif suivant SW7 = OFF     // Envoie mail ALERTE Temp
Si SW1 == ON >>>> SW7 = ON au bout de tempo 1s  >>>> actif suivant SW7 = OFF                                    // Verrouille l’envoie de nouveau mail
Si SW1 == OFF >>>> Envoie Mail « FIN ALERTE Temp extérieure OK.. »  >>>> actif suivant SW7 = ON    // Envoie mail Fin Alerte temp
Si SW1 == OFF >>>> SW7 = OFF si cdt vrai pendant tempo 1s  >>>> actif suivant SW7 = ON                      // Déverrouille l’envoie des mails

Par contre j’ai trouvé un petit bug dans la page programme qui doit être corrigé si vous le constatez aussi.
Si dans la page Programme, en bas à droite dans la zone « Actif suivant switchs Virtuel« , vous constater que le texte « Toujours Actif ! » se trouve en dehors de la liste de sélection du Choix des SWx, que ce texte est visible lorsque la liste est fermée, vous pouvez corriger le bug.

Normalement le texte « Toujours Actif ! » doit se trouver dans la liste en 1ere ligne dans la liste de sélection des SW, au dessus de SW1. C’est la sélection par défaut en cas de non utilisation des SW « actif suivant .. »

Si le 1er élément de la Liste commence par SW1, il y a alors un décalage dans le choix du SW de -1. dans l’exécution du programme  ex: un test défini sur SW2 sera décalé de -1 et le test sera actif sur SW1 par le programme au lieu de SW2.

J’ai envoyé le correctif à Nicolas

Correction à apporter à partir de la Ligne 164 du fichier PROGRAM.HTM de la microSD

avant modif :
 
 <select class= »form-control » id= »virtuel_2″ />
 <option value=0>Toujours actif !</option>

Aprés modif : modif fin de la 1er ligne et ajout </select> en 3eme ligne

<select class= »form-control » id= »virtuel_2″ >
    <option value=0>Toujours actif !</option>
 </select>

Cdt

Bonjour c’est très faisable je l’ai fait pour des intensités je coupe au delà d’un seuil et je réenclenche en deçà d’un autre seuil avec un delta suffisant pour que ca ne batte pas…

Il faut passer par un SW utilisé en BISTABLE .

SW1 sert de bistable avec une condition de set sur température minimale et une condition de reset sur temperature d’annulation.

Le bistable avec SW1

Si tempExt < 1° >>>>  sortie SW1 = ON  ou  ON si cdt vrai pendant tempo X seconde (cela permet de filtrer les passages non définitifs)

Si tempExt > T° Max° (ex:5°) >>>> sortie SW1 = OFF ou OFF si cdt vrai pendant tempo X seconde (cela permet de filtrer les passages non définitifs)

Pour avoir ON SW1 il faut passer en dessous de 1° et pour qu’il repasse a OFF il faut que l’on repasse  au dessus de 5°

ensuite il faut récupérer le SW pour l’EMAIL

Si SW1 état = ON >>>> email « blablabla ALERTE »

Si SW1 état = OFF >>>> email « blablabla FIN ALERTE »

ATTENTION PAS ON TANT QUE qui enverrait les EMAILS en Permanence mais ON qui ne le fera q’une fois lors du passage a ON et inverse pour la fin d’alerte sur le OFF

et voila le tour est joué

on peut remplacé la température par tout ce que le a besoin avec hystérésis (surveillance intensité, puissance…..)

Slt

bon usage

si vous faites

Si SW1 état = ON >>>> email « blablabla ALERTE »

Si SW1 état = OFF >>>> email « blablabla FIN ALERTE »

Rien n’arrêtera l’envoie de mail en rafale dans votre exemple. SW1 sera soit ON ou OFF et un mail associé sera envoyé les uns après les autres suivant  la condition de SW1.

C’est pourquoi il faut faire jouer un 2eme SW de verrouillage afin qu’un seul mail soit envoyer et bloquer les autres tentatives. Ce 2eme SW doit être monté sur le Test SW1 mais avec un léger retard par rapport au test SW1 de l’envoie du mail. Ceci pour éviter d’avoir le verrouillage d »envoie des mails en même temps que la demande d’envoie de mail. Un léger retard de 1s suffit.

Le 2éme SW de verrouillage servira comme 2éme condition de test pour l’envoie des mail via l’option « Actif suivant SW « .  Cela fonctionne comme ceci >> SI SW1 = ON >>>>  email « blablabla ALERTE » uniquement si le SWx de verrouillage = OFF,  puis 1 seconde après on positionne SWx à ON pour bloquer tout autre envoie de mail sur le test SW1 = ON, on fait l’inverse pour la fin Alerte avec SW1 = OFF.

Mon exemple donné ci-dessus fonctionne parfaitement bien.

Attention par contre il faut corriger le bug dans le Fichier PROGRAM.HTM  comme spécifié dans mon dernier POST.  Nicolas prétend que le PB n’est pas visible dans Chrome,  mais avec Firefox, IE et autres le pb est bien présent. Je pense que Nicolas va implémenter cette correction dans sa prochaine release.

Il faut ouvrir et éditer le fichier program.htm avec un éditeur de texte et enregistrer le fichier après modification. Il faut faire ensuite CTRL+F5 avec le navigateur pour effacer le cache du navigateur afin de prendre en compte la modif du HTM.

Cdt

Cdlog,

Mon exemple fonctionne à merveille j’ai des Emails sur conditions On dans le genre et même des alarme LCD (rouge).

le  = On ne le fait que lors de la « transition passage du OFF au ON » et non en permanence qui est pour cela le ON tant Que.

J’ai des surveillances multiples qui envoi des Emails sur condition = On,  JE NE RECOIT qu’un SEUL MAIL!

Je vous invite a essayer

A+

En général ne n’insiste pas  mais !

Programmer cette simple ligne :

Si  SW7 == ON >>>>> SW8 = ON  .

mettez SW7 et SW8 a OFF manuellement puis mettez SW7 = ON. SW8 va bien sur passer à ON.

Par contre sans toucher à SW7=ON, essayez de mettre SW8 = OFF manuellement,  vous verrez que vous aurez beau remettre SW8 = OFF > SW8 repassera en auto à ON et ceci tant que SW7= ON.  Donc on voit bien que SW8 monte = ON par l’état de SW7 = ON et non par la transition de SW7 de OFF vers ON comme vous le dites

Si le test était une transition comme vous le dites,  alors SW8 ne reviendrait pas à ON en auto si mis manuellement à OFF pendant que SW7=ON

Le test sur == ON simple est bien un test d’état et non un test de transition comme vous le supposez. Le test On au bout tempo peut par contre être assimilé à un changement par une transition.

Cdt

Cdlog

Je pensais comme vous et j ai essayé pour l email.

Et la je vous assure la condition est bien On et un seul mail….

Exemple d une des lignes congélateur est sur l entrée capteur 2 (j ai un relais nf sur le 220v congélateur avec le contact sec sur capteur 2) si 220 le nf est ouvert est si perte 220 le nf est fermé.

La programmation est

Congélateur état  = ON sortie email alarme 220v congélateur.

Le mail part bien si j ouvre le fusible (test) mais une seul fois j ai laissé plus de 2 minutes un et un seul mail …..

Pour les relais les sw la je suis ok avec CI dessus…

Il doit y avoir un quelque chose qui nous échappe. …pour le mail….

Nicolas doit pouvoir répondre

Ok je vous suis sur le sujet. Je n’ai pas essayé l’envoie de Mail donc je ne peux que me remettre à votre expérience.

Je pense que l’on peux expliquer le pourquoi du comment. Il suffit d’interpréter quelque peu la logique de Nicolas.
On peut supposer que chaque ligne de programme est constituée d’une structure commune définie pour chaque lignes de Prg.
Dans cette structure on devrait trouver divers Flags dont pour les plus utiles pour la gestion des Actions :

Flag Status : permet de connaître l’Action en cours : noactive , isactive
Flag TypeProcess : permet de connaître le type du process de l’objet définie en action : Circle, StopOnce, TimerCount
Flag TypeObjet : permet de connaître le type d’objet mis en oeuvre dans l’action soit : SW, Rl, mail, requête etc
Flag ActDone : permet de savoir si l’action est active si True ou pas encore active = False.
Var valTimer : Valeur d’une tempo si déclaré pour valider l’action

et certainement pleins d’autres variables ou flags spécifiques.

Donc déjà on peut élaborer des scénaries : 2 états possibles concernant la comparaison sur la source : ScrCompar = False ou True

Les lignes sont scrutées de façon cycliques ligne par ligne. Pour chaque ligne on teste la comparaison sur la Source.
Si SrcCompar = False, on positionne le Status de l’action à noactive, ActDone = False et on passe à la ligne suivante.

Si ScrCompar = True, On commence par tester le Status de l’Action. si Status = noactive on sait que l’action n’est pas encore activée et que l’on est en phase d’init. Donc on initialise certains Flag, en autres on met le compteur ValTimer = 0 et on passe le Status à isactive.
Ensuite on lance la procédure défini par le TypeProcess avec le TypeObjet en argument.

C’est dans cette procédure que l’on va déterminer si l’objet est un TypeProcess Circle, StopOnce, TimerCount.

On comprend que le TypeProcess TimerCount, va lancer un décompte sur un Timer pour ensuite activer l’action suivant le type Objet et mettre ActDone = True. On reste dans cet état tans que ScrCompar = True

Le TypeProcess Circle permet de réagir en boucle >> c’est le cas de notre SW8 = ON si Source SW7 = ON > SW8 revient en auto en ON en boucle

Pour terminer arrive le TypeProcess StopOnce. C’est notre action Mail. En effet je suis certain que Nicolas fait une analyse particulière pour les Mails et les Requêtes mis en Action. C’est pourquoi, lorsque le Mail à été envoyé, ActDone passe à True et il doit y avoir une discri du genre :

Si Status = isactive et ActDone = True et si TypeProcess = StopOnce > alors on ne réagit plus.

C’est une explication comme une autre, mais je suis certain qu’il y a une gestion Spécifique pour les Actions Mails et Requêtes. en plus cela semble Logique d’envoyer 1 seul Mail relatif à un test Positif d’une Source.

Seule un ScrCompar = False sur la Source permettra de réinitialiser les Flag Actions et autoriser de relancer un Mail dès que ScrCompar = True.

Cdt

J’ai bien lu vos suggestions, et ça m’a incité à observer le comportement du WES pour mieux le comprendre. Voici ce que j’ai observé sans utiliser ni le « tempo » ni « tant que c’est vrai » dans la programmation, mais seulement les actions de programmation « ON » ou « OFF »:

– Lorsqu’un switch virtuel est actionné par une condition de température qui devient vraie, l’état de ce switch est permanent et ne peut pas être modifié manuellement tant que cette condition de température reste vraie.
– Si cette condition de température n’est plus vraie, ce switch virtuel reste inchangé tant qu’une autre action ne vient pas le faire changer d’état (une autre ligne de programmation, ou un changement manuel qui devient alors possible).
– Lorsque le passage de ce switch virtuel de OFF à ON ou de ON à OFF conditionne l’envoi d’un email, cet email n’est envoyé qu’une seule fois uniquement lors de cette transition, ce qui est une bonne chose.

Ces observations faites, il m’a semblé qu’il n’était pas utile d’utiliser 2 switches virtuels, mais un seul, et les 4 lignes de programmation suivantes semblent bien fonctionner pour ne plus recevoir plusieurs email lorsque la température oscille autour d’un seuil de déclenchement:

Si Temperature <= 1°, alors SW_1 = ON  (pas de tempo, et option « toujours actif »)
Si Temperature >  3°, alors SW_1 = OFF (pas de tempo, et option « toujours actif »)
Si SW_1 = ON, alors envoi email « Risque de gel »  (option « toujours actif »)
Si SW_1 = OFF, alors envoi email « Fin de risque de gel »  (option « toujours actif »)

Pour résumer le comportement du switch virtuel:

– En dessous de 1°C, SW_1 = ON forcé
– Entre 1 et 3°C, SW_1 garde la valeur précédante
– Au-dessus de 3°C, SW_1 = OFF forcé

Ça me semble être simple, et dans mon cas ça fonctionne:

– 1 seul mail reçu lors de la baisse de la température malgré les petites variations autour du seuil de 1°C.
– 1 seul mail reçu lors de la remontée de la température à 3°C malgré les petites variations autour de 3°C.

A mon avis, l’utilisation du paramètre « tempo » n’a pas d’utilité dans ce cas.

Pour ce qui est de la surveillance des consommations électriques ceci n’est pas applicable, car les consommations ont des variations importantes non progressives, et les mesures sont bien plus fréquentes. L’utilisation du tempo est alors très probablement nécessaire pour limiter le nombre d’alertes.

Je vais continuer une observation sur une plus longue période, mais pour l’instant ça a l’air de marcher. Dans ma programmation d’origine qui me posait problème, je n’utilisais pas de switch virtuel, mais une seule ligne de programmation sans hystérésis (hystérésis = 2 seuils), avec pour effet des emails en abondance (mais pas des centaines non plus).

• Cette réponse a été modifiée le il y a 5 années et 10 mois par rene38.
• Cette réponse a été modifiée le il y a 5 années et 10 mois par rene38.

rene38

c’est ma proposition plus haut ok c’est parfait

Pour la tempo j’ai bien précise que ce n’est que pour « filtrer » les passages fugitifs.

Sans tempo dès que tu passe en dessous pour le ON et au dessus pour le OFF le SW change d’état meme si ce passage ne dur que quelques dixieme de seconde alors qu’avec la tempo cela assure que c’est bien « permanent ».

Pour les consommations ca fonctionne très bien sous reserve de mettre un hystérésis significatif par exemple pour la puissance au moins 2 a 3 KW d’écart (en fait il faut réfléchir aux consommateurs et tenir compte de leur consommation en plus ou en moins). et mettre une tempo assure la aussi que ce n’est pas fugitif. Pour moi c’est Ok je surveille avec le TIC Pmax et I sur les trois phases pour délester tel ou tel consommateur….

A+

A

• Cette réponse a été modifiée le il y a 5 années et 10 mois par plruffin.
• Cette réponse a été modifiée le il y a 5 années et 10 mois par plruffin.

Oui, tout à fait d’accord, sauf que je n’avais pas bien assimilé le processus de fonctionnement du WES que j’ai détaillé.

En ce qui concerne l’observation des consommations, tout dépend du type d’alerte qu’on souhaite mettre en place.
Dans mon cas, c’est lorsque ma puissance globale consommée dépasse mon abonnement… Ça m’arrive en hiver car je suis tout électrique, et comme je n’ai pas (encore) de Linky, je souhaite être alerté afin de mettre en place le meilleur délestage possible, ce que je n’ai pas encore fait (le délestage du tableau électrique existant n’est pas suffisant). Ainsi, si le Linky est incontournable, je serai prêt, et on ne me forcera pas à passer à l’abonnement supérieur. J’ai déjà 12 kVA, c’est à dire 50 A maxi.

Rene38

12kvA c’est 60A. je suis en 12kVA tri et tempo presque tout électrique , habitant en montagne j’ai du bois et une bonne cheminé.

Si tu programme des SW en bascule RS (set et reset) sur des conditions  ayant de l’hystérésis ca fonctionne très bien.

Désolé, mais ici j’ai 240V, parfois même jusqu’à 244V, mais pas 220V, je suis à 300m du transfo abaisseur de tension.
L’abonnement est en kVA.
240 x 50 = 12 000 watts
C’est donc bien 50 A dans mon cas

CQFD 😉

Je souhaite préciser une chose: la lecture Téléinfo de mon compteur EDF indique bien: « Intensité souscrite: 60A ». Cependant, sur chaque facture EDF, il est indiqué que le contrat souscrit est pour 12 kVA. Cette valeur est inscrite sur chaque facture depuis plusieurs années. Des discussions sur un autre forum montrent que c’est cette dernière valeur en kVA qui est prise en compte en cas de dépassement.
Du coup, j’ai modifié ma programmation d’alerte de surconsommation non pas sur l’intensité, mais sur la puissance calculée par le WES issue de la mesure réelle de tension et du courant global. D’autant que lorsque tout le monde consomme en même temps en soirée par temps froid, la tension secteur baisse aux alentours de 236V au lieu de 240V (ou plus) en journée.

Dernière remarque concernant les alertes de températures extérieures dont il est question plus haut (alerte en cas de gel):
Maintenant que cette programmation avec le WES est mise en place, je constate que lorsque la condition d’alerte sur le switch virtuel est vraie à minuit (température <= 1°C), l’email programmé en action est envoyé une deuxième fois après la vraie alerte. Comme si les switches virtuels étaient remis sur OFF à minuit. Est-ce un bug ?

Effectivement c’est bien 60A car EDF considère la tension nominale de 220V !!!

personnellement comme vous je surveille la puissance effective du Linky au travers des variables TIC du WES, comme la tension n’est pas de 220V cela prend en compte son écart et évite des mauvaise surprises.

pour les intensités quand je le fait je suis loin des nominaux , c’est du délestage local par phases

Pour le SW et l’email aucune idée mais votre hypothèse tiens la route , réponse précise voir Nicolas.

A+

• Cette réponse a été modifiée le il y a 5 années et 10 mois par plruffin.

Concernant les alertes inutiles tous les jours à minuit, j’ai l’impression que ça vient du fait que la programmation en question est valide tous les jours de 00:00 à 23:59 (on ne peut pas écrire 24:00), et de ce fait la condition sur le switch est perdue entre 23:59 et 00:00, ce qui lance une alerte. J’ai donc une alerte intempestive tous les jours à minuit, soit à cause de la condition de risque de gel, soit à cause de la condition sur la fin de risque de gel…
Un « avis avisé » serait utile.

Bonjour,

Que lisez vous comme info en fin de vos lignes dans la liste historique en haut de vos programmations.

Normalement pour le champ « plages horaire » vous devriez lire 00:00 à 00:00 le tjl, soit début heure = 0 et fin heure = 0 et ceci tous les jours, bien sur si vous le souhaitez programmé ainsi. Tout autres valeurs sera effectivement pris en compte.

Normalement si les heures Début et heure Fin sont bien de 00:00 à 00:00, le WES prend ces infos pour nulles et ne tiendra pas compte de la programmation horaire. Ceci était vraie pour les anciennes Releases. Comme je ne suis pas en version 0.83H, je ne peux vous dire si cela à changé sur cette dernière version, mais à mon avis non ?

Pour une programmation sur 24h, vous avez le choix entre 00h00 à 23h59 ou 00h01 à 00h00.

Donc si vous lisez 00:00 à 23:59 et que ce ne soit pas de votre fait, alors modifier la les ligne(s) et forcer les champs à deb 00:00 fin 00:00 tous les jours puis validez et transférez.

J’en profite pour vous demander, que lisez vous comme 1er élément dans la liste déroulante « Actif suivant switch Virtuel » quand vous l’ouvrez ?
Si vous lisez « SW 1 » comme 1er élément des sélections possible alors vous êtes concerné par le bug que j’ai décris en début de ce Fil et il faut effectuer la modif dans le fichier PROGRAM.HTM comme je l’ai décrit. Cette modif sera implémentée dans la nvelle release par Nicolas en principe.

Par contre si la liste déroulante commence par « Toujours actif », suivi de « SW 1 », « Sw 2 », « Sw 3 » etc alors c’est ok chez vous.

cdt

Effectivement, les plages horaires de mes programmations sont: « 00:00 à 23:59 le Tlj ».
J’ai mis ces valeurs pensant bien faire, car dans mon esprit c’était la plage maxi qu’il fallait mettre, sauf que la valeur maxi était 23:59, et non 24:00.
Je ne savait pas que « 00:00 à 00:00 » était possible, et c’est bien cette programmation qu’il me faut. Je viens de corriger.
Merci beaucoup pour votre aide.

Pour répondre à votre seconde question:
La valeur du champ  « Actif suivant switch Virtuel » est: « Toujours actif », donc pas de problème pour moi.

Merci encore!