[ RESOLU ] comprehension callback python

[iznobe]

Bonjour , je reviens a la charge sur un petit detail qui me titille depuis un moment .

un exemple pour essayer d ' expliquer au mieux mon probleme de comprehension .

Quand je fait :

Code: Select all

def my_callback (pin_flotteur) : 
    state = GPIO.input(pin_flotteur)
    print(state)

GPIO.add_event_detect(pin_flotteur, GPIO.FALLING, callback=my_callback, bouncetime=1000)

logiquement , la fonction " my_callback " est apelle uniquement si un etat low sur le pin pin_flotteur est detecté non ?

pourquoi donc est ce que j ' obtiens un affichage continu toutes les secondes de l ' etat du pin alors que le pin est continuellement en etat HIGH ???
en sortie j ' ai :

Code: Select all

1
1
1
1
1
1

ca coince la c ' est une boucle ou une detection d' evenement ???

[JumpZero]

logiquement , la fonction " my_callback " est apelle uniquement si un etat low sur le pin pin_flotteur est detecté non ?

NON: la fonction est appellée à chaque changement d'état de l'état haut à l'état bas. C'est "FALLING"
"RISING" fait l'inverse, il y a encore "BOTH", "LOW" et "HIGH" dont les noms suffisent à décrire ce qu'ils font.
En fait les interruptions sont une fonctionnalité extrêmement puissante et pratique et c'est juste génial que le Pi puisse les gérer sur tous ses GPIO.
En gros une interruption c'est un petit programme (une fonction) qui doit être très courte (rapide) et dont tu donnes l'adresse au processeur. Quand l'événement prévu (FALLING dans ton cas) arrive le processeur stop la tache en cours pour aller exécuter ce programme (c'est pour ça qu'il doit être court et rapide pour que le processeur puisse rapidement retourner à sa tache principale).
En fait dans ton cas pourquoi ça ne marche pas, la réponse est je ne sais pas, mais je peux te donner plusieurs pistes.
Déjà ça peut-être le hard, ensuite tu n'as sans doute pas besoin d'utiliser une interruption, enfin pas dans un premier temps. Pour ma part je suis fan des interruptions mais c'est sur que c'est plus pointu qu'une boucle de lecture permanente (le polling).
Je te conseille donc de faire un bête câblage avec un bouton poussoir sur un gpio quelconque comme il y a plein d'exemple sur le web et de vérifier que ça fonctionne bien (lire 0 quand le BP n'est pas appuyé et 1 quand il est appuyé [ou l'inverse étant donné que tu peux l’inverser en hard et en soft autant de fois que tu veux, pas important, ce qui est compte c'est que ça change et reste bien dans l'état attendu])
Ensuite en python tu fais un programme de lecture permanente de l'état du GPIO avec une boucle sans fin, mais en introduisant un petit délai (un sleep) autrement c'est trop rapide, disons 0,1 seconde)

Code: Select all

Boucle sans fin (Ctrl-C to stop)
    print(etat(gpio))
    sleep un certain temps

