Béta sur JeedouinoExt

benj29 · Avril 10, 2020, 7:03

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 ›).

Puis plus loin dans la fonction rearm :

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.

benj29 · Avril 10, 2020, 12:43

@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é.

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]#

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 !

benj29 · Avril 15, 2020, 8:49

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 ?

benj29 · Avril 16, 2020, 9:28

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.

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.

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 :

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

revlys · Avril 16, 2020, 10:13

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.

benj29 · Avril 16, 2020, 12:07

@revlys

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

benj29:

[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

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)

benj29 · Avril 16, 2020, 12:27

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);
  }

revlys · Avril 18, 2020, 7:36

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.

benj29 · Avril 24, 2020, 7:14

Hello @revlys,

Modification faite dans mon code, merci pour ton aide.
Par contre, j’ai mis ton fichier .py sur toutes mes PY et du coup, je vois les bloquages de remontée plus souvent.
Hier c’était la PI avec des températures (piscine, 3 capteurs) qui s’est bloquée. Donc rien à voir avec le pulse aussi. Ou du moins la relance du démon plante d’une manière générale ?

revlys · Mai 2, 2020, 4:36

Bonjour @benj29,

Tu aurais gardé le log de ce plantage ?
De mon coté, j’ai toujours mes 2 rpi en tests depuis 3 semaines env. sans soucis.
Mais comme l’environnement et les sollicitations ne sont pas les mêmes, difficile de comparer.

Bonne journée.

benj29 · Mai 3, 2020, 5:24

Zut, je viens de vérifier… mais non (pour celui de la température, trop vieux).

Par contre, je te confirme que j’ai encore des problèmes de compteurs pulse qui ne redémarrent pas et partent en vrille. Encore un ce matin.

Tu as corrigé ton code ? Je peux le tester si tu veux (vu que je tourne déjà avec la béta).

benj29 · Mai 9, 2020, 10:56

Hello @revlys,

Un autre souci, je ne sais pas si c’est lié mais je ne pense pas.

En parallèle du blocage des pulses, si je coupe une PI, quand elle redémarre son chemin de configuration est erroné. Il faut que je relance une installation et tout rentre dans l’ordre. Mais à la coupure électrique suivante, bis répétita.

Une idée ?

Le problème est que si coupure, les démons sont inaccessibles car l’interface pointée (du serveur html je présume) est erronée.

Elle pointe après reboot sur :

Il faut que je fasse une installation nouvelle (et non une mise à jour qui pointe toujours sur l’ancien chemin) pour que tout soit OK :

Alors qu’elle doit pointer quand je relance une installation ou que tout est OK sur :

L’autre problème est que je ne peux pas récupérer les logs par l’interface jeedom car JeedouinoExt sur la PI est « tanké »

Je peux y accéder par SSH :

celui du Gpio, mais rien de probant avant ma coupure à 12h20 :

celui du Ext, idem :

J’ai ce phénomène sur 3 PI sur 4.
(peut être apache vs nginx ?)

revlys · Mai 10, 2020, 9:29

Bonjour @benj29,

Je pensais avoir déjà corrigé ce problème de chemin.
Du coup, j’ai regardé et c’était qu’en partie fait, cela devrait être bon maintenant.
Merci pour les retours.

Pour les autres corrections, elles sont disponibles sur github et sur le market en stable.

Bonne journée.

benj29 · Mai 10, 2020, 3:26

Mise à jour appliquée sur Jeedom et sur toutes les PI.
A suivre.
A noter que l’on peut faire une mise à jour sur JeedouinoExt en local (127.0.0.1) qui est logiquement refusée.
Tu devrais empêcher cela.
Non ?

revlys · Mai 10, 2020, 4:36

Bien vu !

Je corrige ça

benj29 · Mai 10, 2020, 8:28

Pour l’instant tout roule. A voir au prochain cash de pulse…

benj29 · Mai 20, 2020, 6:45

