Problème détection pont Hue depuis la 4.2.1

Quand le bug sur Philips Hue sera uploader??
Je ne peux toujours rien faire.

Quel bug ?

Si tu parles de l’augmentation du timeout du discovery local (UpNp-search), cela a été publié dans la 4.3.1 il y a 25 jours (cf CHANGELOG: Release v4.3.1 · GladysAssistant/Gladys · GitHub).

Oui je parle de ça.
Ça ne fonctionne toujours pas de mon côté.

Ah mince ! Pourtant chez certains ça a réglé le problème, n’ayant pas eu de retour supplémentaire je pensais que le problème était réglé :slight_smile:

Pour information on a doublé le timeout de 5s à 10 secondes, c’est peut être pas suffisant chez toi.

Tu as un setup de dev ou pas je me rappelle plus ?

Si oui, limite tu aurais moyen de faire la modification chez toi en local (rajouter encore 5-10 secondes de timeout), et voir si ça fonctionne ? (Exemple du commit pour modifier ça: Increase Philips hue bridge scan timeout to 10s (#1185) · GladysAssistant/Gladys@757d95b · GitHub )

Sinon je peux faire un build dev en doublant le timeout

Je trouvais ça bizarre que ça soit aussi long pour régler ça.

Oui j’ai un environnement de dev mais je suis loin d’être au point.
Je vais voir ça.
@VonOx tu avais le même problème, est ce cela fonctionne chez toi?

Tu m’avais dit qu’il était possible de faire un UpNp-search et aussi N-uPnP-search pourquoi ne pas faire ça?
Qui peux le plus peux le moins!!

Oui ça avait résolu le problème, enfin je le pensais car ça ne fonctionne plus donc la source du problème est probablement ailleurs.

Car en cherchant avec @VonOx, l’augmentation du timeout resolvait le problème chez lui, donc on s’était arrêté là :slight_smile:

Oui mais le plus prend plus de temps à développer, temps qui est loin d’être infini :slight_smile:

ah mince. Ok on va continuer à investiguer alors. @VonOx tu peux faire des tests pour voir d’où ça vient ? augmenter le timeout par exemple ? Voir si c’est un problème lié à la configuration Docker ?

@lmilcent La correction de ton bug dans les scènes est live dans Gladys v4.4 :

1 Like

Hello,

Est-ce qu’ajouter la possibilité de renseigner l’IP du pont en dernier recours ne peux pas être une solution pertinente ?

Cela permettra que dans les cas vraiment particulier, l’utilisateur puisse quand même relié le pont à Gladys.

Pourquoi pas, ça peut être une bonne idée!

Ah oui si c’est faisable ça serait bien. Car pour le moment je n’ai toujours rien.

Est ce que ce problème est présent chez d’autre personne qui ont du philipps Hue?

Pas reproduit de mon côté dernièrement , c’est un peu aléatoire car j’avais le soucis.

@Tlse-vins tu ne m’avais pas répondu par rapport à Philips Hue, je voulais savoir si c’était juste un problème de timeout ou rien à voir, est ce que tu aurais moyen de tester de changer le timeout ?

Salut @pierre-gilles , je n’avais pas eu le temps de regarder avant.
je viens de tester avec mon en environnement de dév en mettant un timeout de 30 secondes et c’est pareil.
J’ai bien vérifié que le pont se trouve sur le même réseau.

@JeuFore mentionne l’utilisation de l’adresse IP, Eedomus procède comme cela. Il y a même un scan du réseau pour trouver les adresse IP et Mac des périphériques.
Est ce que c’est une solution envisageable?

L’ajout manuel est une solution envisageable oui. Après dans ton cas, si ça fonctionnait avec le N-Upnp search, je me disais qu’on pourrait faire un scan hybride UpNp + N-UpNp, c’est une autre solution.

Un scan réseau c’est exactement ce qu’on fait actuellement, sauf que ça ne fonctionne pas chez toi visiblement.

Dans un premier temps, je pense que dans ton cas remettre un mix du N-UpNp + du Upnp ça serait la solution la plus simple.

Tu aurais le temps de jeter un oeil dessus ?

J’ai fais un test en remplaçant UpNp par N-UpNp dans 2 fichiers.
Sur les logs, un bridge à été trouvé mais il n’est pas sous Gladys.
Déplus il y a plusieurs messages d’erreurs dans plusieurs fichiers.

Je pourrais te faire un retour ce soir.

Pour rappel, je ne suis pas codeur. Si tu fais les modifications je pourrais tester en les intégrante de mon côté.

Voici le résultat de la modification ci-dessus.

2021-07-04T22:22:21+0200 <info> light.getBridges.js:12 (PhilipsHueLightHandler.getBridges) PhilipsHueService: Found 1 bridges

2021-07-04T22:22:21+0200 <trace> errorMiddleware.js:49 (errorMiddleware) TypeError: Cannot read property 'serial' of undefined
at /home/linux-vins/gladys/server/services/philips-hue/lib/light/light.getBridges.js:14:49
at Array.forEach (<anonymous>)
at PhilipsHueLightHandler.getBridges (/home/linux-vins/gladys/server/services/philips-hue/lib/light/light.getBridges.js:13:16)

at processTicksAndRejections (internal/process/task_queues.js:97:5)

at async getBridges (/home/linux-vins/gladys/server/services/philips-hue/api/hue.controller.js:10:21)

From previous event:

at /home/linux-vins/gladys/server/api/middlewares/asyncMiddleware.js:4:11

at Layer.handle [as handle_request] (/home/linux-vins/gladys/server/node_modules/express/lib/router/layer.js:95:5)

at next (/home/linux-vins/gladys/server/node_modules/express/lib/router/route.js:137:13)

at /home/linux-vins/gladys/server/api/middlewares/authMiddleware.js:28:7`

@Tlse-vins l’API de N-uPnP search et UpNp search n’est pas la même, d’où l’erreur.

La documentation de la librairie:

J’ai bien lu la doc.
J’ai essayé d’enlever le pont de l’application Hue et de le remettre, j’ai faits des recherches de ponts dans les 2 cas et rien dans Gladys, aucune détection.

Le changement de N-UPnP vers UPnP fait suite à une demande de @Herve qui a eu des problèmes de détection avec la première méthode. Il fut le seul dans ce cas?

Depuis ce changement aucune détection de mon coté, et @VonOx par intermittence (si je ne dit pas de bêtise).

Est ce qu’il y a d’autre personne concerné par ce problème?
Est ce que ça fonctionne avec Gladys plus?

@pierre-gilles à ouvert une issue

pour mettre en place les 2 méthodes.

Je suis prêt à tester.