Et là tu testes, l’écran se rempli de 0, tu appuies sur le BP c'est des 1, tu relâches c'est des 0 (ou l'inverse, hein! pas de pb)
Et avec ça tu devrais en avoir assez pour faire ton programme (à toi de gérer (et/ou mémoriser) le changement d'état et d'agir en fonction)
Maintenant si tu veux vraiment utiliser les interruptions, tu peux, il faut savoir que un switch mécanique quand il est actionné fait des rebonds (bounce) il ne passe pas de 0 à 1 franchement mais fait 0, 1, 0, 1, 0...1 ceci très rapidement, imperceptible pour nous autres humains mais le processeur vois très bien ces rebonds. On peut les supprimer en hard (ajouter un condensateur) et/ou en soft (le paramètre bounce) dans tous les cas il faut faire des essais et trouver les bons réglages.
Voilà j'ai encore été trop long, mais en résumé vas-y doucement, par étapes, du plus simple au plus complexe en comprenant ce que tu fais à chaque étape.
Pythone bien

[iznobe]

Salut et merci pour ta reponse claire mais longue

Effectivement je me suis mal exprime , mais comme dans mon code je demarre a un etat haut , effectivement ce que vous dites est exact .

Donc vous me confirmez bien que la fonction n ' est execute uniquement dans le cas d' un falling ( passage d' un etat haut a bas ) ,
et que le comportement que je constate chez moi ( se comporte comme une " simple boucle " ) n ' est pas normal ?

Dans le code suivant , est ce que les commentaires , parraissent correspondre a ce qui se passe rellement ?

est ce que le code parait logique ?

la fonction de callback n ' est - elle pas trop longue ?

Code: Select all

#! /usr/bin/python
# coding: utf-8

import os
import RPi.GPIO as GPIO
import time
from datetime import datetime

GPIO.setmode(GPIO.BCM) # board = emplacements physiques , BCM emplacements logiques du proc

# les pins 15 , 8 , 36 sont inutilisables ...
# lorsque le flotteur est en position normale ( basse ) , le contacteur est alimentee et permet aux pompes et aux electrovannes 
# de gerer le systeme automatiquement, le PI recoit un signal LOW sur son PIN car relie a la masse .
# En cas de fuite , le flotteur passe en position haute , le contacteur n ' alimente plus les pompes et electrovannes du local technique 
# afin de limiter les degats du a la fuite d' eau . le PI recoit un signal HIGH car le PIN est placé en pull UP .
# reellement le PIN n ' est plus connecte a rien car le contacteur est ouvert justement !

#global pin_flotteur
pin_flotteur=27
GPIO.setup(pin_flotteur, GPIO.IN, pull_up_down=GPIO.PUD_UP) # en mode entree Tout Ou Rien

#GPIO.setup(GPIO_LEFT, GPIO.IN, pull_up_down=GPIO.PUD_UP)
# On se met en pullup, l'état du GPIO est donc à 1 par défaut, on détectera un appui lorsqu'il passe à zero (et donc FALLING) ,
# donc il faut cabler sur masse quand contact , quand il n ' y a pas de contact on reste en etat HIGH par defaut du au pull_up.

# Fonctions
def ecrire_log ( message , date ) :
    #fichier = open("/home/pi/projets_auto/logs/envoi_mail_auto.log", "a")
    
    log = (message + "\n")
    if date == 1 :
        now=(datetime.now().strftime("le %d/%m/%Y a : %H:%M:%S , "))
        log = (now + message + "\n")

    #fichier.write(log)
    #fichier.close()
    
    print(log)

    
########################################################################
def my_callback (pin_flotteur) : # gestion des actions en fonction de l ' etat du PIN d' entree
    
    GPIO.remove_event_detect(pin_flotteur) # on évite un autre appel pendant qu'on traite celui déjà présent
    time.sleep(1) # ici on fait un debounce : on attend 1s pour confirmer ou non l'appui
    state = GPIO.input(pin_flotteur) # lecture etat de l ' entree
        
        # Si on est toujours dans l' etat bas apres detection du falling , le changement d' etat est confirme , donc on agit.
    if not state : # permet de faire les actions une seule fois par cycle de montee descente flotteur grace au time.sleep dans la boucle while
             #sendmail()
        os.system ('python /home/pi/projets_auto/python/mail.py') # envoi du mail
        ecrire_log("le flotteur est passe en position haute",1)
        #state = GPIO.input(pin_flotteur)
    
    while not state : # on attend le retour du contacteur.
        ecrire_log("on attend le retour a l ' etat normal du flotteur",0)
        time.sleep(5) # on attend le retour a l ' etat normal du flotteur
        state = GPIO.input(pin_flotteur) # lecture etat de l ' entree
        if state : # le flotteur est repasse en position basse , donc le contacteur fait contact et remet le pin a 0
            ecrire_log("le flotteur est en position normale : basse",1)
                
    GPIO.add_event_detect(pin_flotteur, GPIO.FALLING, callback=my_callback, bouncetime=1000)
        # on remet la détection maintenant que le traitement a été fait
                
########################################################################

GPIO.add_event_detect(pin_flotteur, GPIO.FALLING, callback=my_callback, bouncetime=1000) # GPIO.FALLING GPIO.BOTH GPIO.RISING  , callback=my_callback
ecrire_log ("Initialisation sur le pin : " + str(pin_flotteur),1)

while True :
    time.sleep(1)

gpio.cleanup()

La fonction de log est plus la pour servir de debugguer , en exploitation , je commenterai tous les appels a cette fonction

j ' ai cable de la sorte : GPIO => resistance 470 kohms => contacteur en NO => retour masse .
j ' ai des problemes souvent de faux positifs le cablage ( fils telephonique cuivre monobrin ) aller retour a une longueur d ' environ 150 metres .

par la suite j ' aurais une autre question plus ardue , mais pas vitale ( maintenant que j ' ai trouve la parade ) .

j ' aime bien comprendre ce que je fais et etre capable de pouvoir maintenir et ameliorer mon code si besoin .

l ' interruption n ' est pas indispensable pour le moment mais je compte ajouter des fonctions petit a petit .

Encore merci pour ton aide !

[ernesto]

Bonjour

j ' ai cable de la sorte : GPIO => resistance 470 kohms => contacteur en NO => retour masse .
j ' ai des problemes souvent de faux positifs le cablage ( fils telephonique cuivre monobrin ) aller retour a une longueur d ' environ 150 metres .

1) Il doit s'agir de 470 ohm et non pas 470 kohm.
2) Effectivement les faux positifs sont dus à la longueur de câble. L'entrée gpio est instable et vous allez capter France Inter (des parasites).
Ou pire encore , dés que le temps sera orageux vous allez capter des parasites de tensions élevés , qui vont détruire l'entrée gpio voir le RPI.

J'ai réalisé un projet comparable au votre, de boite aux lettre "connectée" (mail + sms lorsque le facteur ouvre la trappe) . Voila le schéma pour connecter le contacteur au gpio:. J'ai parfois par temps orageux des faux positifs.


3) Coté logiciel: Je suis proche de votre solution mais plutôt que d'utiliser :
GPIO.add_event_detect(pin_flotteur, GPIO.FALLING, callback=my_callback, bouncetime=1000)
je préfère l'instruction suivante qui est beaucoup moins gourmande en ressource CPU .Le prog est stoppé puis débloqué lors de l'événement, pas besoin de boucle while pour rien faire (consommatrice de ressource CPU)
GPIO.wait_for_edge(intPin, GPIO.FALLING)

Comme le conseil JumpZero il faut d'abord mettre au point le prog "sur table" avec un BP et des longueurs de fils raisonnable (max 1 m).
Puis s'attaquer au problème de la longueur du câble.
Bon courage.

[JumpZero]

il faut d'abord mettre au point le prog "sur table" avec un BP et des longueurs de fils raisonnable (max 1 m).
Puis s'attaquer au problème de la longueur du câble.

+1 avec @ernesto effectivement 150m c'est beaucoup.
l'optocoupleur est une bonne solution.
C'est un contact (contact NO) que tu utilises sans doute et non pas un contacteur qui est un organe de puissance

[iznobe]

il faut d'abord mettre au point le prog "sur table" avec un BP et des longueurs de fils raisonnable (max 1 m).
Puis s'attaquer au problème de la longueur du câble.

+1 avec @ernesto effectivement 150m c'est beaucoup.
l'optocoupleur est une bonne solution.
C'est un contact (contact NO) que tu utilises sans doute et non pas un contacteur qui est un organe de puissance

Bonjour , j ' ai fait des test du prog avecun BP manuel : un chint tout simplement , entre la masse , la resistance et le pin , ce qui simule le BP .

