Béta sur JeedouinoExt

Plugins Protocole domotique
1

@revlys,

J’ai mis en place la béta de Jeedouino sur cette méthode.
Sur chacune de mes PI sous debian 9 à jour, que ce soit pour les PI avec un démon ou plusieurs démons, sur tes recommandations ont le fichier jeedouinoPiGpio.py* dans le répertoire /var/www/html/JeedouinoExt.
J’ai simplement modifié l’owner/groupe en www-data et appliqué à un 775 comme les autres fichiers.
Et ensuite, il m’a fallu réenregistrer toutes les configurations côté plugin jeedom, démon après démon, sinon plus rien ne bougeait.

Tu confirmes pour la méthode… déjà ?

Pour l’état de mes PI, voici à quoi ça ressemble :

  • PI Chauffe eau : 1 sonde DS,
  • PI Garage : 4 compteurs pulse séparés (4 démons différents)
  • PI Portail : 1 compteur pulse, 3 contacts secs
  • PI Piscine : 3 sondes DS, 1 contact sec.

Ce qui donne ça en démons : 4 (3 PI, mais 1 PI avec 4 démons différents).

Par contre, clairement… il y a du souci pour les compteurs.

Alors pour les contacts secs, OK ils fonctionnent parfaitement.
Pour les températures, là encore, tout est OK.

Alors exemple :

  • la PI portail qui a 3 capteurs secs et un pulse… ne compte plus !
    Malgré plusieurs réenregistrements…
    Test d’un contact sec sur ce démon, OK.
    https://i.imgur.com/DfjCx4e.png
    Le compteur d’eau lui est figé depuis hier… j’ai poussé une valeur reset vers 6h ce matin et j’ai refait un save des pins 3/4 fois pour réessayer à 6/7h puis à 10h alors qu’on consomme de l’eau, il ne bouge plus !
    https://i.imgur.com/JWVBGGe.png

Un autre exemple beaucoup plus génant, les pulses sur la PI Garage. J’ai l’impression que tu filtres à mort les impulsions et du coup, c’est faux, je perds de l’énergie à tout va dans le comptage.

Exemple le compteur clim. Il monte de 3000 impulsions en 3h le matin, là ce matin s’il est monté de 100…

1423×720 157 KB

Pire, le compteur PV ! Je précise qu’il fait un soleil magnifique… je peux pointer le compteur de l’API pour te montrer la différence. Voilà le comptage :

1428×721 154 KB

Encore plus simple à comprendre, le compteur eau chaude, alors qu’il a tourné comme la veille 2h… j’ai consommé 100 fois moins :p. Le top j’économise :wink:

1429×726 149 KB

Voilà la production recalculée en se basant sur la production que je sors avec le pulse. On voit bien qu’il y a un filtrage, la courbe ne décolle plus car elle loupe des impulsions.

332×568 4.27 KB

Aucun souci apparemment pour les contacts secs et les températures :
Eau chaude (PI dédiée)

204×574 7.92 KB

Eau de la piscine (PI dédiée)
242×578 7.97 KB

2

A la lecture du code, je vois ta fonction de déblocage, je vois que tu as parallélisé 4 comptages en parallèle si j’ai bien compris par rapport à l’ancienne version (toggle_cpts0 à toggle_cpts3).

# Essai : ReArm compteur si bloqué (toutes les heures)
                        if CptNextReArm < time.time():
                                CptNextReArm = time.time() + ReArmDelay
                                for i in range(0,40):
                                        j = pin2gpio[i]
                                        if Status_pins[i] == 'c':
                                                k = i % 4
                                                GPIO.setup(j, GPIO.IN,  pull_up_down = GPIO.PUD_UP)
                                                GPIO.remove_event_detect(j)
                                                time.sleep(1)
                                                if k == 1:
                                                        GPIO.add_event_detect(j, GPIO.FALLING, callback = toggle_cpts1)
                                                elif k == 2:
                                                        GPIO.add_event_detect(j, GPIO.FALLING, callback = toggle_cpts2)
                                                elif k == 3:
                                                        GPIO.add_event_detect(j, GPIO.FALLING, callback = toggle_cpts3)
                                                else:
                                                        GPIO.add_event_detect(j, GPIO.FALLING, callback = toggle_cpts0)
                                        elif Status_pins[i] == 'G':
                                                k = i % 4
                                                GPIO.setup(j, GPIO.IN,  pull_up_down = GPIO.PUD_DOWN)
                                                GPIO.remove_event_detect(j)
                                                time.sleep(1)
                                                if k == 1:
                                                        GPIO.add_event_detect(j, GPIO.RISING, callback = toggle_cpts1)
                                                elif k == 2:
                                                        GPIO.add_event_detect(j, GPIO.RISING, callback = toggle_cpts2)
                                                elif k == 3:
                                                        GPIO.add_event_detect(j, GPIO.RISING, callback = toggle_cpts3)
                                                else:
                                                        GPIO.add_event_detect(j, GPIO.RISING, callback = toggle_cpts0)

