Perte connexion Z-Stick GEN5 - Aeon Labs

[guildamo]

Bonjour à tous,

Il m'arrive régulièrement de perdre la connexion de ma clé USB Z-Stick GEN5 - Aeon Labs qui est relié à mon NAS Synology, sur lequel est installé Domoticz. Parfois plusieurs fois dans la semaine et parfois je suis tranquille 3 semaines...
Du coup j'ai quelques questions : Est-il possible d'avoir un retour d'état sur ce module depuis Domoticz ? Si oui, peut-on le programmer à redémarrer en cas de perte du module USB ?

Merci de votre éclairage

[lost]

Il m'arrive régulièrement de perdre la connexion de ma clé USB Z-Stick GEN5 - Aeon Labs qui est relié à mon NAS Synology...

Il faudrait déjà commencer par avoir une idée de ce qui peut provoquer cela? Le dmesg si on est pas trop loin de la survenue du problème ou les logs systèmes pourraient sans doute permettre de repérer un disconnect ou reset du port USB, avec un grep ciblé dessus comme ces NAS ont généralement une base Linux.

[plouf34]

Bonjour à tous,

Il m'arrive régulièrement de perdre la connexion de ma clé USB Z-Stick GEN5 - Aeon Labs qui est relié à mon NAS Synology, sur lequel est installé Domoticz. Parfois plusieurs fois dans la semaine et parfois je suis tranquille 3 semaines...
Du coup j'ai quelques questions : Est-il possible d'avoir un retour d'état sur ce module depuis Domoticz ? Si oui, peut-on le programmer à redémarrer en cas de perte du module USB ?

Merci de votre éclairage

+1

La réponse ci dessus ne m’avance guère.

[guildamo]

Le hic c'est que je me rends compte que ca a coupé quand je rentre le soir (une lumière qui ne s'allume pas, le portail qui reste fermé..) et la Z-Stcik peut être déconnectée depuis plusieurs heures

Il faut donc lancer un dmesg en SSH quand la connexion est perdue ? Je doit y chercher quoi ? Comment je configure grep pour "cibler" la coupure ? (Que de questions !)

Je suis totalement incompétent en linux, merci de votre aide par avance

Voici un dsmeg quand tout va bien : https://nofile.io/f/PPEVfJp9oXH/dsmeg.txt

[beuz33]

Le hic c'est que je me rends compte que ca a coupé quand je rentre le soir (une lumière qui ne s'allume pas, le portail qui reste fermé..) et la Z-Stcik peut être déconnectée depuis plusieurs heures

Il faut donc lancer un dmesg en SSH quand la connexion est perdue ? Je doit y chercher quoi ? Comment je configure grep pour "cibler" la coupure ? (Que de questions !)

Je suis totalement incompétent en linux, merci de votre aide par avance

Voici un dsmeg quand tout va bien : https://nofile.io/f/PPEVfJp9oXH/dsmeg.txt

j'avais le meme soucis, la coupure se produisait quand le NAS faisait une mise a jour AUTO, pour l'instant je les ai mise en manuel et comme ça je décide quand ça plante .

sinon j'avais évoqué mon problème sur une autre page du forum mais pas de réponse, pour moi la solution était de fixer les ports virtuels pour les matériels connectés au NAS

SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ENV{ID_VENDOR}=="RFXCOM", SYMLINK+="ttyUSB10"
SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ENV{ID_VENDOR}=="Silicon_Labs", SYMLINK+="ttyUSB11"
SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ENV{ID_VENDOR}=="FTDI", SYMLINK+="ttyUSB12"

cette solution évitait pas mal de conflit sur raspberry mais la je ne sais pas ou mettre ces infos sur NAS.

voila ce que je peux te dire

[guildamo]

Merci c'est une bonne info ! Je passe en manuel à défaut de mieux pour le moment

[lost]

Le hic c'est que je me rends compte que ca a coupé quand je rentre le soir (une lumière qui ne s'allume pas, le portail qui reste fermé..) et la Z-Stcik peut être déconnectée depuis plusieurs heures

