Timeout défini à 5 secondes sur la fonction "exec" trop long > double voir triple "Gâchage"

Bonjour,

Le timeout défini à 5 secondes sur la fonction « exec » qui exécute la commande « com_http » est trop court, d’autant plus lorsque le temps de gâche est par exemple défini à 5 secondes également.

nuki_class.php

530 : $test = $request_http->exec($_timeout = 5);

Le Nuki, en tous cas le miens, ne répond à la command HTTP qu’une fois le temps de gâche arrivé à son terme …
Donc 1 à 5 secondes pour « gâcher » en fonction de l’état actuel verrouillé ou non et des réglages de vitesse et de course … plus 3 secondes de temps de gâche voir 5 secondes si configuré sur 5 secondes résultent sur un timeout et une relance de la commande vu que le retry par défaut de la fonction « exec » est de 3 et que le plugin Nuki ne limite pas le nombre de retry à 1.

Résultat :
Si je règle mon temps de gâche sur 3 secondes mon Nuki gâche toujours successivement 2 fois car la première fois le timeout est systématiquement dépassé et la deuxième fois on est juste à la limite inférieure du timeout.
Si je règle mon temps de gâche sur 5 secondes mon Nuki gâche toujours successivement 3 fois, une fois par retry car le timeout est dépassé à chaque fois.

Dans les deux cas le plugin log une erreur de timeout :

Erreur exécution de la commande [xxxxx][xxxxx][xxxxx] : Echec de la requête HTTP : http://xxx.xxx.xxx.xxx:8080/lockAction?token=xxxxx&nukiId=xxxxxxxx&deviceType=0&action=3&noWait=1 cURL error : Operation timed out after 5001 milliseconds with 0 bytes received`

Après avoir augmenté manuellement dans le code du plugin le timeout à 10 secondes tout se passe alors comme prévu, plus d’erreur de timeout et plus de double ou triple gâchage.

Il serait donc judicieux de mettre ce timeout à une valeur supérieur à 5, soit en continuant à le hardcoder mais à 10 ou en y donnant accès à l’utilisateur en l’ajoutant aux paramètre du plugin afin de pouvoir l’ajuster au mieux en fonction des particularités de son installation et de son Nuki.

Il serait également judicieux pour des raisons de sécu de forcer le retry à maximum 1 pour les commandes « unsafe » comme le déverrouillage et l’ouverture et de laisser le retry à 3 pour les commandes « safes » comme le verrouillage.

Pour le moment je tweak manuellement le plugin chez moi sur 15 secondes pour résoudre ce problème car sur 10 secondes + temps de gâche à 5 secondes j’arrive encore à avoir des timeouts.
Et je conditionne le retry sur le type d’action.

if ($request == 1 || $request == 3){
	$test = $request_http->exec($_timeout = 15, $_maxRetry = 1);
} else {
	$test = $request_http->exec($_timeout = 15);
}

@+

Bonjour,

La bêta intégre 2 nouvelles config avancée pour gérer le timeout et les retry cependant le problème de base était bien chez Nuki car le bridge n’était pas sensé attendre la fin de l’action avant de répondre donc cela n’aurait jamais dû pendre plus de 5s.
Il semble que cela soit corrigé dans leur firmware depuis des mois.

hello. je vois bien ces champs timeout et tentatives dans le plugin en beta. cependant on dirait que rien n’est pris en compte quand j’entre des valeurs dedans.

après sauvegarde ca conserve les chiffres mais dès que je quitte la page et retourne desus, ca revient toujours aux nombres grisés et j’ai toujours une erreur non impactante (mais que je voulais supprimer grâce aux champs):

0000|[2023-10-18 06:16:53]ERROR : Erreur exécution de la commande [NUKI][Entrée][Déverrouiller] : Echec de la requête HTTP : http://192.168.1.xx:8080/lockAction?xxxx&deviceType=0&action=1&noWait=1 cURL error : Operation timed out after 1001 milliseconds with 0 bytes received

merci

Bonjour,

Cela sera fixé dans la beta demain