L’ancienne version de la fonction de comptage était à 30 secondes mais il n’y en avait qu’une.

def toggle_cpts(u):
        global CounterPinValue, PinNextSend, Status_pins, GPIO
        # if Status_pins[u-1] == 'c':
        # On compte le nombre d'impulsions
        uu = gpio2pin[u]
        CounterPinValue[uu] += GPIO.input(u)
        #GPIO.remove_event_detect(u)
        # on verifie qu'il y ai suffisamment de temps d'ecoule pour ne pas saturer jeedom et le reseau
        if PinNextSend[uu] < time.time():
                PinNextSend[uu] = time.time() + 30  #30s environ
                SimpleSend('&' + str(uu) + '=' + str(CounterPinValue[uu]))
        #GPIO.add_event_detect(u, GPIO.BOTH, callback=toggle_cpts)

En souvenir des essais du passé 2019, voir ici :
https://forum.jeedom.com/viewtopic.php?f=133&t=14056&hilit=jeedouino&sid=672e5439c2b5b263a25ddccd276842b3&start=1720#p767749

j’ai tenté de modifier ta fonction actuelle avec 10 secondes pour voir si le filtrage est diminué.
A voir si 10, 20 …

3

A priori, le log fait sa vie et le passage à 10 secondes ne l’a pas chamboulé.
Il faut que je le laisse tourner pour voir si la courbe est plus vraie et je vais aller pointer les compteurs.
Je vais aussi voir si le compteur d’eau recompte. Je me pose la question d’ailleurs de le sortir sur un démon dédié aussi… (comme les autres pulses).

Si on regarde le compteur 1673 (celui du PV qui bouge bcp actuellement), on voit des changements toutes les 3/5 secondes !

JeedouinoPiGpio-4pulsesdémonsséparés.log (86,5 Ko)

4

Salut @benj29,

J’ai mis en place la béta de Jeedouino sur cette méthode.
Sur chacune de mes PI sous debian 9 à jour, que ce soit pour les PI avec un démon ou plusieurs démons, sur tes recommandations ont le fichier jeedouinoPiGpio.py* dans le répertoire /var/www/html/JeedouinoExt.
J’ai simplement modifié l’owner/groupe en www-data et appliqué à un 775 comme les autres fichiers.
Et ensuite, il m’a fallu réenregistrer toutes les configurations côté plugin jeedom, démon après démon, sinon plus rien ne bougeait.
Tu confirmes pour la méthode… déjà ?

Oui, c’est bien ce qu’il fallait faire.

Encore plus simple à comprendre, le compteur eau chaude, alors qu’il a tourné comme la veille 2h… j’ai consommé 100 fois moins :p. Le top j’économise :wink:

C’est la bonne façon de voir les choses… :laughing:

A la lecture du code, je vois ta fonction de déblocage, je vois que tu as parallélisé 4 comptages en parallèle si j’ai bien compris par rapport à l’ancienne version (toggle_cpts0 à toggle_cpts3).

Exact, c’est pour repartir la charge des events_detect (au niveau de la librairie gpio).

j’ai tenté de modifier ta fonction actuelle avec 10 secondes pour voir si le filtrage est diminué.
A voir si 10, 20 …

Non, cela ne changera rien dans ton cas.

En fait le filtrage, est fait sur les fronts montants / descendants des impulsions.
J’avais changé cela, pour faire une différence avec les compteurs en pull_up et en pull_down.