j ' utilise bien un contact NO d ' un contacteur a 4 sorties NO et NF .
mais ca ne change rien , ca simule un contact manuel ou un BP , le resultat est le meme , le contact est etabli ou pas selon les cas .

lorsque je fais des test manuels cela fonctionne sans probleme .

reste ce soucis des faux positifs et le fait que j ' ai du faire une commande shell pour lancer un autre script python dans python car sinon j ' avais une erreur de segmentation ( voir ici ) pour plus d' info .

[iznobe]

1) Il doit s'agir de 470 ohm et non pas 470 kohm.
2) Effectivement les faux positifs sont dus à la longueur de câble. L'entrée gpio est instable et vous allez capter France Inter (des parasites).
Ou pire encore , dés que le temps sera orageux vous allez capter des parasites de tensions élevés , qui vont détruire l'entrée gpio voir le RPI.

J'ai réalisé un projet comparable au votre, de boite aux lettre "connectée" (mail + sms lorsque le facteur ouvre la trappe) . Voila le schéma pour connecter le contacteur au gpio:. J'ai parfois par temps orageux des faux positifs.


3) Coté logiciel: Je suis proche de votre solution mais plutôt que d'utiliser :
GPIO.add_event_detect(pin_flotteur, GPIO.FALLING, callback=my_callback, bouncetime=1000)
je préfère l'instruction suivante qui est beaucoup moins gourmande en ressource CPU .Le prog est stoppé puis débloqué lors de l'événement, pas besoin de boucle while pour rien faire (consommatrice de ressource CPU)
GPIO.wait_for_edge(intPin, GPIO.FALLING)

Comme le conseil JumpZero il faut d'abord mettre au point le prog "sur table" avec un BP et des longueurs de fils raisonnable (max 1 m).
Puis s'attaquer au problème de la longueur du câble.
Bon courage.

Bonjour ,

1°) effectivement , mon doigt a glisse

2°) je ne sais pas trop si il existe des solutions a ce soucis de longueur de cables.

