Plantage lié au module Yeelight

#1

Salut à tous !

Depuis l’achat de mes lampes Yeelight, je rencontre un plantage qui me fais crasher Gladys presque systématiquement. La cause est simple : je débranche, par exemple la nuit, mes ampoules Yeelight et gladys ne peut plus leur envoyer de commandes. Si une commande est déclenchée, une erreur survient et gladys crash. Error: connect EHOSTUNREACH 192.168.1.98:55443

Idem, si je redémarre/démarre gladys alors que mes ampoules ne sont pas en service et connectées à la box (wifi box désactivé, ou une ampoule oubliée sur OFF), Gladys passe en “bootloop” (avec pm2) et plante à ce moment là de son démarrage :

0|gladys | Gladys Gateway: Not connected.
0|gladys | Gladys is up to date !
0|gladys | Snips :: Successfully connected to MQTT : mqtt://localhost:1883
0|gladys | Received data from RFLINK 20;00;Nodo RadioFrequencyLink - RFLink Gateway V1.1 - R48;
0|gladys | You have triggered an unhandledRejection, you may have forgotten to catch a Promise rejection:
0|gladys | Connection timeout
0|gladys | Error: connect EHOSTUNREACH 192.168.1.98:55443
0|gladys | at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1191:14)
PM2 | App [gladys:0] exited with code [1] via signal [SIGINT]

J’utilise le module Yeelight de @Pti_Nico dans la dernière version. Je ne vois pas d’autres retours sur ce problème donc je me demande si cela viens de mon installation ou du module lui même. Auriez vous des idées ? :slight_smile:

Merci d’avance ! :smile:

#2

Du module en lui même! Il faudrait catcher l’erreur. Vois avec @Pti_Nico si il peut rajouter ce try catch autour de l’appel API :slight_smile:

#3

Salut @jojolll,

J’ai reproduit le problème chez moi en éteignant physiquement une de mes lampes et je ne suis pas parvenu à corriger le problème (même avec un try catch, comme le suggère @pierre-gilles).

Il semble qu’il y a un bug dans la librairie yeelight awesome que j’utilise qui ne catche pas l’erreur dans une promise.

Je peux peut-être essayer de corriger le problème et créer une PR pour cette librairie…

1 Like
#4

@Pti_Nico Yes effectivement le try catch est peut être à faire du côté de la lib!

Après ça m’étonne quand même que tu n’ai pas réussi à catcher ça du côté du module Gladys. Ou as essayé de mettre ton try catch dans le code?

#5

J’ai mis un try catch comme ceci :

try {
    return yee.connect()
        .then((yeelight) => {
            ...
        })
        .then((res) => yee.disconnect())
        .catch((err) => {
            yee.disconnect();
            sails.log.error(`Yeelight - Error, during exec!`);
            return Promise.reject(err);
        });
} catch (err) {
    sails.log.error(`Yeelight - Unknown error!`);
    return Promise.reject(err);
}
#6

Sans voir le programme complet et sans tester c’est dur d’aider :slight_smile:

Tu parles de quelle fonction? Qui appelle cette fonction?

D’où vient la variable “yee”?

A mon avis, ton instance “yee” se promène autre part, cette instance est probablement un eventemitter et doit émettre des event “error” dans certains cas où elle n’arrive pas à faire certaines actions.

Le lifecycle de cet objet doit être proprement géré, et dès l’instanciation il doit y avoir un try catch pour protéger le reste du module.

#7

Le programme complet est là :

C’est lors du yee.connect() que ça plante.
Pour cette raison, j’ai englobé le connect() et le reste du code par le try catch, mais ça plante quand même :confused:

et la variable yee est une instance de Yeelight, code là :