Mes tests semblaient ok, mais il va me falloir creuser ça.

En attendant, essaye de remplacer les :

GPIO.add_event_detect(j, GPIO.FALLING, callback = toggle_cpts

par

GPIO.add_event_detect(j, GPIO.BOTH, callback = toggle_cpts

pour chaque toggle_cpts (8 fois donc).

Bonne journée.

5

Hello,

Merci pour ta réponse. Nous sommes bien d’accord que tu parles des 8 fonctions dans la fonction rearm ?
J’ai fait la modification. Il faut que je réinitialise les compteurs vu qu’ils sont tous faux en valeur absolue.

6

Bon, j’ai fait la modification en repassant à 30 secondes (comme d’origine dans ton code) donc ça 4 fois :

1018×149 5.03 KB

et j’ai modifié en mettant BOTH au lieu de RISING/FALLING sur les 4 fonctions à chaque fois dans la fonction Rearm.

1023×650 18.5 KB

Ce qui me dérange c’est que je vois aussi dans la fonction toggle_inputs mais je ne change pas.

858×259 6.23 KB

Du coup, je ne comprends en quoi ce changement dans la fonction rearm uniquement (toutes les heures) va permettre de mieux compter en temps réel ?

Les changements faits depuis 12h10 ne montrent rien de plus que ce matin (j’ai réenregistré chaque démon côté jeedouino et j’ai redémarré chaque démon par sécurité via le widget dédié et vérifié sur la page html de jeedouinoext de mes 2 pi à compteurs pulse.

D’ailleurs dans santé, malgré ma relance, modification, le compteur eau n’a pas bougé depuis 11h50 !
PI_GARAGE_qlqchose sont 4 compteurs pulse. PI_PORTAIL_EAU est le compteur pulse pour l’eau sur une autre PI qui est figé depuis la mise à jour hier.

1458×294 51.1 KB

EDIT : j’ai remis l’ancien fichier PY pour le compteur d’eau, il s’est remis à compter. Il y a autre chose donc…
Et je te confirme que les compteurs « pulse » électriques sont filtrés à mort… et comptent peu.

7

De rien.
Non, tu as 4 fonctions dans réarm, mais les 4 importantes sont vers la ligne 192.

8

Tu me confirmes que ce sont les 8 là ?

916×543 16.8 KB

Pas les n,q,i.
Seulement c, G.

Merci !

EDIT 1 :
J’ai fait la modification, à suivre sur les 5 compteurs d’ici demain.
Surtout si je me suis trompé, dis-le moi.
Je vais vite voir si le compteur d’eau compte correctement…

EDIT 2 :
le compteur d’eau compte.
à suivre si les pulses électriques comptent pareil (à voir demain pour le PV, l’ECS ou la clim…).
à voir ensuite si les démons se bloquent encore.

9

Bon bein… c’est la catastrophe.
Effectivement les compteurs se bloquent et se relancent.
Mon script de vérification le détecte.
Sauf que le comptage est complètement dans les choux.

Par exemple, l’eau, il manque presque 100l. Le compteur se bloque par moment avant de se relancer et ainsi de suite.

Pour le PV, piscine, etc ; compteurs élec c’est pareil. On loupe des fronts de partout et le comptage est complètement erroné. Donc soit j’ai modifié des mauvaises lignes (j’en doute car j’ai bien trouvé à la ligne 190 environ les 8 à modifier) … soit la modification n’est pas suffisante.

En attendant, je remets l’ancien fichier…

10

Le log de la PI compteur d’eau (un démon), contacts secs (3 ; un autre démon)

JeedouinoExt.log (80,7 Ko)

Le log du démon compteur d’eau :

JeedouinoPiGpio.log (174,0 Ko)

Je te mets aussi un compteur (par exemple celui de clim que j’ai vu planter plusieurs fois et qui a redemarré). Le log de la PI (qui a 4 compteurs pulse)

JeedouinoExt (1).log (80,9 Ko)

Le compteur clim :
JeedouinoPiGpio (1).log (336,8 Ko)

Le compteur PV qui est bien loin du compte en comptage :
JeedouinoPiGpio (2).log (337,0 Ko)

11

Quelques copies d’écran pour bien voir les « pauses » de comptage.
Effectivement ça repart derrière, mais on loupe clairement du comptage.
J’ai mis volontairement la veille pour voir la différence :).

Le 7 à gauche, on voit les comptages, aujourd’hui … rien.
J’ai fait les mises à jour hier soir.

La clim :

1437×776 184 KB

La piscine qui tourne une heure tous les jours de 11h30 à 12h30. Pire y a du comptage à 21h hier soir ! Et quasi rien aujourd’hui de 11h30 à 12h30

1422×675 151 KB

L’eau chaude n’a rien vu aujourd’hui (cette nuit) :

1430×690 161 KB

Et le photovoltaique qui n’a pas vu qu’il faisait jour :smiley:

1412×676 150 KB

12

Bonjour,

Alors pour les modifs, on s’est mal compris je pense.
Je te joint 2 captures (les numéros de lignes peuvent légèrement varier):

addevent_pigpio
addevent_pigpio1168×810 127 KB
rearm_pigpio
rearm_pigpio1182×992 149 KB

Pas les n,q,i.
Seulement c, G.

Seulement ‹ c › :
Les GPIO.add_event_detect(j, GPIO.FALLING, callback = toggle_cpts

J’ai fait la modification, à suivre sur les 5 compteurs d’ici demain.

Tu peux tester sur un seul si tu veux.

Vérifie aussi :
rearm_delay

Laisse 3600 pour les tests.

Bonne journée.

13

Je viens de modifier comme suit, effectivement, j’avais compris qu’il fallait modifier les 8.
Donc non ce sont les 4 fallings à passer en BOTH pour la fonction rearm et la fonction de comptage (‹ c ›).

1150×661 20.9 KB

Puis plus loin dans la fonction rearm :

1166×687 20.3 KB

Sinon c’est bien comme ça sur le comptage :

Je vais enregistrer que les compteurs élec avec cette modification et voir le comptage pour aujourd’hui.
Pas l’eau car c’est trop sensible et ton code précédent en stable marche très bien et n’a JAMAIS planté pour un seul compteur.

14

@revlys,

Je te confirme que ça compte plutôt bien sur les premières heures.
Par contre, clairement, la sauvegarde pour prendre ça en compte est plutôt hasardeuse.

J’ai modifié le code PY sur la PI en question.
J’ai réénregistré le démon côté Jeedouino avec la configuration PINS et ensuite fait un redémarrage sur la page JEEDOUINOEXT de la PI du démon.
Sincèrement en moyenne, 4 ou 5 essais pour revoir le compteur « compter »…

Je me suis résolu à effacer le numéro de port pour forcer la création d’un nouveau démon et là, magie, les compteurs se sont remis à bouger.

Maintenant le comptage tourne à voir si tout est OK d’ici demain (que ça compte correctement sans louper trop de fronts).

Mais déjà de voir ça, je suis déjà très content !
De gauche à droite : code ancien PY qui comptait, code nouveau qui compte pas, et la grosse montée de today, ton code modifié.

image

Dernière question. En théorie, les compteurs doivent toujours compter au bout de 3600 secondes, soit 1h, nous sommes bien d’accords ?

A l’heure actuelle, j’avais mis un code qui surveillait le lastcom des compteurs pour me le notifier. Mais du coup, j’avais en fonction des consommations et de l’habitude que ça ne bouge pas mis une temporisation plus importante. Je peux redescendre à 3600 (ou un peu au-dessous) pour détecter si le code fait son travail ?

(variable(PI-GARAGE_ECS_LastCom) < 32400) ET (variable(PI-GARAGE_CLIM_LastCom) < 1800) ET (variable(PI-GARAGE_PV_LastCom) < 32400) ET (variable(PI-GARAGE_PISCINE_LastCom) < 1800) ET #[Surveillance][Jeedouino Control][Etat Démon PI-GARAGE_ECS]# ET #[Surveillance][Jeedouino Control][Etat Démon PI-GARAGE_PISCINE]# ET #[Surveillance][Jeedouino Control][Etat Démon PI-GARAGE_PV]# ET #[Surveillance][Jeedouino Control][Etat Démon PI-GARAGE_CLIM]#

image
image1810×890 132 KB

PS : si OK ce soir, je mettrai ce code sur le compteur d’eau pour voir sur 2/3 jours si c’est toujours OK.

EDIT : j’ai mis le compteur pour l’eau. Pour l’instant il compte parfaitement. Du coup, j’attends ta confirmation pour la surveillance que j’avais mise en place et j’attends de voir comment ça se comporte sur plus de temps…

Ca sent bon !

15

Salut @revlys,

J’ai poussé ton code sur toutes les PI, ça tourne. Plus d’erreur de comptage. A voir sur la durée par contre, si un compteur se bloque, pas assez de recul pour l’instant.

Par contre, j’avais mis en place une surveillance à base de lastcom sur chaque Gpio des PI. Et j’ai l’impression que cela est faux. Il donne la dernière fois où il a vu la valeur et non la dernière réception de communication même si la valeur est la même (je ne sais pas si je suis clair).

	$valeurdbt= $equipt->getStatus('lastCommunication');

Du coup, j’ai viré cette partie pour l’instant et je me base sur l’état des démons.
Sur quoi te bases-tu pour passer un démon à 0 ou 1 ?

16

Again @revlys, premier blocage et cela n’a pas redémarré.

Exemple : cette nuit, le compteur piscine s’est arrêté à une valeur et n’a pas bougé depuis 0h36.

567×674 137 KB

Je précise qu’il y a un talon de consommation faible de quelques watts qui devrait faire monter le compteur faiblement mais monter quand même (exemple la nuit précédente) :

Du coup, un vrai blocage, chouette ! Jeedom qui m’historise l’état du démon, on voit que le démon de ce compteur est à 0.
Il redémarre à 5h du matin, d’ailleurs dans l’historique, pas de point entre 0h36 et 5h du matin.
Sauf qu’ensuite, le compteur reste bloqué à cette valeur mais il existe des points.
Mais la GPIO en question est bloquée…
Donc est-ce que le code de rearm a fait son travail, non. Je ne sais pas trop comment le vérifier.

483×629 112 KB

Je précise que le démon en question est toujours à 1 sans cesse.

On voit bien que le démon remonte une valeur mais que la valeur reste toujours la même. La dernière communication est récente :

1435×285 14 KB

Mais si on regarde le log (ou l’historique) je n’ai pas de valeur qui remonte sur 1674.
JeedouinoPiGpio.log (316,1 Ko)

La dernière valeur remonte en 1674 remonte à sinon ce ne sont que des PING OK. Pourquoi ?

[2020-04-16 10:10:02][Demon PiGpio] GET : /plugins/jeedouino/core/php/Callback.php?BoardEQ=1674&REP=PINGOK
[2020-04-16 10:10:02][Demon PiGpio] Requete : : ['PING', '1']
[2020-04-16 10:10:02][Demon PiGpio] >>Reponse a la requete : : PINGOK

D’ailleurs je ne comprends pas trop ce type de ligne :

[2020-04-16 10:20:43][Demon PiGpio] GET : /plugins/jeedouino/core/php/Callback.php?BoardEQ=1674&36=33

Ah quand je remonte je vois ça. Il a pas aimé quelque chose …

[2020-04-16 01:25:28][Demon PiGpio] GET : /plugins/jeedouino/core/php/Callback.php?BoardEQ=1674&THREADSDEAD=1
Traceback (most recent call last):
  File "/var/www/html/JeedouinoExt/jeedouinoPiGpio_1674.py", line 512, in toggle_cpts3
    SimpleSend('&' + str(uu) + '=' + str(CounterPinValue[uu]))
  File "/var/www/html/JeedouinoExt/jeedouinoPiGpio_1674.py", line 789, in SimpleSend
    conn.request("GET", url )
  File "/usr/lib/python3.5/http/client.py", line 1107, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib/python3.5/http/client.py", line 1152, in _send_request
    self.endheaders(body)
  File "/usr/lib/python3.5/http/client.py", line 1103, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python3.5/http/client.py", line 934, in _send_output
    self.send(msg)
  File "/usr/lib/python3.5/http/client.py", line 877, in send
    self.connect()
  File "/usr/lib/python3.5/http/client.py", line 849, in connect
    (self.host,self.port), self.timeout, self.source_address)
  File "/usr/lib/python3.5/socket.py", line 712, in create_connection
    raise err
  File "/usr/lib/python3.5/socket.py", line 703, in create_connection
    sock.connect(sa)
OSError: [Errno 113] No route to host
Exception in thread Second Network thread:
Traceback (most recent call last):
  File "/usr/lib/python3.5/threading.py", line 914, in _bootstrap_inner
    self.run()
  File "/var/www/html/JeedouinoExt/jeedouinoPiGpio_1674.py", line 633, in run
    SimpleSend(pinStr)
  File "/var/www/html/JeedouinoExt/jeedouinoPiGpio_1674.py", line 789, in SimpleSend
    conn.request("GET", url )
  File "/usr/lib/python3.5/http/client.py", line 1107, in request
    self._send_request(method, url, body, headers)
  File "/usr/lib/python3.5/http/client.py", line 1152, in _send_request
    self.endheaders(body)
  File "/usr/lib/python3.5/http/client.py", line 1103, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python3.5/http/client.py", line 934, in _send_output
    self.send(msg)
  File "/usr/lib/python3.5/http/client.py", line 877, in send
    self.connect()
  File "/usr/lib/python3.5/http/client.py", line 849, in connect
    (self.host,self.port), self.timeout, self.source_address)
  File "/usr/lib/python3.5/socket.py", line 712, in create_connection
    raise err
  File "/usr/lib/python3.5/socket.py", line 703, in create_connection
    sock.connect(sa)
OSError: [Errno 113] No route to host

kill: (18405): No such process
kill: (18406): No such process
[2020-04-16 01:25:35][Demon PiGpio] info : Starting First Network thread
[2020-04-16 01:25:35][Demon PiGpio] info : Starting Second Network thread
[2020-04-16 01:25:35][Demon PiGpio] info : Jeedouino PiGpio daemon running...
[2020-04-16 01:25:36][Demon PiGpio] Requete : : ['BootMode', '0']
[2020-04-16 01:25:37][Demon PiGpio] >>Reponse a la requete : : BMOK
[2020-04-16 01:25:39][Demon PiGpio] GET : /plugins/jeedouino/core/php/Callback.php?BoardEQ=1674&PINMODE=1&CPT_36=36
[2020-04-16 01:25:39][Demon PiGpio] Requete : : ['ConfigurePins', '...................................c....']
[2020-04-16 01:25:39][Demon PiGpio] >>Reponse a la requete : : COK
[2020-04-16 01:25:39][Demon PiGpio] GET : /plugins/jeedouino/core/php/Callback.php?BoardEQ=1674&REP=COK
[2020-04-16 01:25:39][Demon PiGpio] Requete : : ['ConfigurePins', '...................................c....']
[2020-04-16 01:25:39][Demon PiGpio] >>Reponse a la requete : : COK
[2020-04-16 01:25:39][Demon PiGpio] GET : /plugins/jeedouino/core/php/Callback.php?BoardEQ=1674&REP=COK
[2020-04-16 01:29:09][Demon PiGpio] Requete : : ['PING', '1']
[2020-04-16 01:29:09][Demon PiGpio] >>Reponse a la requete : : PINGOK
[2020-04-16 01:29:09][Demon PiGpio] GET : /plugins/jeedouino/core/php/Callback.php?BoardEQ=1675&REP=PINGOK
[2020-04-16 01:29:09][Demon PiGpio] Requete : : ['PING', '1']
[2020-04-16 01:29:09][Demon PiGpio] >>Reponse a la requete : : PINGOK
[2020-04-16 01:29:09][Demon PiGpio] GET : /plugins/jeedouino/core/php/Callback.php?BoardEQ=1676&REP=PINGOK
[2020-04-16 01:29:09][Demon PiGpio] Requete : : ['PING', '1']
[2020-04-16 01:29:09][Demon PiGpio] >>Reponse a la requete : : PINGOK
[2020-04-16 01:29:09][Demon PiGpio] GET : /plugins/jeedouino/core/php/Callback.php?BoardEQ=1674&REP=PINGOK
[2020-04-16 01:29:09][Demon PiGpio] Requete : : ['PING', '1']
[2020-04-16 01:29:09][Demon PiGpio] >>Reponse a la requete : : PINGOK
[2020-04-16 01:29:09][Demon PiGpio] GET : /plugins/jeedouino/core/php/Callback.php?BoardEQ=1673&REP=PINGOK
[2020-04-16 01:29:34][Demon PiGpio] GET : /plugins/jeedouino/core/php/Callback.php?BoardEQ=1675&40=1141435
[2020-04-16 01:32:06][Demon PiGpio] GET : /plugins/jeedouino/core/php/Callback.php?BoardEQ=1674&36=0
[2020-04-16 01:32:36][Demon PiGpio] GET : /plugins/jeedouino/core/php/Callback.php?BoardEQ=1674&36=1
17

Salut @benj29,

Par contre, j’avais mis en place une surveillance à base de lastcom sur chaque Gpio des PI. Et j’ai l’impression que cela est faux. Il donne la dernière fois où il a vu la valeur et non la dernière réception de communication même si la valeur est la même (je ne sais pas si je suis clair).

Cela vient de Jeedom, il ne modifie plus la date si la valeur ne change pas.
Il y a un débat sur le forum a ce sujet.
Essaye plutôt ça (cela te donnera la même date que la page santé):

$eqTime = config::byKey('lastCommunication'.$eqLogic->getId(), 'jeedouino', '');

Du coup, j’ai viré cette partie pour l’instant et je me base sur l’état des démons.
Sur quoi te bases-tu pour passer un démon à 0 ou 1 ?

J’envoie une commande ping au démon, et je vois si il réponds.
Tu peux regarder le code si tu veux plus de détails : function StatusBoardDemon

Again @revlys, premier blocage et cela n’a pas redémarré.
Exemple : cette nuit, le compteur piscine s’est arrêté à une valeur et n’a pas bougé depuis 0h36.

Arghh!

Du coup, un vrai blocage, chouette ! Jeedom qui m’historise l’état du démon, on voit que le démon de ce compteur est à 0.
Il redémarre à 5h du matin, d’ailleurs dans l’historique, pas de point entre 0h36 et 5h du matin.
Sauf qu’ensuite, le compteur reste bloqué à cette valeur mais il existe des points.
Mais la GPIO en question est bloquée…

J’ai regardé le log, et on voit bien que sur l’équipement 1674, tu as des remontées, peu d’accord mais il y en a et je pense que cela correspond a ce que tu m’as dit :

Je précise qu’il y a un talon de consommation faible de quelques watts qui devrait faire monter le compteur faiblement mais monter quand même

Par contre si ton compteur (coté jeedouino) la valeur ne change pas, c’est parce que le nouveau comptage renvoi un valeur plus faible que celle qu’il a déjà en mémoire, et donc n’en tient pas compte.
Ce qui soulève le problème suivant:

  • Pourquoi le démon quand il a redémarré, n’a pas reçu la dernière valeur connue du compteur?

Je vais devoir investiguer cela.

L’erreur que tu soulèves dans le log, fait suit à :

[2020-04-16 01:25:26][Demon PiGpio] Error : 2nd Thread dead, shutting down daemon server and ask Jeedouino for a restart.

C’est donc suite au redémarrage du démon.

D’ailleurs je ne comprends pas trop ce type de ligne :

[2020-04-16 10:20:43][Demon PiGpio] GET : /plugins/jeedouino/core/php/Callback.php?Boar

Littéralement: le démon appelle Jeedouino en lui donnant l’id de l’équipement pour lequel il faut mettre à jour la pin 36 avec la valeur 33.

Donc est-ce que le code de rearm a fait son travail, non. Je ne sais pas trop comment le vérifier.

J’ai l’impression que non, sauf si le blocage du démon est du à autre chose.
Je regarde ça dès que je peux.

Bonne journée.

18

@revlys

Tu as bien vu le log qui part en sucette juste avant le redémarrage ?

De même, le compteur compte après cette erreur, c’est juste que sa valeur est eronnée, je vois 1, 2 etc jusqu’à 35… mais pas du tout la valeur que j’ai côté jeedom qui est en million. On dirait qu’il recommence à compter mais pas depuis la bonne valeur et que ces valeurs ne sont pas transmises (regarde le log en détail, je te l’ai posté plus haut)

19

Je ne vois pas comment mettre en place ta ligne.
J’ai l’impression que ça donne la dernière remontée du démon.
Moi j’ai nommé mes objets à regarder dans mon code et je balaye par une boucle le tableau en question.
Désolé, suis vraiment novice en code.

$equipements = array("#[Agrégateurs][PI-CHAUFFEEAU][31_ds18b20]#",
                     "#[Agrégateurs][PI-GARAGE_ECS][33_cpt_ecs]#",
                     "#[Agrégateurs][PI-GARAGE_PV][35_cpt_pv]#",
                     "#[Agrégateurs][PI-GARAGE_PISCINE][36_cpt_piscine]#",
                     "#[Agrégateurs][PI-GARAGE_CLIM][40_cpt_clim]#",
                     "#[Agrégateurs][PI-PISCINE][7_ds18b20]#",
                     "#[Agrégateurs][PI-PISCINE][11_ds18b20]#",
                     "#[Agrégateurs][PI-PISCINE][12_input_pullup]#",
                     "#[Agrégateurs][PI-PISCINE][13_ds18b20]#",
                     "#[Agrégateurs][PI-PISCINE][Etat_Pin_29]#",
                     "#[Agrégateurs][PI-PORTAIL][35_input_pullup]#",
					 "#[Agrégateurs][PI-PORTAIL][37_input_pullup]#",
                     "#[Agrégateurs][PI-PORTAIL_EAU][7_compteur_pullup]#",
                     "#[Agrégateurs][PI-PORTAIL][33_input_pullup]#");

$maintenant = (new DateTime(date("Y-m-d H:i:s")));
$valeurfin = ($maintenant->format('Y-m-d H:i:s'));
$valeurfin2 = ($maintenant->getTimestamp());

$scenario->setLog("maintenant : $valeurfin timestamp : $valeurfin2");

foreach ($equipements as $equipement) {
	$cmd = cmd::byString($equipement);
	$idEquipt = $cmd->getEqLogic_id();

	$equipt=eqLogic::byId($idEquipt);
  
	$nomEquipement = $equipt->getName();
	$valeurdbt= $equipt->getStatus('lastCommunication');
    //$valeurdbt = config::byKey('lastCommunication'.$eqLogic->getId(), 'jeedouino', '');
  
// 1er methode différence delta
	$delta = gmdate("H:i:s",strtotime($valeurfin) - strtotime($valeurdbt));
  
// 2eme methode difference timestamp
  	$temp_difftime = ($valeurfin2 - (new DateTime($valeurdbt))->getTimestamp());
  	$scenario->setLog("-----------------------------------------------------");
	$scenario->setLog("Nom du device : $nomEquipement id : $idEquipt");
	$scenario->setLog("dernière communication : $valeurdbt différence : $delta secondes : $temp_difftime");
  $scenario->setData($nomEquipement."_LastCom", $temp_difftime);
  }
20

Bonjour @benj29 ,

De même, le compteur compte après cette erreur, c’est juste que sa valeur est eronnée, je vois 1, 2 etc jusqu’à 35… mais pas du tout la valeur que j’ai côté jeedom qui est en million. On dirait qu’il recommence à compter mais pas depuis la bonne valeur et que ces valeurs ne sont pas transmises (regarde le log en détail, je te l’ai posté plus haut)

On est bien d’accord, c’est que je te disais dans ma réponse précédente:
Pourquoi le démon quand il a redémarré, n’a pas reçu la dernière valeur connue du compteur?
Il faut je me penche dessus cela.

Je ne vois pas comment mettre en place ta ligne.
J’ai l’impression que ça donne la dernière remontée du démon.
Moi j’ai nommé mes objets à regarder dans mon code et je balaye par une boucle le tableau en question.
Désolé, suis vraiment novice en code.

En fait dans ton code, tu récupères l’id de l’équipement par:
$idEquipt = $cmd->getEqLogic_id();

Donc la ligne devient:
$valeurdbt = config::byKey('lastCommunication' . $idEquipt, 'jeedouino', '');

Note: dans ton code, ce sont des commandes que tu balayes, pas des équipements.

Bonne journée.