Bonjour,
Je viens d’acquérir le tout nouveau Rfplayer. Apres un moment quelques jours, il ne répond plus et je n’ai plus de retour de mes télécommandes DIO 1.0 dans jeedom (V4.1.22).
Aucun message d’erreur nulle part. Santé Ok vert…
Apres un reboot tout repart jusque la prochaine fois…
une idée ?
Merci
Bonjour,
Oui une idée : lire ceci Comment nous aider à vous aider - ou Comment poser une bonne question? et donner des détails.
Bonjour,
Ah désolé, Je vais essayer de compléter…mais vu qu’il n’y a aucune erreur nulle part lorsque le phénomène se produit c’est difficile…
J’utilise une jeedom Smart avec dessus une clef conbee2(deconz qui marche bien) et le nouveau RFPlayer de GCE (sur une rallonge USB de 50cm).
J’ai oublié en effet de préciser que j’utilise le plugin rfplayer2.
Quand le phénomène se produit, aucune info nulle part tout est vert. J’ai vérifié également dans le log système si problème de port USB (via dmsg) mais non le port n’a pas été changé et la clef ne s’est pas déconnecté ou reconnecté.
Lorsque j’appuis sur la touche de la télécommande DIO 1.0 (dans ce cas de plantage) je vois bien la led bleu du rfplayer réagir mais au niveau du retour état de la télécommande dans jeedom rien ne bouge…
Comme si la communication entre Rfplayer2 et jeedom n’existait plus.
Pour que ça fonctionne, il faut que je redémarre le daemon (même si le daemon dit qu’il est Ok) et ensuite c’est ok pour quelques jours de nouveau.
Avez vous besoin d’autres infos ?
Merci
Cordialement
Pourriez-vous également fournir le log en mode debug au moment du problème afin que la communauté puisse vous aidez, je l’espère.
Je n’ai pas ce plugin donc je ne pense pas pouvoir aider beaucoup plus.
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
