RFXCOM se fige depuis la dernière MAJ

[Qben]

Bonjour

Ton alim n aurait elle pas un soucis ?

[benj29]

Hello, de quelle alimentation parles-tu ?

J'ai restauré ma VM à une date ultérieure et surtout j'ai désactivé pour l'instant une mise à jour béta d'un plugin (chauffe eau) qui faisait une répétition de valeur et tout semble OK.

Je vais creuser. Car je veux comprendre.

[Fabrice]

Bonjour,

Si c'est possible, débranche TOUS tes appareils (par lot de 50%) en RFX pour voir si tu n'a pas l'un d'eux qui "spam" ton installation.

Je ne sais pas si tu peux simuler cela en désactivant TOUS les protocoles.

[benj29]

Bonsoir Fabrice,

En fait, j'y ai pensé.
J'ai utilisé le second RFXCOM que l'on m'a prêté sur mon PC windows pour écouter le 433 avec les mêmes canaux activés.
Et c'est le calme plat !

Code : Tout sélectionner

------------------------------------------------
08/01/2019 06:31:45:745
Packettype    = Lighting2
subtype       = AC
Sequence nbr  = 112
ID            = 256652C decimal:39216428
Unit          = 1
Command       = Off
Signal level  = 7  -64dBm
------------------------------------------------
08/01/2019 06:31:49:026
Packettype    = Lighting2
subtype       = AC
Sequence nbr  = 113
ID            = 280B68F decimal:41989775
Unit          = 9
Command       = Off
Signal level  = 7  -64dBm
------------------------------------------------
08/01/2019 06:45:37:848
Packettype    = Lighting2
subtype       = AC
Sequence nbr  = 114
ID            = 0FE919A decimal:16683418
Unit          = 1
Command       = On
Signal level  = 7  -64dBm
------------------------------------------------
08/01/2019 06:45:38:389
Packettype    = Lighting2
subtype       = AC
Sequence nbr  = 115
ID            = 0FE919A decimal:16683418
Unit          = 1
Command       = Off
Signal level  = 7  -64dBm
------------------------------------------------
08/01/2019 06:52:13:839
Packettype    = Lighting2
subtype       = AC
Sequence nbr  = 116
ID            = 2D9E6A4 decimal:47834788
Unit          = 3
Command       = On
Signal level  = 6  -72dBm

J'ai comme un énorme doute sur un plugin que mika m'a fourni avec une répétition de commande, je lui ai indiqué sur un autre fil.

[Qben]

Pardon. Je pensais que tu étais sur toi !


Édit.. rpi !

[benj29]

Sur moi ?

Envoyé de mon JSN-L21 en utilisant Tapatalk

[squarky]

Bonjour,

Je viens de trouver ce post car j'ai eu la même mésaventure que certains d'entre vous.
Aujourd'hui en regardant par hasard les températures de mon jeedom, je m'aperçoit que mes sondes Oregon ne remontent plus aucune information, ainsi que mon OWL CM180 (pince ampermétrique). Toutes les valeurs sont figées depuis la même heure.

Je remarque que la log du plugin indique cela :

Code : Tout sélectionner

