Je pense que c’est l’envoi des trames sous la forme :
2020-05-23 16:27:52,153 - Thread-91 - myhomescs_command:42 - DEBUG - Received data : http://127.0.0.1:80/plugins/myhomescs/core/php/jeemyhomescs.php => {'packettype': '00', 'apikey': 'a5rK1BcwaUUcxuWVg8kP9ajOs1nRyHaf', 'trame': 'Y5Y18YZ8ZZ'}
qui posent des problèmes.
Même dans les logs certaines trames ne remontent pas alors que le plugin les a traité.
et inversement certaines trames remontes comme Y5Y18YZ8ZZ (remplacer les Y par * et Z par #) et le plugin ne les traite pas.
C’est comme si le daemon py envoyait les trames sans vérification de réception.
La réception du message est-elle vérifier sous ce format d’envoi?
Le plugin log et voit donc toutes le trames (log message daemon py) :
2020-05-23 16:39:14 Received data : => *5*1*##
---------------------------------
2020-05-23 16:39:14 Received data : => *5*9*##
---------------------------------
2020-05-23 16:39:14 Received data : => *5*5*##
---------------------------------
2020-05-23 16:39:14 Received data : => *5*7*##
---------------------------------
2020-05-23 16:39:14 Received data : => *5*11*#1##
---------------------------------
2020-05-23 16:39:14 Received data : => *5*11*#2##
---------------------------------
2020-05-23 16:39:14 Received data : => *5*18*#3##
---------------------------------
2020-05-23 16:39:14 Received data : => *5*11*#4##
---------------------------------
2020-05-23 16:39:14 Received data : => *5*18*#5##
---------------------------------
2020-05-23 16:39:14 Received data : => *5*18*#6##
---------------------------------
2020-05-23 16:39:14 Received data : => *5*18*#7##
---------------------------------
2020-05-23 16:39:14 Received data : => *5*18*#8##
Donc c’est plutôt la liaison entre le daemon et jeedom qui pose problème.
On peut pas faire différemment pour envoyer les trames ou ajouter des wait ou autre?
Ce qui m’étonne, c’est que les trames présentes des les logs ne correspondent pas à ce qu’a reçu et traité Jeedom. Par exemple, certaine requête sont présentes dans les logs et pas traitées par Jeedom et d’autres ne le sont pas alors qu’elles sont reçues et traitées par Jeedom.
Par contre l’ensemble des trames OPENWEBNET semblent correctement collectées par le demon python (a en juger par le log « myhomescsd.message »).
Lors de la trame de l’alarme le demon python semble vouloir envoyer plus de dix requêtes http simultanément. Je me demande si ce n’est pas le problème…
Je regarde le log ‹ Myhomescs › et notamment les logs type Reçu sur Jeedom : *1*34*11##: qui découlent directement du bout de code du fichier jeemyhomescs.php :
if (isset($_GET['trame'])) {
$trame = str_replace('Y', '*', $_GET['trame']);
$trame = str_replace('Z', '#', $trame);
log::add ('myhomescs','info','Reçu sur Jeedom : '.$trame);
Déclencher par la requete HTTP si je dis pas de bêtise. ?
Cela me parait étrange d’envoyer plusieurs requêtes simultanément au même endroit.
Je compare ces informations avec le log Myhomescsd ou on voit les requêtes.
Il n’y a pas vraiment d’autre moyen de communiquer ici que de transmettre individuellement chaque trame entre le code python et le code php.
En général ça ne pose aucun problème, mais j’ai bien peur que si il y a problème de perte ou de duplication de trames dans ce canal de communication, c’est un problème de performance global.
Ici on voit que toutes les trames ont bien été reçues par le daemon python, et qu’elles ont bien été transmises (en tout cas que la commande curl a bien été appelée) car le log est écrit après ça.
Si derrière ça le fichier jeemyhomescs.php ne reçoit pas exactement ce qui a été envoyé, c’est qu’il y a eu un problème avec la requête curl, et probablement simplement que le serveur PHP n’arrivait pas a honorer la requête. Ce qui est effectivement possible si il n’arrivait pas à gérer quelques dizaines de requêtes en l’espace de quelques millisecondes.
La seule possibilité serait de créer une sorte de buffer des trames entrantes dans le daemon python pour les transmettre plus lentement au serveur web. Mais la création et la gestion de ce buffer demanderai beaucoup de travail, et pourrait être une grosse source de latences voir de crash.
Alternativement il faut peut être regarder si des optimisations sont possibles dans la configuration d’Apache et/ou php pour fluidifier ça.
@apages2, tu as écrit ce code python ? Pourrais-tu donner ton avis? y-a-t-il un moyen de régler ce problème? Peut être au moment de traiter la trame qui est ensuite splité avant être envoyer au plugin simultanément?
while 1:
message = message+eventsocket.recv(1024)
trame = re.search(b"(.*?##$)", message)
if trame:
trames = re.split("##", message)
for trame in trames:
if trame == "":
continue
trame = trame+"##"
prm = trame.replace('*', 'Y')
prm = prm.replace('#', 'Z')
action['trame'] = str(prm)
command = Command(config.trigger_url,action)
command.run(timeout=config.trigger_timeout)
Pour info le split c’est moi qui l’ai rajouté parce que les trames arrivaient tellement vite sur le système qu’elles étaient concaténées en une seule ligne, parfois même incomplète.
C’était le seule moyen de transmettre des trames correctes, entières et unitaires au reste du plugin.
Ce bout de code semble avoir, à priori, des performances adéquates dans la mesure où il est capable de logger individuellement toutes les trames.
Cependant, si des optimisations sont possibles, je les accueilles à bras ouverts !
ah d’accord je ne savais pas :).
Je pensais que tes évolutions étaiement pas présentes sur la dernière version du plugin.
Oui c’est bien mieux que la version précédente.
On recevait ça avant :
[2019-02-04 21:57:32][INFO] : Envoi depuis Jeedom : *#5##
[2019-02-04 21:57:32][INFO] : Reçu sur Jeedom : *5*9*##
[2019-02-04 21:57:32][INFO] : Reçu sur Jeedom : *5*5*##*5*7*##*5*18*#1##*5*18*#2##*5*18*#3##
[2019-02-04 21:57:32][INFO] : Reçu sur Jeedom : *5*5*##*5*7*##*5*18*#1##*5*18*#2##*5*18*#3##
[2019-02-04 21:57:32][INFO] : Reçu sur Jeedom : *5*18*#5##*5*18*#6##*5*18*#7##*5*18*#8##
[2019-02-04 21:57:32][INFO] : Reçu sur Jeedom : *5*18*#5##*5*18*#6##*5*18*#7##*5*18*#8##
Oui ID en 10, il faut du coup créer l’équipement avec cet ID. J’ai mis une note dans le titre du Template. Normalement on a une seule centrale d’alarme… de toute façon il n’y a pas de where dans les trames…
C’est malheureusement bien là où je veux en venir, c’est une solution qui est loin d’être universelle.
Chez moi par exemple A1 PL0 c’est la lumière dans le jardin, pas l’alarme.
Je ne pense pas que le plugin ait été développé au départ en pensant finir par y intégrer toutes les facettes de myhome / openwebnet, et du coup ça impose des limitations qu’il devient difficile de contourner.
La principale étant ici LogicalID = APL.
(Mais aussi le LogicalID des commandes qui est la trame de la commande, ça limite l’intégration)
C’est pour ça que lorsque j’ai ajouté la gestion de l’énergie par exemple, j’ai du intercepter le traitement des trames à différents endroits pour y ajouter un « E », pour ne pas qu’il y ait de collision avec des APL existants.
Oui… J’ai créé des noms de commande ‹ info › uniques pour contourner cela.
J’ai un ID 10 également sur du WHO 1, pas de conflit pour le moment.
C’est que du statut l’alarme, j’ai locké logic ID + commande info unique
Mais ça a ses limites, c’est vrai.
Tu trouveras les fichiers ci-joint. J’espère qu’ils t’apporteront satisfaction.
J’ai finalement attribué l’ID 00 à la centrale pour deux raisons :
Suite à la conversation avec @anotherjulien sur les APL (même si cela ne change pas grand chose sur le fond, il n’y a normalement pas d’équipement en 00 sur le système)
Pour coller au mieux avec la conception du WHO 5 du système legrand SCS.
Les trames envoyées par la centrale lors de son activation et désactivation sont avec un where 0 et ce n’est à priori pas modifiable.
Il y a sur le bus legrand scs neuf canaux auxiliaires qui gèrent des événements et les transmettent à tout le système (Tous les WHO).
Ces canaux auxiliaires sont gérés de façon très simple. C’est comme pour l’état d’une lumière mais c’est sur le who 9. C’est un peu comme des actionneurs virtuels : *9*0*2## canal 2 désactivé & *9*1*2## canal 2 activé. *#9*2## pour la demande d’état par canal et *#9## pour le statut de tous les canaux (Toujours des problèmes de trame avec cette dernière commande…)
Cela permet en programmant l’alarme correctement de la gérer de façon plus « sûre » car la trame du type *9*0*1## est envoyée par l’alarme sur un événement du type enclenchée par un activateur ou autre. La trame n’est pas envoyée dans le même « paquet » que celles du statut de l’alarme.
On peut également programmer un auxiliaire sur l’intrusion d’une zone par exemple.
C’est assez limité car il y a que 9 auxiliaires mais ils simplifient certaines interface.
Certains équipements ont des fonctions pilotables avec ces auxiliaires comme le webserver sur lequel on peut activer ou désactiver le répondeur pour le portier ou alors couper le réseau du webserveur…
Ils peuvent être changés d’état par un scénario ou alors directement activer un scénario.
Pour répondre (une fois de plus car j’ai beaucoup d’idées) à la problématique soulevée par @anotherjulien, j’ai décidé de nommer les ID « AUX1 », « AUX2 » ; en modifiant le code comme suit :
