Problème de configuration réseau avec Gladys

Hello,

J’hésitais à mettre cela dans idea pour la v4 à venir mais bon.

Je viens de me rendre compte d’un comportement bizarre de gladys suivant les configurations réseau.

Ma dernière installation était la suivante :

  • Un serveur qui faisait office de point d’accès Wifi domotique ou tous les devices était connectés dessus
  • Gladys était connecté sur ce réseau wifi

Le seul hic dans cette configuration, c’est que pour la partie configuration des mi-light, il fallait que je reboot le raspberry sans l’interface eth0, que je me connecte via son ip wifi et fasse le “configuration” de mi-light. Une fois cela fait, je pouvais redémarrer le raspberry avec son interface eth0 et me servir des ampoules.

Je me suis dis que je vais changer de configuration, car si pour X ou Y raison le serveur est éteint… et bien plus de domotique. J’ai donc fait en sorte que le raspberry gère un point d’accès sans fil + dhcp pour y connecté le relai mi-light dans ce cas.

J’ai pu voir plusieurs chose bizarre :

  • Au redémarrage du raspberry avec l’interface wifi, le raspberry avait bien une route pour le réseau 192.168.50.0/24, on pouvait faire un ping sur le relai mi-light sans soucis. Mais le “configuration” du mi-light était très rapide et bien évidemment pas de device.

  • J’ai rajouter une route par défault sur l’interface wifi et la le “configuration” à fonctionné.

Par contre, si je remet la route par défaut sur l’interface eth0, il n’est pas possible d’utilise les ampoule? Elles sont uniquement accessible avec une route par défaut sur wlan0 :face_with_raised_eyebrow:

Avec le route par défault sur eth0

default via 192.168.0.254 dev eth0 onlink 
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.6 
192.168.50.0/24 dev wlan0 proto kernel scope link src 192.168.50.254 

Log gladys

0|gladys   | Unhandled rejection Error: no response timeout
0|gladys   |     at Timeout._onTimeout (/home/pi/gladys/api/hooks/milight/node_modules/node-milight-promise/src/milight-v6-mixin.js:125:26)
0|gladys   |     at ontimeout (timers.js:475:11)
0|gladys   |     at tryOnTimeout (timers.js:310:5)
0|gladys   |     at Timer.listOnTimeout (timers.js:270:5)
0|gladys   | Event : create : new Event with code : devicetype-new-value
0|gladys   | Scenario : Trigger : New event : devicetype-new-value
0|gladys   | Scenario : Trigger : Found 0 launchers with code devicetype-new-value.
0|gladys   | Unhandled rejection Error: no response timeout
0|gladys   |     at Timeout._onTimeout (/home/pi/gladys/api/hooks/milight/node_modules/node-milight-promise/src/milight-v6-mixin.js:125:26)
0|gladys   |     at ontimeout (timers.js:475:11)
0|gladys   |     at tryOnTimeout (timers.js:310:5)
0|gladys   |     at Timer.listOnTimeout (timers.js:270:5)
0|gladys   | Event : create : new Event with code : devicetype-new-value
0|gladys   | Scenario : Trigger : New event : devicetype-new-value
0|gladys   | Scenario : Trigger : Found 0 launchers with code devicetype-new-value.

Avec la route par défault sur wlan0

default dev wlan0 scope link 
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.6 
192.168.50.0/24 dev wlan0 proto kernel scope link src 192.168.50.254 

Log gladys

0|gladys   | Event : create : new Event with code : devicetype-new-value
0|gladys   | Scenario : Trigger : New event : devicetype-new-value
0|gladys   | Scenario : Trigger : Found 0 launchers with code devicetype-new-value.
0|gladys   | Event : create : new Event with code : devicetype-new-value
0|gladys   | Scenario : Trigger : New event : devicetype-new-value
0|gladys   | Scenario : Trigger : Found 0 launchers with code devicetype-new-value.

Ce que je ne comprends pas, c’est que cela était fonctionnel lorsqu’il était connecté sur un autre wifi, mais depuis que c’est lui qui gère le wifi on dirait que cela ne lui va pas.

Je me doute que cela ne sera pas corrigé pour le v3 @pierre-gilles, mais aurais-tu une idée de ou cela peut venir ?

Est-ce que dans la v4 des cas comme celui la peuvent être pris en compte dans le fonctionnement ?

Quelqu’un à une configuration comme celle-ci ?

Je sais que certains ont eu le même problème avec les milight, as tu cherché sur le forum?

Il y a effectivement des petites subtilités réseaux!

Salut @pierre-gilles

Je ne pense pas que cela soit du au module en soit, j’ai aussi le problème avec une yeelight

Route

[email protected]:/home/pi# ip r
default dev wlan0 scope link 
192.168.50.0/24 dev wlan0 proto kernel scope link src 192.168.50.254 

Ping yeelight

[email protected]:/home/pi# ping 192.168.50.2
PING 192.168.50.2 (192.168.50.2) 56(84) bytes of data.
64 bytes from 192.168.50.2: icmp_seq=1 ttl=255 time=3.58 ms
64 bytes from 192.168.50.2: icmp_seq=2 ttl=255 time=1.98 ms

Erreur de configuration

0|gladys   | Error: bind EADDRINUSE 0.0.0.0:1982
0|gladys   |     at Object._errnoException (util.js:1022:11)
0|gladys   |     at _exceptionWithHostPort (util.js:1044:20)
0|gladys   |     at _handle.lookup (dgram.js:266:18)
0|gladys   |     at _combinedTickCallback (internal/process/next_tick.js:141:11)
0|gladys   |     at process._tickDomainCallback (internal/process/next_tick.js:218:9)

C’est pas ce que je disais, c’est un problème de réseau oui, c’est pas lié au module :slight_smile: Après je sais que sur le forum des utilisateurs en avaient déjà parlé!

Salut @pierre-gilles,

J’ai enfin réussi à faire la config que je voulais avec le raspberry, c’était assez chiant pour la découverte des devices, mais le principal c’est que ce soit fonctionnel !

Je ferais un petit “tuto” au cas ou d’autres personnes sont intéréssés

2 Likes