[2019-01-21 18:16:04][ERROR] : Error: Incoming packet not valid length (85 F2 02 00 00 16 42 00 00 00 00 00 00 69 04 02 01 00 00 04 02 01 00 00 04 02 01 00 00 11 5A 02 36 85 F2 01 00 00 16 21 00 00 00 00 00 00 69 0A 52 01 37 B1 02 00 C9 30 01 89 11 5A 02 38 85 F2 00 00 00 15 F1 00 00 72 D3 EB 88 69 11 5A 02 39 85 F2 04 00 00 16 32 00 00 00 00 00 00 69 0A 52 0A 3A 9D F9 00 01 38 01 79 0A 52 01 3B B1 02 00 CA 30 01 89 11 5A 02 3C 85 F2 02 00 00 16 52 00 00 00 00).
[2019-01-21 18:16:52][ERROR] : Error: Incoming packet not valid length (69 11 5A 02 3D 85 F2 01 00 00 16 32 00 00 00 00 00 00 69 0A 52 01 3E 5A 04 00 C0 32 00 69 11 5A 02 3F 85 F2 00 00 00 16 21 00 00 72 D4 3F 58 69 11 5A 02 40 85 F2 04 00 00 15 F1 00 00 00 00 00 00 69 0A 52 01 41 B1 02 00 CA 30 01 89 0A 52 0A 42 9D F9 00 01 38 01 79 11 5A 02 43 85 F2 03 00 00 15 F1 00 00 00 00).
[2019-01-21 18:17:44][ERROR] : Error: Incoming packet not valid length (69 0A 52 01 44 5A 04 00 C0 32 00 69 11 5A 02 45 85 F2 02 00 00 16 32 00 00 00 00 00 00 69 11 5A 02 46 85 F2 01 00 00 16 42 00 00 00 00 00 00 69 0A 52 01 47 B1 02 00 CA 30 01 89 11 5A 02 48 85 F2 00 00 00 19 46 00 00 72 D4 94 1E 69 11 5A 02 49 85 F2 04 00 00 16 21 00 00 00 00 00 00 69 0A 52 01 4A 5A 04 00 C0).
[2019-01-21 18:18:16][ERROR] : Error: Incoming packet not valid length (32 00 69 0A 52 0A 4B 9D F9 00 01 38 01 79 11 5A 02 4C 85 F2 03 00 00 17 A4 00 00 00 00 00 00 69 11 5A 02 4D 85 F2 01 00 00 17 84 00 00 00 00 00 00).
[2019-01-21 18:19:04][ERROR] : Error: Incoming packet not valid length (69 0A 52 01 4E 5A 04 00 C0 32 00 69 11 5A 02 4F 85 F2 00 00 00 1A 88 00 00 72 D4 EA 52 69 11 5A 02 50 85 F2 04 00 00 16 D3 00 00 00 00 00 00 69 0A 52 0A 51 9D F9 00 01 38 01 79 0A 52 01 52 B1 02 00 C9 30 01 89 11 5A 02 53 85 F2 03 00 00 17 03 00 00 00 00 00 00 69 11 5A 02 54 85 F2 02 00 00 17 13 00 00 00 00).
[2019-01-21 18:19:41][ERROR] : Error: Incoming packet not valid length (69 04 02 01 00 00 04 02 01 00 00 0A 52 01 55 5A 04 00 C0 31 00 69 11 5A 02 56 85 F2 01 00 00 16 42 00 00 00 00 00 00 69 08 50 0A 57 30 01 00 15 40 0A 52 01 58 B1 02 00 C9 30 01 89 11 5A 02 59 85 F2 00 00 00 0D 44 00 00 72 D5 37 92 69 11 5A 02 5A 85 F2 04 00 00 0A 2F 00 00 00 00 00 00 69 0A 52 0A 5B 9D F9 00 01 38).
[2019-01-23 17:00:05][ERROR] : Error: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
Unhandled exception in thread started by <function read_rfxcom at 0x75ecc5b0>
Traceback (most recent call last):
File "/var/www/html/plugins/rfxcom/resources/rfxcomd/rfxcomd.py", line 781, in read_rfxcom
message = byte + globals.JEEDOM_SERIAL.readbytes(ord(byte))
File "/var/www/html/plugins/rfxcom/resources/rfxcomd/jeedom/jeedom.py", line 288, in readbytes
buf += byte
UnboundLocalError: local variable 'byte' referenced before assignment

Je précise que mon installation n'a pas bougé depuis plusieurs mois (pas d'ajout de capteur, pas de rajout de plugin, bref aucun bidouillage), la seule chose que j'ai faite ce sont des mises à jour de jeedom/plugin qui trainaient depuis des mois, dont le rfxcom.

C'est la première fois que je constate ce problème et la mise à jour récente du plugin me laisse penser que c'est lié...

Par contre j'ai l'impression que personne n'a trouvé de cause ou de solution à ce problème ...

Quelqu'un a pris le temps d'ouvrir un ticket ?

[fredlamour]

Bonjour,
Je suis un peu dans le même cas.
Je dis un peu parce qu'en fait, c'est via le plugin RFXCom que je m'en suis rendu compte et plus précisément un scénario qui vérifie la mise à jour de mes sondes de température.
En fait cela touche pour moi 2 plugins en même temps : RFXCom qui est figé et TéléInfo qui me dit "pas de port" alors que le lsusb le voit, rien dans la liste sur la config du plugin.
Pour RFXCom, le redémarrage du plugin résoud des fois le problème mais seulement un redémarrage fait tout fonctionner.
Une chose est étrange dans tout cela. Lorsque c'est planté, je vois que depuis 6:30 du matin à chaque fois, il n'y a plus de mise à jour des sondes. Par contre, après le redémarrage, j'ai des données dans l’historique pour la période 6:30 jusqu'au redémarrage.
Je parle de 6:30 et c'est toujours à cette heure là que cela plante. J'ai regardé le moteur de cron et je n'ai rien qui démarre à cette heure là...

Actuellement je suis sur un NUC mais je vais tout migrer ce week end sur ma smart que j'avais mis de côté le temps de résoudre un problème avec le plugin thermostat.
L'idée est d'écarter un soucis d'alimentation des ports usb bien que je sois sur un hub alimenté.

[JMPJEEDOM]

Bonjour,
J'ai exactement le même problème de remontée de valeur (sondes température Oregon) depuis la dernière mise à jour du plugin.
Seule solution,le relancer.
Le problème est soulevé depuis près de 3 mois.
Faut-il ouvrir un ticket, le plugin RFXcom est quand même un plugin officiel.

[guigui69]