Il faut donc lancer un dmesg en SSH quand la connexion est perdue ? Je doit y chercher quoi ? Comment je configure grep pour "cibler" la coupure ? (Que de questions !)

Je suis totalement incompétent en linux, merci de votre aide par avance

grep est un filtre prenant un motif en argument et tout les unices ont ceci de bien qu'ils intègrent... le manuel. Dans un terminal, "man grep" donnera l'usage. Même si on ne connaît pas précisément la commande à utiliser, c'est prévu pourvu qu'on ait un mot clef: "man -k KeyWord". Ici, "man -k motif" donne les commandes de filtrage sur motif/chaine de caractère par exemple, même si on ne les connait pas. Suffit d'avoir un mot clef pertinent pour trouver la/les commandes pouvant résoudre son problème.

Si c'est plusieurs heures après, il faudra sans doute regarder les fichiers de log, généralement dans le répertoire /var/log. Les noms peuvent cependant varier un peu... Au pire, ne pas être fin et le lancer sur tout le répertoire:

Code : Tout sélectionner

grep -i disconnect /var/log/*

En root ou éventuellement précédé d'un sudo (si le compte utilisé est "sudoer"): Va donner toutes les lignes de log ou un disconnect apparait, sans tenir compte des minuscules/majuscules (rôle de l'option -i).

Comme cela risque de ne pas donner que des lignes relatives à l'usb, on peut aussi filtrer la sortie standard par un second niveau de grep via un tube (caractère "|"):

Code : Tout sélectionner

grep -i disconnect /var/log/* | grep -i usb

On entrevoit alors à peine toute la puissance de la ligne de commande vs les clicodromes pour trouver ce qu'on cherche dans des dizaines de fichiers comportant potentiellement des dizaines de milliers de lignes en un claquement de doigts.

Ce qui chez moi donne:

/var/log/kern.log.1:Mar 13 17:20:18 kernel: [19490.930503] usb 4-1.1: USB disconnect, device number 6
/var/log/messages.1:Mar 13 17:20:18 kernel: [19490.930503] usb 4-1.1: USB disconnect, device number 6

C'est le même évènement sorti des logs kernel et message, au 1er niveau d'archivage (d'ou le .1 ajouté au nom de fichier, non encore compressé) (qui est en fait le contenu archivé du dmesg=debug messages): La dernière fois ou j'ai débranché ma z-stick pour associer un nouveau module en fait, donc ici ce n'est pas anormal.

Si c'est encore plus ancien, attention au logrotate qui va compresser régulièrement les fichiers de log (au delà du courant et du 1er niveau d'archivage) avant de poursuivre. Dans ce cas, utiliser zgrep qui va décompresser à la volée à la place de grep (sur le 1er niveau relatif au fichier).

Si c'est tout récent, le dmesg suffira. Filtrer sa sortie standard tout pareil:

Code : Tout sélectionner

dmesg | grep -i disconnect

[guildamo]

Merci pour ce retour qui explique super bien sans prendre l'auteur de la question pour un gros naze

Je n'ai pas d'info avec les 2 premières commandes et zgrep n'est pas reconnu par mon synology. Je garde la réponse au chaud pour la prochaine déconnexion sachant que je n'ai pas eu de problème lors de la dernière mise à jour manuelle.

@+

[lost]

Merci pour ce retour qui explique super bien sans prendre l'auteur de la question pour un gros naze

Je n'ai pas d'info avec les 2 premières commandes et zgrep n'est pas reconnu par mon synology. Je garde la réponse au chaud pour la prochaine déconnexion sachant que je n'ai pas eu de problème lors de la dernière mise à jour manuelle.

@+

Ensuite, une fois qu'on a un datage de l'évènement et le fichier de log qui l'a enregistré, voir ce qui s'est passé un peu avant peut éclairer sur les raisons du problème... On peut aussi regarder d'autres fichiers de log et cibler le même horodatage.

C'est pas garanti de donner des idées sur la cause à tous les coups... mais c'est assez souvent le cas quand même.

[Tractopel]

Hello à tous, truc bête mais peut être vous y avez déjà pensé ?
Les Syno peuvent mettre en veille les ports USB inutilisés...