3°) je vais tester de remplacer le callback par ( GPIO.wait_for_edge(intPin, GPIO.FALLING)
dans le code , si j ' ai besoin plus tard d' ajouter d ' autres fonctions je le ferais dans des fichiers separes .

je ne suis pas tres doué et ne connait pas bien les composants , je sais qu ' un optocoupleur permet d' isoler le passage du courant afin d' eviter les retours un peu comme une diode , mais quel est l' interet ici ?

je vous tiens au courant des resultats , merci a vous .

EDIT donc si dans le corps du programme je met :

Code: Select all

while True :
   if  ( GPIO.wait_for_edge(pin_flotteur, GPIO.FALLING) ) :
           time.sleep(0.2) # anti-rebond
          ecrire_log ("Initialisation sur le pin : " + str(pin_flotteur),1)

il detecte le falling , mais aussi l ' autre front le montant et me met donc un print a chaque changement d' etat

apres me direz vous il suffit de faire une lecture du pin et de regarder si il vaut 0 ( contact etabli ) , mais bon , il me semble que c' est deja ce qu ' est censé faire le ( wait for edge , falling ) non ? ( attente du passage d' un etat haut a bas) .

Hors-mis ce detail , comme avec la fonction callback , les test passent impec ...

j ' ai peut etre un probleme avec le truc du pi qui gere ou lit les pins ( hardware ) ou alors je suis tres mauvais en programation ou bien j ' ai pas compris un truc ...

qu ' en pensez vous ?

EDIT 2 : si je branche le contact NO du contacteur , j ' ai 5 messages par secondes

je sais pas , mais ce qui est sur , c ' est que mon contacteur serait grille depuis longtemps si il se mettrait en route et arret 5 fois par seconde MDR

avec un code d ' exemple pris sur le net : meme resultat que precedement ( on dirait une boucle classique )

Code: Select all

while True :
    edge_detect = GPIO.wait_for_edge (pin_flotteur, GPIO.FALLING, bouncetime=1000)
    if edge_detect is not None:
        ecrire_log ("Initialisation sur le pin : " + str(pin_flotteur),1)

Si je chint avec un morceau de cable , le defilement se stoppe , pourtant le contacteur est bien ouvert ... une fois les deux cables telephones debranché et test de resistance a l ' omhmetre , zero permanent ...

[JumpZero]

EDIT 2 : si je branche le contact NO du contacteur , j ' ai 5 messages par secondes

Probablement comme te l'as dit Ernesto tes 150m de câble font antenne et tu capte toutes les ondes électromagnétiques du coin (et entre autre les parasites (220V non?) du contacteur lui-même), un niveau de tension suffisant pour faire changer d'état le gpio du Pi, tu ne verras rien à l'ohmmètre il faut un oscilloscope pour voir ça.
Un optocoupleur sert à séparer (isoler) les 2 circuits (voir ici) et devrait dans un cas comme le tien éviter le problème (à démontrer par les essais)
Bon courage
PS: sans oscillo le trés bon programme PiScope de Joan qui est très présente sur les forums anglophones ici même permet de voir ce genre d'évènements très rapides, mais c'est une autre histoire...

[iznobe]

Re bonjour ,

ok , je ne pensais pas que c' etait si sensible que ca
de plus c ' est du cable telephonique avec gaine noire ultra resistant pour passage souterrain , je pensais qu il etait isole un minimum

Mon contacteur est alimente en 24 Volts , mais sur la distance des 75 metres lineaires , je dois avoir une cinquantaine d' appareils alimentés en 220 et en 380 Volts , le flotteur est pour detecter une fuite d' eau dans le local technique d' une station de lavage voiture ...
le contacteur sert a couper la commande des pompes forage et relevage en cas de fuite ainsi que les electrovannes de remplissage du bac tampon afin d' eviter que tout ce petit monde grille . j ' aurais voulu etre averti par mail au cas ou afin de venir en urgence reparer .

Donc y a plein de machines qui demarrent et s' arretent toute la journee , ca doit pas arranger les choses .

Jai commander des relais 5 volts optocouplés ( par 8 ) voir ici que je vais placer dans un boitier dedié, au lieu de faire un bidouillage de soudure d ' un optocoupleur en direct est il possible de passer par un de ces relais ou bien existe-il un module tout pret qui pourrait faire l ' affaire , que je pourrais fixer sur un rail DIN ? j ' ai des supports de ce style si besoin .

EDIT : je pense avoir trouver un paliatif , evidemment pas tres elegant mais bon vu qu ' on dirait que mon pi recoit du 50 HZ , je pense qu ' un truc du style permet deja de faire une detection fiable a plus de 99 % :

Code: Select all

edge_detect = GPIO.wait_for_edge (pin_flotteur, GPIO.FALLING, bouncetime=1000)
while True :
    if edge_detect is not None:
        count=0
        for i in range (0,5) :
            time.sleep (1)
            state = GPIO.input(pin_flotteur)
        
            if not state :
                count = count+1
                print (count)
                
                if count == 5 :
                    ecrire_log ("Initialisation sur le pin : " + str(pin_flotteur),1)

vous en pensez quoi ?

[joan]

Peut-être que la GPIO n'est basse que pendant une courte période, disons inférieure à une milliseconde. Il faudra un peu de temps avant que Python puisse démarrer le code de rappel. Au moment où vous le lisez dans le rappel, il est peut-être redevenu trop fort.

(google translate from "Perhaps the GPIO is only low for a short time, say less than a millisecond. There will be delay before Python gets to start the callback code. By the time you read it in the callback it may have become high again.")

[ernesto]

Avec la carte à relais cela devrait aller mieux.

pour filtrer je vous propose ce code:

Après la détection (GPIO.wait_for_edge):
lecture 1000 fois à intervalle de 1ms l’état de la pin_flotteur
Si la pin_flotteur est a l’état haut pendant temps > 0.8 s // la valeur de 0.8 devra être déterminé expérimentalement
alors -> parasite
sinon
détection pin flotteur état bas.

ce qui donne:

Code: Select all

while 1:
	GPIO.wait_for_edge(pin_flotteur, GPIO.FALLING)
	# lorsque le GPIO passe sur down - appui - on passe a la suite
	i=0		# pour la boucle while
	x=0		# nbre de fois que la pin_flotteur est vue avec la valeur 1
	t_ar=1000 # temps anti rebond 1000 boucles donc à peu pres 1000 ms
	while i < t_ar:
		x += GPIO.input(pin_flotteur) // on lit 0 ou 1
		i += 1
		time.sleep(0.001)	

	if x > 800:  # si état haut > 800 ms alors considère comme parasite
		print '** Signal parasite sur gpio ' ,pin_flotteur ,' x=',x,'... **'

	else:	#alors envoie mail
		print '** Signal sur gpio ' ,pin_flotteur ,' x=',x,' i=',i,' - ici écrire la suite des ... **'
		os.system('/var/www/interruption/envoie_mail.sh')

	time.sleep(1)	

[ernesto]

Quelques remarques:

il detecte le falling , mais aussi l ' autre front le montant et me met donc un print a chaque changement d' etat

Je suppose que vous faites des essais "sur table" donc lorsque vous appuyer sur le BP le prog détecte bien le passage à zéro. Puis lorsque vous relâcher le BP le prog détecte encore car il y a aussi des rebonds donc c'est normal, car le prog ne filtre rien du tout.

Si je chint avec un morceau de cable , le defilement se stoppe , pourtant le contacteur est bien ouvert ... une fois les deux cables telephones debranché et test de resistance a l ' omhmetre , zero permanent ...

Pas zéro permanent mais l'infini.

[iznobe]

Quelques remarques:

il detecte le falling , mais aussi l ' autre front le montant et me met donc un print a chaque changement d' etat

Je suppose que vous faites des essais "sur table" donc lorsque vous appuyer sur le BP le prog détecte bien le passage à zéro. Puis lorsque vous relâcher le BP le prog détecte encore car il y a aussi des rebonds donc c'est normal, car le prog ne filtre rien du tout.

Si je chint avec un morceau de cable , le defilement se stoppe , pourtant le contacteur est bien ouvert ... une fois les deux cables telephones debranché et test de resistance a l ' omhmetre , zero permanent ...

Pas zéro permanent mais l'infini.

ben dans :

Code: Select all

edge_detect = GPIO.wait_for_edge (pin_flotteur, GPIO.FALLING, [b]bouncetime=1000[/b])

le bounce time , c ' est pas cense etre un temps anti rebond justement ?

pour ce qui est de la resistance je sais pas trop , mais deux fils qui ne sont pas en contact , l ' afficheur m ' indique 0 , ce qui est le cas quand je n' ai pas de fuite d' eau et que mon flotteur est en position " normale " . quand il monte ( donc fuite d' eau ) il coupe le 24 V de l ' alimentation du relais contacteur et ferme mon contact ce qui donne le contact a la masse sur le GPIO donc etat LOW = 0 , j ' ai peut etre dit NO alors que c ' est NF ... desole je suis un peu fatigué a force

Pour ce qui est de la boucle a 5 tours , apres une heure de test continu , je n ' ai pas depasse le stade de 2 tours , sachant que c ' est exponentiel j ' ai vraiment peu de chance pour arriver jusqu ' a 5

j ' etudie votre code de pres , mais j ' emet qulques difficultés a tout comprendre , ca me parait un peu complexe pour le moment , je vous remercie et approfondie la chose

EDIT : sur la ligne dans le while :

Code: Select all

x += GPIO.input(pin_flotteur) // on lit 0 ou 1

il faut mettre # a la palce de "//"

par contre , x s ' incremente a chaque tour , d ' un 0 ou d' un 1 , donc en ajoutant 0 ne s ' incremente pas

j ' ai eu un peu de mal avec ca , mais bon j ' ai compris .

Par contre pour la suite je ne suis pas sur mais il me semble que ca serait plutot :

Code: Select all

while 1:
	GPIO.wait_for_edge(pin_flotteur, GPIO.FALLING)
	# lorsque le GPIO passe sur down - appui - on passe a la suite
	i=0		# pour la boucle while
	x=0		# nbre de fois que la pin_flotteur est vue avec la valeur 1
	t_ar=1000 # temps anti rebond 1000 boucles donc à peu pres 1000 ms
	while i < t_ar:
		x += GPIO.input(pin_flotteur) # on lit 0 ou 1
		i += 1
		time.sleep(0.001)	

	if x != t_ar:  # si état haut n ' est pas tout le temps , alors considère comme parasite
		print '** Signal parasite sur gpio ' ,pin_flotteur ,' x=',x,'... **'

	else:	#alors envoie mail
		print '** Signal sur gpio ' ,pin_flotteur ,' x=',x,' i=',i,' - ici écrire la suite des ... **'
		os.system('/var/www/interruption/envoie_mail.sh')

	time.sleep(1)	

Ca me parait puissant comme filtre , au niveau ressources proc , ca ne risque pas d' etre tres gourmand ?

[ernesto]

Ca me parait puissant comme filtre , au niveau ressources proc , ca ne risque pas d' etre tres gourmand ?

C'est sûr que lire 1000 fois le gpio en 1 seconde ça use !!! mais bon cela ne doit arrivé que lorsque le flotteur est actif lors de fuite c'est dire que très rarement. voir jamais.
Il faut résoudre le pb des parasites à laide de la carte relais.

dans le code il faut bien laisser le test if x > 800 car c'est normal qu il y est quelques rebonds.
Déterminer la valeur 800 à adopter en faisant des tests "sur table"

Code: Select all

while 1:
	GPIO.wait_for_edge(pin_flotteur, GPIO.FALLING)
	# lorsque le GPIO passe sur down - appui - on passe a la suite
	i=0		# pour la boucle while
	x=0		# nbre de fois que la pin_flotteur est vue avec la valeur 1
	t_ar=1000 # temps anti rebond 1000 boucles donc à peu pres 1000 ms
	while i < t_ar:
		x += GPIO.input(pin_flotteur) # on lit 0 ou 1
		i += 1
		time.sleep(0.001)	

	if x > 800:  # si état haut > 800 ms alors considère comme parasite
	#if x != t_ar:  # si état haut n ' est pas tout le temps , alors considère comme parasite
		print '** Signal parasite sur gpio ' ,pin_flotteur ,' x=',x,'... **'

	else:	#alors envoie mail
		print '** Signal sur gpio ' ,pin_flotteur ,' x=',x,' i=',i,' - ici écrire la suite des ... **'
		os.system('/var/www/interruption/envoie_mail.sh')

	time.sleep(1)	

[JumpZero]

ce qui est le cas quand je n' ai pas de fuite d' eau et que mon flotteur est en position " normale " . quand il monte ( donc fuite d' eau ) il coupe le 24 V de l ' alimentation du relais contacteur et ferme mon contact ce qui donne le contact a la masse sur le GPIO donc etat LOW = 0 , j ' ai peut etre dit NO alors que c ' est NF ... desole je suis un peu fatigué a force

C'est bien NF: Normalement Fermé, un contact est dit NF lorsque hors énergie (elec, pneumatique, etc..) il est fermé (le courant passe)
et bien sur NO c'est l'inverse. Donc si le contact auxiliaire du contacteur se ferme lorsque la bobine du contacteur n'est plus alimentée alors c'est un NF.
Dans ton script tu nommes le gpio "pin_flotteur" mais en fait ce n'est pas directement un contact du flotteur qui est raccordé au gpio mais ce contact auxiliaire du contacteur non?
A ce stade un schéma de l'existant serait le bienvenu!

[iznobe]

C'est bien NF: Normalement Fermé, un contact est dit NF lorsque hors énergie (elec, pneumatique, etc..) il est fermé (le courant passe)
et bien sur NO c'est l'inverse. Donc si le contact auxiliaire du contacteur se ferme lorsque la bobine du contacteur n'est plus alimentée alors c'est un NF.

Bonjour ,
il s ' agit bien d ' un contact NF

Dans ton script tu nommes le gpio "pin_flotteur" mais en fait ce n'est pas directement un contact du flotteur qui est raccordé au gpio mais ce contact auxiliaire du contacteur non?
A ce stade un schéma de l'existant serait le bienvenu!

et oui , le gpio est sur le contact NF , le flotteur agit directement sur l ' alimentation en 24 Volts du contacteur .
Si une fuite se produit , le flotteur coupe l ' alim du contacteur et donc ferme le GPIO , et ouvre la commande des pompes et electrovannes en 24 Volts aussi afin de limiter les risques de " grillage de pompe " et stoppe le remplissage du bac tampon qui alimente les pompes de relevage en eau .
Le schema concernant le script reste tres simple si on fait abstraction des " a cotes " on peut le resumer a ca lorsqu ' il n ' y a pas de fuite :


En cas de fuite le contact NF ( donc ) se ferme car le flotteur coupe l' alim du contacteur .

[iznobe]

Bon j ' ai adapte votre code anti rebond a mon script ce qui donne :

Code: Select all

#! /usr/bin/python
# coding: utf-8
import os
#import sys
import RPi.GPIO as GPIO
import time
#from datetime import datetime

# les pins 15 , 8 , 36 sont inutilisables ...
# lorsque le flotteur est en position normale ( basse ) , le contacteur est alimentee et permet aux pompes et aux electrovannes 
# de gerer le systeme automatiquement, le PI recoit un signal LOW sur son PIN car relie a la masse .
# En cas de fuite , le flotteur passe en position haute , le contacteur n ' alimente plus les pompes et electrovannes du local technique 
# afin de limiter les degats du a la fuite d' eau . le PI recoit un signal HIGH car le PIN est placé en pull UP .
# reellement le PIN n ' est plus connecte a rien car le contacteur est ouvert justement !

pin_flotteur=16
GPIO.setmode(GPIO.BCM) # board = emplacements physiques , BCM emplacements logiques du proc
GPIO.setup(pin_flotteur, GPIO.IN, pull_up_down=GPIO.PUD_UP) # en mode entree Tout Ou Rien
edge_detect = GPIO.wait_for_edge (pin_flotteur, GPIO.FALLING, bouncetime=1000)

while 1 :
    if edge_detect is not None :
        # lorsque le GPIO passe sur down - appui - on passe a la suite
        i=0		# pour la boucle while
        x=0		# nbre de fois que la pin_flotteur est vue avec la valeur 1
        t_ar=100 # temps anti rebond 1000 boucles donc à peu pres 1000 ms
    
        print "falling detecte !"

        while i < t_ar :
            x += GPIO.input(pin_flotteur) # on lit 0 ou 1
            i += 1
            time.sleep(1/t_ar)
            if x == 1 :
                break
        # de base on est en etat HIGH , a cause du pull up !
        # donc pour detecter le Falling , il faut se retrouver en etat bas pendant plus de temps ( a determiner )
        if x == 0 :  # si état bas tout le temps , alors on envoie le mail
            os.system ('python /home/pi/projets_auto/python/mail.py') # envoi du mail
            print "envoi du mail ! "

            while not GPIO.input(pin_flotteur) : # on attend tant qu ' on reste en position basse : permet de n' envoyer qu ' un mail !
                time.sleep(1)
                print "attente"

        time.sleep(1)
    time.sleep(1)

gpio.cleanup()

seul probleme , il consomme pas mal de ressources : 3 % du proc , cela car il y a beaucoup de faux falling , en fait la boucle a peine arrete repars , j ' ai plein de falling detecte ...

[ernesto]

seul probleme , il consomme pas mal de ressources : 3 % du proc , cela car il y a beaucoup de faux falling , en fait la boucle a peine arrete repars , j ' ai plein de falling detecte ..

Il faut résoudre le pb des parasites provoqués par la longueur de ligne !!!
Dans ces conditions de parasitage l'instruction GPIO.wait_for_edge n'a aucun intérêt.

[iznobe]

seul probleme , il consomme pas mal de ressources : 3 % du proc , cela car il y a beaucoup de faux falling , en fait la boucle a peine arrete repars , j ' ai plein de falling detecte ..

Il faut résoudre le pb des parasites provoqués par la longueur de ligne !!!
Dans ces conditions de parasitage l'instruction GPIO.wait_for_edge n'a aucun intérêt.

Salut , comment proceder afin d' eliminer les parasites ?

Existe t-il une solution physique ou logicielle ?

un truc qui me turlupine tout de meme : si il y a des parasites , pourquoi y en a t il uniquement sur la detection du 1 ??

je veux dire que si je releve le flotteur a la main , je n ' obtiens que des 0 et jamais de perturbation ( de 1 ) , si des parasites il y a , ne devrait il pas y en avoir aussi quand le flotteur est en haut ( contact relie a la masse ) ?

la boucle while qui attend le retour du contact ouvert : devrait etre " casse " du coup non ? j ' ai indique l ' endroit dans le code ci dessous :

Code: Select all

#! /usr/bin/python
# coding: utf-8

import os
import RPi.GPIO as GPIO
import time
#from datetime import datetime

GPIO.setmode(GPIO.BCM) # board = emplacements physiques , BCM emplacements logiques du proc

# les pins 15 , 8 , 36 sont inutilisables ...
# lorsque le flotteur est en position normale ( basse ) , le contacteur est alimentee et permet aux pompes et aux electrovannes 
# de gerer le systeme automatiquement, le PI recoit un signal LOW sur son PIN car relie a la masse .
# En cas de fuite , le flotteur passe en position haute , le contacteur n ' alimente plus les pompes et electrovannes du local technique 
# afin de limiter les degats du a la fuite d' eau . le PI recoit un signal HIGH car le PIN est placé en pull UP .
# reellement le PIN n ' est plus connecte a rien car le contacteur est ouvert justement !

#global pin_flotteur
#pin_flotteur=27 # GPIO. 2 , physique pin 13 .
pin_flotteur=16 # GPIO. 27 , physique pin 36 .

GPIO.setup(pin_flotteur, GPIO.IN, pull_up_down=GPIO.PUD_UP) # en mode entree Tout Ou Rien , reste en etat HIGH lorsque pas connecte

#GPIO.setup(GPIO_LEFT, GPIO.IN, pull_up_down=GPIO.PUD_UP)
# On se met en pullup, l'état du GPIO est donc à 1 par défaut, on détectera un appui lorsqu'il passe à zero (et donc FALLING) ,
# donc il faut cabler sur masse quand contact , quand il n ' y a pas de contact on reste en etat HIGH par defaut du au pull_up.
                
########################################################################
edge_detect = GPIO.wait_for_edge (pin_flotteur, GPIO.FALLING)

while True :
    if edge_detect is not None :
        print "falling detecte ! ", edge_detect
        time.sleep(0.1)
        count=0
        
        for i in range (0,10) :
            time.sleep (0.1)
            count += GPIO.input(pin_flotteur)
            print (count)
            
            if count >= 1 :
                print "parasite detecte"
                time.sleep(1)
                break

        if count == 0 :
            os.system ('python /home/pi/projets_auto/python/mail.py') # envoi du mail
            print "mail envoye!"
############################ ICI
        while not count : # on attend le retour du contacteur.
            time.sleep(1) # on attend le retour a l ' etat normal du flotteur
            count = GPIO.input(pin_flotteur) # lecture etat de l ' entree
############################ ICI
        time.sleep(1)
    time.sleep(1)

gpio.cleanup()

[ernesto]

Lorsque le contact est fermé (flotteur levé) on impose un 0 V à travers 150 m de câble mais apparemment cela suffit pour ne pas capter de parasites .
Dans l'autre cas lorsque le contact est ouvert (flotteur en bas) on impose 3.3v (1 logique) à travers la résistance de pullup interne du rpi qui fait à peu prés 50Kohm et au quel on rajoute un câble de 75 m connecté à rien du tout et qui joue le rôle d'antenne ... .

Vous pouvez tester le montage ci dessous qui devrait filtrer
R1 470 ohm '(environ) va se retrouver en // avec la 50 kohm de pullup interne
C1 : un condensateur entre 100 nano F et quelques micro F (vaut mieux 1 ou 4.7 micro farad enfin ce que vous avez sous la main)


Edit: Ou alors comme ci dessous juste rajouter un condensateur

[iznobe]

merci pour votre reponse

cependant j ' ai 3 questions :

je dois avoir environ 5000 condo de toutes sortes

le voltage du condensateur a t il une importance ?
le moins est represente par le petit trait ou le gros trait sur votre schema ?

si au lieu de faire un pull up , je branche sur le contact NO un 3.3 volts direct et que je laisse la masse monte sur le NF , cela pourrait fonctionner sans parasite ?

[ernesto]

le voltage du condensateur a t il une importance ?
le moins est represente par le petit trait ou le gros trait sur votre schema ?

Voltage supérieur à 3.3 Volt (ca ne doit pas exister en dessous 6V)
Le moins (si condensateur polarisé) du coté de la masse , erreur sur le second schéma. je corrige.

si au lieu de faire un pull up , je branche sur le contact NO un 3.3 volts direct et que je laisse la masse monte sur le NF , cela pourrait fonctionner sans parasite ?

NON , J'ai pas bien compris mais je crois que vous allez faire un court-circuit lorsque le contact va se fermer (adieu l'alim, adieu le rpi)

[iznobe]

J ' ai commence par la facilite , c ' est a dire juste le condensateur un 10 nanofarad 160 v non polarise ( sinon les pattes etaient trop courtes pour mettre dans le bornier ) :
au demarrage plus de edge detecte , par contre une fois que je fais monte le flotteur , on retourne a l ' etat initial de parasitage , comme si le condensateur n ' etait plus la .

Pour le 3.3 volts , ce que je voulais dire , c ' est que au lieu de faire semblant avec le pullup d' avoir un etat 1 , pourquoi ne pas mettre un vrai 3.3 volts , il me reste un contact dispo ( NO ) sur mon contacteur et 2 autres cable telephonique qui y arrive du coup avec un vrai voltage a 3.3 volts du pin , peut etre qu ' il n ' y aurait plus de parasite .

[ernesto]

10 nano c'est vraiment pas assez , il faut taper dans les quelques micro F (Mille fois plus).

Edit: Si j'ai bien compris , le schéma ci dessous représente ce que vous voulez faire (je comprends mieux avec un schéma )?
Le danger c'est que pendant un bref instant K1 et K2 seront tous les deux fermés (cela dépend de comment est fabriqué le contacteur). Pour palier a ce risque , le deuxième schéma peu fonctionner .




Dans ce schéma R2 n'est pas obligatoire mais c'est plus sécure
J'ai oublié de rajouter un condensateur entre 27 et la masse.

Je rappelle qu'il est fortement déconseillé (INTERDIT) de promener les alims 3.3v avec 75 m de câble

[iznobe]

Bonjour et encore merci pour votre aide

effectivement c ' est l ' hypothese que j ' ai emis , j ' ai installe fritzing , mais je decouvre a peine comment s ' en servir

j ' ai change le condo par un de 1 microfarad , mais resultat identique au test avec le condo precedent .

De plus, il doit y avoir autre chose que des parasites car , comme je l ' ai dit plus haut une fois que le contact est fait ( avec un chint a la mano ) ,
il me detecte des falling quasi permanent , meme lors que je debranche tout

le code me " parait bon " car apres de multiples test cela fonctionne comme je le veux , j ' ai modifie legerement afin de consommer moins de ressources ( ajout d ' un break dans la boucle si il y a un 1 qui reapparait et passage de 1000 iterations a 100 ) :

Code: Select all

#! /usr/bin/python
# coding: utf-8
import os
#import sys
import RPi.GPIO as GPIO
import time
#from datetime import datetime

# les pins 15 , 8 , 36 sont inutilisables ...
# lorsque le flotteur est en position normale ( basse ) , le contacteur est alimentee et permet aux pompes et aux electrovannes 
# de gerer le systeme automatiquement, le PI recoit un signal LOW sur son PIN car relie a la masse .
# En cas de fuite , le flotteur passe en position haute , le contacteur n ' alimente plus les pompes et electrovannes du local technique 
# afin de limiter les degats du a la fuite d' eau . le PI recoit un signal HIGH car le PIN est placé en pull UP .
# reellement le PIN n ' est plus connecte a rien car le contacteur est ouvert justement !

pin_flotteur=16
GPIO.setmode(GPIO.BCM) # board = emplacements physiques , BCM emplacements logiques du proc
GPIO.setup(pin_flotteur, GPIO.IN, pull_up_down=GPIO.PUD_UP) # en mode entree Tout Ou Rien
edge_detect = GPIO.wait_for_edge (pin_flotteur, GPIO.FALLING, bouncetime=1000)

while 1 :
    if edge_detect is not None :
        # lorsque le GPIO passe sur down - appui - on passe a la suite
        i=0		# pour la boucle while
        x=0		# nbre de fois que la pin_flotteur est vue avec la valeur 1
        t_ar=100 # temps anti rebond 1000 boucles donc à peu pres 1000 ms
    
        print "falling detecte !"

        while i < t_ar :
            x += GPIO.input(pin_flotteur) # on lit 0 ou 1
            i += 1
            time.sleep(1/t_ar)
            if x == 1 :
                break
        # de base on est en etat HIGH , a cause du pull up !
        # donc pour detecter le Falling , il faut se retrouver en etat bas pendant plus de temps ( a determiner )
        if x == 0 :  # si état bas tout le temps , alors on envoie le mail
            os.system ('python /home/pi/projets_auto/python/mail.py') # envoi du mail
            print "envoi du mail ! "

            while not GPIO.input(pin_flotteur) : # on attend tant qu ' on reste en position basse : permet de n' envoyer qu ' un mail !
                time.sleep(1)
                print "attente"

        time.sleep(1)
    time.sleep(1)

gpio.cleanup()

A part un soucis hardware , je ne vois pas trop qu ' est ce qu ' il peut y avoir d' autre

j ' ai utiliser le script pintest de wiring pi , il me dit que les pins sont ok a part 2 , mais comme j ' ai une carte son et une carte pour disque dur de brancher sur le pi , je suppose que les pins NOK , sont ceux utilises par ces cartes .

En tout cas le pin que j ' utilise dans mon script est considere comme OK , voir ci apres le pintest :

Code: Select all

pi@raspberrypi:~/projets_auto/gpio/wiringPi/gpio $ ./pintest
PinTest
=======

This is a simple utility to test the GPIO pins on your Raspberry Pi.

NOTE: All GPIO peripherals must be removed to perform this test. This
  includes serial, I2C and SPI connections. You may get incorrect results
  if something is connected and it interferes with the test.

This test can only test the input side of things. It uses the internal
pull-up and pull-down resistors to simulate inputs. It does not test
the output drivers.

You will need to reboot your Pi after this test if you wish to use the 
serial port as it will be left in GPIO mode rather than serial mode.

This test only tests the original pins present on the Rev A and B. It
does not test the extra pins on the Revision A2, B2 nor the A+ or B+

Please make sure everything is removed and press the ENTER key to continue,
or Control-C to abort... 

          The main 8 GPIO pins  0: 7: 
 --> Pin 7 failure. Expected 1, got 0
One fault detected.
                The 5 SPI pins 10:14:  OK
               The serial pins 15:16:  OK
                  The I2C pins  8: 9: Pin 9 failure - expected 1, got 0
One fault detected.


Faults detected! Output of 'readall':
 +-----+-----+---------+------+---+---Pi 3B--+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 |     |     |    3.3v |      |   |  1 || 2  |   |      | 5v      |     |     |
 |   2 |   8 |   SDA.1 |   IN | 1 |  3 || 4  |   |      | 5v      |     |     |
 |   3 |   9 |   SCL.1 |   IN | 0 |  5 || 6  |   |      | 0v      |     |     |
 |   4 |   7 | GPIO. 7 |   IN | 0 |  7 || 8  | 1 | IN   | TxD     | 15  | 14  |
 |     |     |      0v |      |   |  9 || 10 | 1 | IN   | RxD     | 16  | 15  |
 |  17 |   0 | GPIO. 0 |   IN | 1 | 11 || 12 | 1 | IN   | GPIO. 1 | 1   | 18  |
 |  27 |   2 | GPIO. 2 |   IN | 1 | 13 || 14 |   |      | 0v      |     |     |
 |  22 |   3 | GPIO. 3 |   IN | 1 | 15 || 16 | 1 | IN   | GPIO. 4 | 4   | 23  |
 |     |     |    3.3v |      |   | 17 || 18 | 1 | IN   | GPIO. 5 | 5   | 24  |
 |  10 |  12 |    MOSI |   IN | 1 | 19 || 20 |   |      | 0v      |     |     |
 |   9 |  13 |    MISO |   IN | 1 | 21 || 22 | 1 | IN   | GPIO. 6 | 6   | 25  |
 |  11 |  14 |    SCLK |   IN | 1 | 23 || 24 | 1 | IN   | CE0     | 10  | 8   |
 |     |     |      0v |      |   | 25 || 26 | 1 | IN   | CE1     | 11  | 7   |
 |   0 |  30 |   SDA.0 |   IN | 0 | 27 || 28 | 0 | IN   | SCL.0   | 31  | 1   |
 |   5 |  21 | GPIO.21 |   IN | 0 | 29 || 30 |   |      | 0v      |     |     |
 |   6 |  22 | GPIO.22 |   IN | 1 | 31 || 32 | 1 | OUT  | GPIO.26 | 26  | 12  |
 |  13 |  23 | GPIO.23 |   IN | 0 | 33 || 34 |   |      | 0v      |     |     |
 |  19 |  24 | GPIO.24 | ALT0 | 1 | 35 || 36 | 1 | IN   | GPIO.27 | 27  | 16  |
 |  26 |  25 | GPIO.25 |   IN | 0 | 37 || 38 | 0 | ALT0 | GPIO.28 | 28  | 20  |
 |     |     |      0v |      |   | 39 || 40 | 0 | ALT0 | GPIO.29 | 29  | 21  |
 +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+---Pi 3B--+---+------+---------+-----+-----+
pi@raspberrypi:~/projets_auto/gpio/wiringPi/gpio $ 

EDIT : a priori c ' est de ma faute

il faut laisser le edge dans la boucle , et la plus de probleme avec le condo ca marche impec

un enorme MMMMMerci depuis le temps que je galere avec ce truc ...

je teste plus en profondeur avant de passer en resolu la cas echeant