Bonjour,
Idem, même problème.
J'ai également un rflink, qui lui ne pose aucun soucis.
J'ai pallié au problème avec un reboot journalier, jusque ce jour où seule la réinstallation des dépendances m'a permis de rendre opérationnel rfxcom.

[idem]

Bonjour,

pareil pour moi.
Jeedom tourne sur un NUC, et mon rfxcom est a jour.
1 mise a jour sur 5 j'ai tout qui pète parce qu un protocole va plus ou n'est plus compatible.
Et depuis la dernière mise a jour, je n'ai que 3 sondes (2 oregon et 1 no name) sur 10 qui remonte (les autres sont des sondes chinoises a 8€) , et aucun de mes détecteurs d ouverture de porte (Chacon).

Vivement la prochaine mise a jour.

[bronche]

Bonsoir,
Moi j'ai solutionné provisoirement avec un scénario.
Un simple :

- Nom du scénario : Relance Daemon
- Mode du scénario : schedule
- Programmation : 5 * * * *

SI stateDuration(#[Cuisine][Sonde Cuisine][Température]#) > 3600 and stateDuration(#[Salon][Sonde][Température]# )> 3600
ALORS
CODE
rfxcom::deamon_stop();

On vérifie l'absence de remontées sur deux sondes pendant 1 heure. Si oui on stop le daemon. Il se relancera seul.
Ca fonctionne bien.
Phil

[Fabrice]

Bonjour,

Dans la partie FAQ de la documentation de ce plugin, il y a une référence à ce problème :
Alimentation trop faible
Câble USB à remplacer (ou trop long)
...

[idem]

Bonjour,

Dans la partie FAQ de la documentation de ce plugin, il y a une référence à ce problème :
Alimentation trop faible
Câble USB à remplacer (ou trop long)
...

Oui, mais je suis sur un NUC, avec un Hub alimenté, et un câble de qualité.
D'autant plus que ces dysfonctionnements n'interviennent que suite a des MAJ du plugin.
L'avant dernière fois j'ai du attendre une nouvelle mise à jour et tout était rentré dans l'ordre.
Avec le même comportement :
Il démarre, tout se passe bien... et d'un coup, il part en vrille :

[2019-02-11 14:35:04][ERROR] : Error in read_rfxcom: [Errno 11] Resource temporarily unavailable
[2019-02-11 14:47:09][ERROR] : Error in read_rfxcom: [Errno 11] Resource temporarily unavailable
[2019-02-11 14:47:18][ERROR] : Error in read_rfxcom: [Errno 11] Resource temporarily unavailable
[2019-02-11 14:52:34][ERROR] : Error in read_rfxcom: [Errno 11] Resource temporarily unavailable
[2019-02-11 15:10:03][ERROR] : Error in read_rfxcom: [Errno 11] Resource temporarily unavailable

Sinon, on pensait à un objet qui faisait planté le RFXcom. Du coup, j'ai viré tous les protocoles inutiles, et il reste que 3 protocoles d'activés :
Rubicson,Alecto,Banggood Enabled
La Crosse Enabled
Oregon Scientific Enabled

[stalex]

Bonjour,

j'ai le meme souci.
Effectivement la solution de Phil semble bien fonctionne, faire un deamon_stop après avoir détecter une absence de remontée d'info après un certain temps. Moi j'ai mis 15 minutes sans réception de mes sondes de température.

[stalex]

Edit: par contre je fais donc tourner le scénario toutes les 5 minutes, et j'ai fait l'essai de m'envoyer via le scénario un SMS lorsque je fais un deamon_stop(). Là, après deja deux appels au scénario, je suis toujours en dépassement de temps sur mes sondes qui ne répondent plus.
Savez vous combien de temps peut prendre un deamon_stop() pour redémarrer le rfxcom ?
Merci.

[fredlamour]

Bonjour, j'ai acheté 3 sondes oregon pour remplacer 3 sondes chinoises et je les ai mises sur RFPLAYER2 au lieu de RFXCOM, j'ai supprimé les anciennes et pour le moment je n'ai plus rencontré le problème.

[mortyre]

Bonjour
Je viens de constater le même problème sur deux de mes sondes OREgon. Savez vous si un ticket a été ouvert pour signaler le problème ?

[vince_007]

Salut,

Je me joint à ma discussion car j'ai le même problème. Tout fonctionnait bien puis j'ai la réception du rfxcom qui se fige, l'émission elle fonctionne bien.
Le rfxcom reçoit bien les commandes car la led verte s'allume mais jeedom ne reçoit plus rien.
En redémarrant le plugin, ça repart un certains temps puis ça se refige.

Je suis sur raspberry pi3b+ sur disque ssd. Mon installation n'a que quelques semaines, tout a bien fonctionné jusqu'à hier où mon rfxcom déconne. Je n'ai rien fait de special sur l'instal.

[DuplO]

Bonjour,

Pour suivre le post depuis un moment, je ne pense pas qu'un ticket ait été ouvert.