Bonjour,
Toujours le même phénomène qui se reproduit aléatoirement. Ci-joint le log du rfplayer2 en debug.
Au tout debut on voit que le rfplayer reçoit les commandes mais rien ne se passe sur jeedom. Ensuite je relance le daemon et on voit à la fin du log qu’à la reception de la commande ça réagit enfin.
Si quelqu’un à une idée du problème et surtout de la solution…
Merci
rfplayer2.txt (25,3 Ko)
Bonjour,
Difficile de dire comme çà .Je suppose que tests à répétition ON/OFF à ce que l’on voit dans les logs !
Un problème d’USB ?
Il faut essayer d’avoir log plus long et intercepter le moment ou plus de décodage mis à jour vers Jeedom.
Bonjour,
oui la répétion ce sont mes tests car plus rien ne répond derrière.
En faite il n’y aucun autre log. Lorsque le systeme est en attente aucun log, donc on ne sait pas quand le systeme s’écroule, on voit juste que ça dans les logs.
Auparavant le problème était plus souvent, j’ai diminuerla sensibilité du rfplayer2 (c’est réglable au niveau du logiciel rfplayer) car la lampe bleu clognoter souvent donc parasité ce qui amené peut être à une surcharge de la clef qui peut être planté. Suite à ce changement, c’était mieux, je pensais le phénomène régle mais non il réapparait mais plus tard . Seul solution redémarrer le daemon.
C’est pour cela que je te demandais de voir si dans un log( il faut augmenter les lignes de log) tu voyais le bug
Ah ok, je vais voir et laisser tourner jusqu’au prochain plantage
J’observe ces dernier temps exactement le même comportement avec un RF Player ancienne génération acheté en septembre 2017. Le système tient de quelques semaines à quelques jours. Mais je constate que c’est de plus en plus fréquent. Le matériel commence à vieillir ?
Dans le log, des milliers de lignes (5 lignes par seconde) comme celle ci
[2021-09-19 09:17:21][ERROR] : Error in read_rfplayer: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
C’est le même problème que dans ce sujet
Des fois, il arrive que d’autres protocoles tombent en même temps et donc difficile de déterminer lequel est à l’origine du problème. Mais cette nuit, je n’ai eu que le RP Player. Et le plugin n’est pas capable de détecter que la clé ne communique plus et de redémarrer le daemon.
La commande sudo dmesg montre une déconnexion au niveau de l’USB
[1721275.677021] ftdi_sio ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[1721275.678188] ftdi_sio ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[1754383.522749] ftdi_sio ttyUSB1: usb_serial_generic_write_bulk_callback - nonzero urb status: -71
[1754383.524235] usb 3-2: USB disconnect, device number 5
[1754383.524322] ftdi_sio ttyUSB1: error from flowcontrol urb
[1754383.524622] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[1754383.524634] ftdi_sio 3-2:1.0: device disconnected
[1754384.350331] usb 3-2: new full-speed USB device number 6 using uhci_hcd
[1754384.533906] usb 3-2: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[1754384.533909] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1754384.533910] usb 3-2: Product: RFPLAYER
[1754384.533911] usb 3-2: Manufacturer: Ziblue
[1754384.533911] usb 3-2: SerialNumber: A11SESYS
[1754384.540181] ftdi_sio 3-2:1.0: FTDI USB Serial Device converter detected
[1754384.540210] usb 3-2: Detected FT232RL
[1754384.544439] usb 3-2: FTDI USB Serial Device converter now attached to ttyUSB2
En plus, je surveille toutes les minutes si les clés sont bien branchés.
En cas de micro coupures, genre débranchement et rebranchement de la clé en 1 secondes, ce virtuel ne voit rien malheureusement passé.
Il faudrait une surveillance du log de dmesg: si la ligne Product: RFPLAYER vient d’apparaitre, hop, on fait redémarrer le daemon du plugin. Ou mieux que le plugin surveille lui-même son log 
@Chrishome60940 as-tu résolu tes problèmes depuis ?
Salut,
Même soucis pour moi avec ma Smart.
Tout est dans le vert mais rien ne répond.
J’ai effacé les log 
L’info HC HP n’a pas été remontée cette nuit ,info récupérée par un chacon 54700
==> juste redémarrer le démon suffit
Je me suis fait un scénario de contrôle 2x par jour pour être averti si le rfplayer a décroché
A suivre
Et ce n’est pas le seul plugin a se comporter de la sorte : le ZWave, c’est pareil.
Pourrais-tu détailler ton scénario, stp ?
Cette nuit j’ai vu que mon cumulus ne recevait pas l’ordre de chauffer.
L’info Heure Creuse remontée sur un 54700 restait sur « 0 » ; pourtant le relais EDF était bien collé.
Et j’ai du relancer le démon ==>3x depuis 1 semaine
J’ai des HC à 15h04 et 01h04 alors à 15h08 et 01h08 je contrôle ce qu’il se passe au niveau de l’entrée de ce 54700
et je reçois une notification en fonction de son état 1 ou 0.
Si c’est 1 : Bingo , si pas je devrai relancer le démon 
.
Scénario fait ce matin , la première notification de cet aprèm me dit que tout fonctionne…
Je me réponds. Je viens de découvrir le fonctionnement du heartbeat. Je l’ai mis à 5 minutes.
Si je débranche et rebranche la clé, le daemon redémarre dans les 5 minutes qui suivent.
Effet collatéral, le débranchement/rebranchement manuelle de cette clé me fait généralement sauter le Z-Wave, le ZigBee et l’onduleur, c’est comme si j’avais aussi débranché/rebranché les autres en même temps. Le heartbeat du Z-Wave n’a pas l’air de fonctionner.
D’une manière généralement, après le débranchement/rebranchement d’une clé, ça ne repart pas ! Et certains plugins (RFPlayer, Z-Wave) ne voient rien et leurs santés sont en vert, mais ça ne fonctionne pas.
Slt
Tu dois avoir des problèmes d’alimentation sur tes USB !
Possible.
Mais, j’ai tout fait pour minimiser les soucis : J’ai pris un modèle de marque, le hub USB a sa propre alim de 3A, les 7 dongles ont une rallonge d’1m à 1.5m. J’ai déjà changé de hub.
https://www.amazon.fr/partager-connexion-plusieurs-périphériques-DUB-H7/dp/B0000B0DL7
À part me faire une mini box domotique par dongle avec des RPi zero, je ne vois pas trop quoi faire !
Pour moi, la domotique n’est pas robuste derrière, ça doit repartir tout seul avec un message indiquant les déconnexions.
Dois être aussi possible problème avec la Smart voir avec l’équipe Jeedom , ouvrir ticket !
Je n’ai pas de Smart, Jeedom tourne dans une machine virtuelle sur NUC.
Après une possibilité non étudié, ton dongle est peut-être défaillant ?
Mea-culpa !
Donc vérifie les USB
Et comment ?
peut-être trop de charge sur l’interface USB ?
Trop de charge, pas avec une alim de 3A !
Je viens de faire quelques essais de branchements. Lorsque je rebranche 1 seul dongle, j’ai très souvent plusieurs autre dongles qui se déconnectent et reconnectent en même temps. J’ai essayé avec un autre hub presque identique, j’ai ce fonctionnement similaire. J’ai essayé le hub1 sur le hub2, idem. Le hub semble fonctionner comme ça : les ports USB ne sont pas très indépendant entre eux !
En direct sur les ports USB3 du NUC et sans hub USB2, je n’ai pas ce souci, mais je n’ai plus assez de ports. A partir du moment où il y a au moins une clé USB sur le hub, j’ai aussi le souci sur les ports du NUC et du hub.
Il faudrait que j’essaie un autre modèle de hub USB2. Mais ce n’est pas une raison pour que les plugins s’arrêtent de fonctionner en restant « vert » !
Je viens de racheter un tout autre modèle de hub USB2 non alimenté.
https://www.amazon.fr/Sabrent-HB-MCRM-480Mbit-Noir-concentrateur/dp/B00L2442H0
Et bien c’est pareil, lorsque je débranche le RFPlayer, les 3 autres dongles (Z-Stick Gen 5, ConBee II, Huawei E3531) se déconnectent aussi puis se reconnectent aussitôt. Donc, tout saute !
J’ai aussi réessayé ce nouveau hub ainsi que l’ancien D-Link 7 ports sur mon PC portable qui tourne sous Linux Mint, je n’ai pas de déconnexion de tous les dongles lorsque j’en débranche un.
Donc, ça ne vient pas ni de mes hubs USB2 ni des dongles. Il reste soit le système Debian, ProxMox ou le NUC.