Bon j’ai vérifié quelques bricoles car mon comptage pulse du PV était complètement erroné !
Les autres compteurs font leur vie depuis la mise à jour du 10/05 soit 10 jours…

Mais je ne comprends pas ce qu’il s’est passé dans le cas précis du PV.
Le compteur s’est emballé comme un fou. Pourtant il se calme le soir. Mais il compte comme si il était à fond tout le temps, chose impossible. Surtout que le comptage réel (écrit en temps réel sur le compteur est juste lui).

L’effet d’échelle a complétement écrasé les autres courbes du compteur avant le 18/05.
J’ai zoomé avant pour bien que l’on comprenne la différence entre avant et après.

Par sécurité, j’ai réenregistré un démon proprement pour voir si le comptage revient à la normale et c’est le cas ! Je le vois à la valeur de la puissance estimée chaque min. Avant il était bloqué à 2000W (je le bride) tout le temps du matin au soir. Alors qu’en général c’est plutôt une gaussienne.

Je voulais voir le log car je me posais la question, est-ce que ce ne serait pas le fameux second thread de démon qui compte mal ? Mais le log ne remonte qu’à 6h ce matin dans la fenêtre html du serveur jeedouino de la pi. Je vais voir sur la pi en elle même si j’ai mieux.

revlys · Mai 20, 2020, 9:20

Bonjour @benj29,

Je voulais voir le log car je me posais la question, est-ce que ce ne serait pas le fameux second thread de démon qui compte mal ?

Ok, je pensais que tu voulais juste une notif d’exécution.
En fait, le 2nd thread ne compte pas, il stoppe et réinitialise les events des compteurs.
Les events sont indépendants des threads.

Par contre pour ton compteur PV qui s’emballe, peux-tu regarder dans le log jeedouino si tu as des lignes de type CallBack avec la mention : …La valeur reçue est inférieure à la valeur connue RSTValue…

C’est un ajout suite à ton message du 16/04 Béta sur JeedouinoExt - #18 par 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)

Bonne journée.

benj29 · Mai 20, 2020, 2:29

Le truc c’est que tes logs sont trop courts.
A 9h ce matin, je ne pouvais pas voir avant 4h.
Là, à 16h je ne peux que voir 7h sur JeedouinoPiGpio.log* ou 14h sur JeedouinoExt.log.
Du coup, je ne peux pas voir de log sur hier par exemple.
C’est dommage. Il te faudrait prévoir un rotatif comme les logs système.

De ce que je vois sur le log de JeedouinoPiGpio.log* qui est le seul à être dispo avant mon réenregistrement de compteur, pas de message de ce style.

Il y a quand même quelquechose que je n’explique pas c’est la valeur que je lis !
A 7h ce matin, la valeur en 1673 (qui est le démon PV) était de l’ordre de 2millions…

/plugins/jeedouino/core/php/Callback.php?BoardEQ=1673&35=2318233

Et quand j’ai reenregistré, il est passé à 7milliard !

[2020-05-20 08:38:02][Demon PiGpio] GET : /plugins/jeedouino/core/php/Callback.php?BoardEQ=1673&35=7746229268

Deux remarques :
avant d’enregistrer sur l’interface côté jeedom de jeedouino la valeur du compteur était déjà à 7milliards quelquechose !
d’ailleurs l’historique y était aussi… et pourtant le log avant 8h38 voit du 2millions ! et l’historique non… pourquoi ?

Tu comprends ce que je veux dire ?

Rien en tout cas sur une valeur plus faible en envoi. C’est même plutôt l’inverse. Le log côté PI donne une valeur qui est la bonne valeur de comptage (vers 2 millions) mais côté jeedom il a compté des milliards !

benj29 · Mai 20, 2020, 2:30

Tout est redevenu normal (à l’exception de la valeur farfelue initiale du compteur on va dire) mais en relatif, ça compte bien depuis l’enregistrement du démon…