Perte communication sonde température avec RFXCom

[Mick33]

Bonjour à tous,
Je me permets de réouvrir ce sujet qui n’est pas clos pour moi sur Jeedom Atlas. En effet ayant un doute sur ma sonde Temp/humidité Auriol, j’ai donc acheté une autre sonde similaire Pearl, et je constate les mêmes problèmes qu’avant voir log joint équipements: E601(Auriol) et E500 (Pearl). Les deux autres équipts E41 et E1C2100 sont des cdes prise et porte de garage , qui fonctionnent trés bien. J’ai couplé RFXCom avec RFX manager sur PC et je constate que mes sondes fonctionnent trés bien, rafraichissement des infos toutes les minutes environ. J’ai profité de l’occasion pour mettre à jour le RFXCom à sa dernière version 1047. Où est donc le problème, y a t il un timeout avec Jeedom? D’autre part dans la doc du plugin il y 'a une option qui n’est pas accessible sur ma page de configuration: " * Délai maximum autorisé entre 2 messages (min) : le délai maximum autorisé entre 2 messages avant que Jeedom ne déclare l’équipement en “timeout”. Pourquoi la doc n’est pas en phase avec le plugin? et que l’on n’est pas cet accés sur le plugin pour pouvoir jouer sur ce timeout, qui peut être est l’explication du problème?

le log:

[2022-08-07 10:52:14][DEBUG] : Signal 15 caught, exiting...
[2022-08-07 10:52:14][DEBUG] : Shutdown
[2022-08-07 10:52:14][DEBUG] : Removing PID file /tmp/jeedom/rfxcom/deamon.pid
[2022-08-07 10:52:16][INFO] : Lancement démon rfxcomd : /usr/bin/python3 /var/www/html/plugins/rfxcom/resources/rfxcomd/rfxcomd.py --device /dev/ttyUSB0 --loglevel debug --socketport 55000 --serialrate 38400 --protocol 4,6,12,13,18,20,21,22,23,31 --callback http://127.0.0.1:80/plugins/rfxcom/core/php/jeeRfxcom.php --apikey E1P1xdyU0n7rdauipInvYhY78i35DKRIxZwVP0Ryw8DAtSxjaYLlClnGqRThcF3h --cycle 0.3 --pid /tmp/jeedom/rfxcom/deamon.pid
[2022-08-07 10:52:17][INFO] : Start rfxcomd
[2022-08-07 10:52:17][INFO] : Log level : debug
[2022-08-07 10:52:17][INFO] : Socket port : 55000
[2022-08-07 10:52:17][INFO] : Socket host : 127.0.0.1
[2022-08-07 10:52:17][INFO] : PID file : /tmp/jeedom/rfxcom/deamon.pid
[2022-08-07 10:52:17][INFO] : Device : /dev/ttyUSB0
[2022-08-07 10:52:17][INFO] : Apikey : E1P1xdyU0n7rdauipInvYhY78i35DKRIxZwVP0Ryw8DAtSxjaYLlClnGqRThcF3h
[2022-08-07 10:52:17][INFO] : Callback : http://127.0.0.1:80/plugins/rfxcom/core/php/jeeRfxcom.php
[2022-08-07 10:52:17][INFO] : Cycle : 0.3
[2022-08-07 10:52:17][INFO] : Serial rate : 38400
[2022-08-07 10:52:17][INFO] : Serial timeout : 9
[2022-08-07 10:52:17][INFO] : Protocol : 4,6,12,13,18,20,21,22,23,31
[2022-08-07 10:52:17][INFO] : Find device : /dev/ttyUSB0
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x01 : Interface Response Message
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x02 : Receiver/Transmitter Message
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x10 : Lighting1 (X10, ARC, ELRO, Waveman, EMW200, IMPULS,RisingSun, Philips, Energenie, GDR2, HQ, Oase)
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x11 : Lighting2 (AC, HomeEasy EU, ANSLUT, Kambrook)
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x13 : Lighting4 (PT2262)
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x14 : Lighting5 ( LightwaveRF, Siemens, EMW100, BBSB, MDREMOTE,RSL2, OTIO, Livolo, RGB, Aoke relay, Eurodomest, RGB432W, Legrand,Avantek, IT, Kangtai)
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x15 : Lighting6 (Blyss (AE), Cuveo)
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x16 : Chime (Byron SX, Byron MP001, SelectPlus, Envivo, Alfawise)
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x17 : Fan (Siemens SF01, Itho, LucciAir, SEAV,Westinghouse,Casafan,FT1211R,Novy)
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x19 : Blinds1 (RollerTrol,Hasta,A-OK,Raex, Media Mount, DC)
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x1C : Edisio
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x1D : Honeywell ActivLink
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x1E : FunkBus
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x1F : Hunter Fan
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x20 : Security1 (X10, KD101, Visonic, Meiantech, SA30, SA33, RM174RF)
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x21 : Security2 (KeeLoq)
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x28 : Camera1 (Ninja/Robocam)
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x30 : Remote control and IR (ATI, Medion, PC Remote)
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x40 : Thermostat1 (Digimax)
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x42 : Thermostat3 (Mertik-Maxitrol G6R-H4 type)
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x4E : BBQ Temperature sensors (BBQ1)
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x4F : Temperature and rain sensors
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x50 : Temperature sensors
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x51 : Humidity sensors
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x52 : Temperature and humidity sensors
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x53 : Barometric sensors 
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x54 : Temperature, humidity and barometric sensors
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x55 : Rain sensors
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x56 : Wind sensors
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x57 : UV sensors
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x58 : Date/time sensors
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x59 : Current sensors
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x5A : Current sensors
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x5B : Current + ENERGY sensors
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x5C : Power sensors
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x5D : Weighting scale
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x60 : CARTELECTRONIC
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x70 : RFXsensor
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x71 : RFXMeter
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x72 : FS20 (FS20, FHT 8V, FHT80)
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x76 : Weather stations (WEATHER1-WEATHER2)
[2022-08-07 10:52:17][DEBUG] : Load decoder packet type 0x77 : SOLAR1
[2022-08-07 10:52:17][DEBUG] : Writing PID 19213 to /tmp/jeedom/rfxcom/deamon.pid
[2022-08-07 10:52:17][DEBUG] : Init request module v2.28.1
[2022-08-07 10:52:17][DEBUG] : Starting new HTTP connection (1): 127.0.0.1:80
[2022-08-07 10:52:17][DEBUG] : null
[2022-08-07 10:52:17][DEBUG] : http://127.0.0.1:80 "GET /plugins/rfxcom/core/php/jeeRfxcom.php?apikey=E1P1xdyU0n7rdauipInvYhY78i35DKRIxZwVP0Ryw8DAtSxjaYLlClnGqRThcF3h HTTP/1.1" 200 0
[2022-08-07 10:52:17][DEBUG] : Init serial module v3.5
[2022-08-07 10:52:17][DEBUG] : Start listening...
[2022-08-07 10:52:17][DEBUG] : Socket interface started
[2022-08-07 10:52:17][DEBUG] : LoopNetServer Thread started
[2022-08-07 10:52:17][DEBUG] : Open serial port on device: /dev/ttyUSB0, rate 38400, timeout : 9
[2022-08-07 10:52:17][DEBUG] : Listening on: [127.0.0.1:55000]
[2022-08-07 10:52:17][DEBUG] : Open Serialport
[2022-08-07 10:52:17][DEBUG] : flushOutput serial port 
[2022-08-07 10:52:17][DEBUG] : flushInput serial port 
[2022-08-07 10:52:17][DEBUG] : flushOutput serial port 
[2022-08-07 10:52:17][DEBUG] : flushInput serial port 
[2022-08-07 10:52:17][DEBUG] : Read Socket Thread Launched
[2022-08-07 10:52:17][DEBUG] : Read Device Thread Launched
[2022-08-07 10:52:18][DEBUG] : Send rfxcomd_reset
[2022-08-07 10:52:18][DEBUG] : Write data to serial port : 0d00000000000000000000000000
[2022-08-07 10:52:18][DEBUG] : Sleep 1 sec
[2022-08-07 10:52:19][DEBUG] : flushInput serial port 
[2022-08-07 10:52:19][DEBUG] : Send get status test
[2022-08-07 10:52:19][DEBUG] : Write data to serial port : 0d00000102000000000000000000
[2022-08-07 10:52:19][DEBUG] : Message: 1401000102532f0a0c2f0103011c10754658434f4d
[2022-08-07 10:52:19][DEBUG] : Decode : 1401000102532f0a0c2f0103011c10754658434f4d
[2022-08-07 10:52:19][DEBUG] : Test message: 1401000102532f0a0c2f0103011c10754658434f4d
[2022-08-07 10:52:19][DEBUG] : PacketType: 0x01
[2022-08-07 10:52:19][DEBUG] : Length: 21
[2022-08-07 10:52:19][DEBUG] : Start decoding packet type 0x01
[2022-08-07 10:52:19][DEBUG] : Data : {'packetlen': '0x14', 'packettype': '0x01', 'subtype': '0x00', 'seqnbr': '0x01', 'cmnd': '0x02', 'msg1': '0x53', 'msg2': '0x2F', 'msg3': '0x0A', 'msg4': '0x0C', 'msg5': '0x2F', 'msg6': '0x01', 'msg7': '0x03', 'msg8': '0x01', 'msg9': 28, 'msg10': '0x10', 'msg11': '0x75', 'msg12': '0x46', 'msg13': '0x58', 'msg14': '0x43', 'msg15': '0x4F', 'msg16': '0x4D'}
[2022-08-07 10:52:19][DEBUG] : Subtype = response on a mode command
[2022-08-07 10:52:19][DEBUG] : Firmware version = 0x2F
[2022-08-07 10:52:19][DEBUG] : RFXtrx433 operating at 433.92MHz
[2022-08-07 10:52:19][DEBUG] : Hardware major version = 0x03
[2022-08-07 10:52:19][DEBUG] : Hardware minor version = 0x01
[2022-08-07 10:52:19][DEBUG] : Output power = 10 dBm
[2022-08-07 10:52:19][DEBUG] : Firmware ProXL1
[2022-08-07 10:52:19][DEBUG] : Noise level (only used in special firmware) = 0x75
[2022-08-07 10:52:19][DEBUG] : undec on : 0
[2022-08-07 10:52:19][DEBUG] : Imagintronix,Opus/Alecto2010/Alecto : 0
[2022-08-07 10:52:19][DEBUG] : Byron SX,SelectPlus/Alecto5500 : 0
[2022-08-07 10:52:19][DEBUG] : RSL,Revolt/La Crosse : 0
[2022-08-07 10:52:19][DEBUG] : Lighting4/Davis EU : 1
[2022-08-07 10:52:19][DEBUG] : FineOffset,Viking/Davis US : 0
[2022-08-07 10:52:19][DEBUG] : Rubicson,Alecto,Banggood/Davis AU : 1
[2022-08-07 10:52:19][DEBUG] : AE Blyss : 0
[2022-08-07 10:52:19][DEBUG] : BlindsTx : 0
[2022-08-07 10:52:19][DEBUG] : BlindsT0 : 0
[2022-08-07 10:52:19][DEBUG] : Proguard : 0
[2022-08-07 10:52:19][DEBUG] : Legrand CAD : 0
[2022-08-07 10:52:19][DEBUG] : La Crosse : 1
[2022-08-07 10:52:19][DEBUG] : Hideki,TFA,Cresta,UPM/FS20 : 1
[2022-08-07 10:52:19][DEBUG] : AD LightwaveRF : 0
[2022-08-07 10:52:19][DEBUG] : Mertik/Edisio : 0
[2022-08-07 10:52:19][DEBUG] : Visonic : 0
[2022-08-07 10:52:19][DEBUG] : ATI/cartelectronic/Meiantech,Atlantic : 0
[2022-08-07 10:52:19][DEBUG] : Oregon Scientific/Keeloq : 1
[2022-08-07 10:52:19][DEBUG] : Meiantech,Atlantic/Proguard : 0
[2022-08-07 10:52:19][DEBUG] : HomeEasy EU : 1
[2022-08-07 10:52:19][DEBUG] : AC : 1
[2022-08-07 10:52:19][DEBUG] : ARC : 1
[2022-08-07 10:52:19][DEBUG] : X10 : 1
[2022-08-07 10:52:19][DEBUG] : FunkBus 433.42/Itho CVE RFT : 0
[2022-08-07 10:52:19][DEBUG] : MCZ 434.50/Itho CVE ECO RFT : 0
[2022-08-07 10:52:19][DEBUG] : Honeywell Chime : 0
[2022-08-07 10:52:19][DEBUG] : HomeConfort,Fan : 0
[2022-08-07 10:52:19][DEBUG] : Keeloq : 1
[2022-08-07 10:52:20][INFO] : Démon RFXcom lancé
[2022-08-07 10:52:20][DEBUG] : Client connected to [127.0.0.1:45114]
[2022-08-07 10:52:20][DEBUG] : Message read from socket: b'{"apikey":"E1P1xdyU0n7rdauipInvYhY78i35DKRIxZwVP0Ryw8DAtSxjaYLlClnGqRThcF3h","cmd":"add","device":{"id":"1C2100"}}'
[2022-08-07 10:52:20][DEBUG] : Message received in socket JEEDOM_SOCKET_MESSAGE
[2022-08-07 10:52:20][DEBUG] : Client disconnected from [127.0.0.1:45114]
[2022-08-07 10:52:20][DEBUG] : Add device : {'id': '41'}
[2022-08-07 10:52:20][DEBUG] : Client connected to [127.0.0.1:45116]
[2022-08-07 10:52:20][DEBUG] : Message read from socket: b'{"apikey":"E1P1xdyU0n7rdauipInvYhY78i35DKRIxZwVP0Ryw8DAtSxjaYLlClnGqRThcF3h","cmd":"add","device":{"id":"E601"}}'
[2022-08-07 10:52:20][DEBUG] : Client disconnected from [127.0.0.1:45116]
[2022-08-07 10:52:20][DEBUG] : Client connected to [127.0.0.1:45118]
[2022-08-07 10:52:20][DEBUG] : Message read from socket: b'{"apikey":"E1P1xdyU0n7rdauipInvYhY78i35DKRIxZwVP0Ryw8DAtSxjaYLlClnGqRThcF3h","cmd":"add","device":{"id":"E500"}}'
[2022-08-07 10:52:20][DEBUG] : Client disconnected from [127.0.0.1:45118]
[2022-08-07 10:52:20][DEBUG] : Message received in socket JEEDOM_SOCKET_MESSAGE
[2022-08-07 10:52:20][DEBUG] : Add device : {'id': '1C2100'}
[2022-08-07 10:52:20][DEBUG] : Message received in socket JEEDOM_SOCKET_MESSAGE
[2022-08-07 10:52:20][DEBUG] : Add device : {'id': 'E601'}
[2022-08-07 10:52:20][DEBUG] : Message received in socket JEEDOM_SOCKET_MESSAGE
[2022-08-07 10:52:20][DEBUG] : Add device : {'id': 'E500'}
[2022-08-07 10:52:20][DEBUG] : msg3: [0, 0, 0, 0, 1, 0, 1, 0] / 0a
[2022-08-07 10:52:20][DEBUG] : msg4: [0, 0, 0, 0, 1, 1, 0, 0] / 0c
[2022-08-07 10:52:20][DEBUG] : msg5: [0, 0, 1, 0, 1, 1, 1, 1] / 2f
[2022-08-07 10:52:20][DEBUG] : msg6: [0, 0, 0, 0, 0, 0, 0, 1] / 01
[2022-08-07 10:52:20][DEBUG] : Command: 0d00000203531C0a0c2f01000000
[2022-08-07 10:52:20][DEBUG] : Protocol actually activated 0a0c2f01
[2022-08-07 10:52:20][DEBUG] : Actual Frequency 53
[2022-08-07 10:52:20][DEBUG] : Wanted protocol 0a0c2f01



saisissez ou collez du code ici

[Mips]

Bonjour,

Après 15 jours de non réponse malgré une relance de ma part (sur un autre post) que vous avez ignoré, comment pouvez-vous prétendre rouvrir un sujet ? La moindre des politesse aurait été d’y répondre initialement.
Et lorsque l’on fait référence à un sujet précédent, la bonne pratique est de donner le lien de ce sujet ainsi tous les utilisateurs de la communautée auront le contexte: Perte de communication Sonde avec RFXCom

Ici, vous donnez un log de 6 secondes dans lequel il n’y a aucune erreur, aucun problème ?
Donc pourquoi dire ceci ?:

@Mick33

et je constate les mêmes problèmes qu’avant

Car pour rappel, aucun problème ne semblait exister… On ne sait toujours pas quel problème vous pensez rencontrer.

@Mick33

D’autre part dans la doc du plugin il y 'a une option qui n’est pas accessible sur ma page de configuration: " * Délai maximum autorisé entre 2 messages (min) : le délai maximum autorisé entre 2 messages avant que Jeedom ne déclare l’équipement en “timeout”

Ce paramètre ainsi que plusieurs autre (tout ceux non visible dans l’onglet équipement) sont en réalité des paramètres du core accessible dans la configuration avancée de l’équipement.
La documentation du plug-in devrait effectivement être corrigée.

Ce ne sont donc pas des paramètres que le plug-in gère ni n’utilise et ils n’auront aucune influence sur le comportement du module ou du plug-in.
En l’occurrence le « timeout » va juste ajouter un warning dans jeedom à different endroits, lisez la documentation du core pour avoir plus d’informations.

[Mick33]

Bonjour,
Je vois que vous êtes toujours êtes dans la polémique et dans la forme, mais pas de réponse sur le fond.

Ici, vous donnez un log de 6 secondes dans lequel il n’y a aucune erreur, aucun problème ?
Donc pourquoi dire ceci ?:

En effet je ne voulais pas vous abreuvez de données inutiles ( pour éviter de perdre du temps à lire un log de pages), j’ai sélectionné l’instant où la transmission s’arrête et cela peut durer des heures et même 2 jours, avant que cela reparte sans savoir pourquoi? Par contre contrairement à ce que vous dites, il ya une erreur à la fin, car il détecte sur l’E500, un mauvais code 0a0c2f01 « wanted protrocol » et ensuite il s’arrête pendant des heures et des jours, l’erreur est bien là.

[2022-08-07 10:52:20][DEBUG] : msg3: [0, 0, 0, 0, 1, 0, 1, 0] / 0a
[2022-08-07 10:52:20][DEBUG] : msg4: [0, 0, 0, 0, 1, 1, 0, 0] / 0c
[2022-08-07 10:52:20][DEBUG] : msg5: [0, 0, 1, 0, 1, 1, 1, 1] / 2f
[2022-08-07 10:52:20][DEBUG] : msg6: [0, 0, 0, 0, 0, 0, 0, 1] / 01
[2022-08-07 10:52:20][DEBUG] : Command: 0d00000203531C0a0c2f01000000
[2022-08-07 10:52:20][DEBUG] : Protocol actually activated 0a0c2f01
[2022-08-07 10:52:20][DEBUG] : Actual Frequency 53
[2022-08-07 10:52:20][DEBUG] : Wanted protocol 0a0c2f01

Ce paramètre ainsi que plusieurs autre (tout ceux non visible dans l’onglet équipement) sont en réalité des paramètres du core accessible dans la configuration avancée de l’équipement.
La documentation du plug-in devrait effectivement être corrigée.

Je répond point à point, et j’ai noté que la doc en effet n’était pas à jour, par contre j’ai bien sûr était dans les configurations avancées, PJ , je n’ai rien vu de clair sur le timeout?

lisez la documentation du core pour avoir plus d’informations.
Où trouve t-on la documentation du core? La documentation générale liste des champs de configuration parfois incomplet, mais ne précise pas comment on les rempli ( la procédure en fait) si vous avez cela je suis preneur.
Pas de réponse de votre part sur le fond (les interruptions): Pourquoi avec RFXCom couplé avec RFX manager sur PC le rafraichissement se passe bien et il n’y a pas d’interruptions? Le problème il est là

[Mips]

@Mick33

par contre j’ai bien sûr était dans les configurations avancées, PJ , je n’ai rien vu de clair?

Dans la configuration de l’équipement, onglet alerte.
Pour la documentation, tout le temps valable, c’est le bouton aide ? en haut à droite de l’écran. Cela affichera la documentation de la fenêtre ouverte.

@Mick33

Je vois que vous êtes toujours êtes dans la polémique et dans la forme

Note de modération : Évitez les attaques personnelles sans fondement, ce n’est pas autorisé.

Par contre oui je vous reprend sur la forme, en tant que modérateur, vous allez devoir appliquer un minimum de règles lorsque vous interviendrez sur ce forum.

Et je vous ai répondu sur le fond: je vous donné l’explication pour les paramètres manquants et je vous ai demandé le problème que vous rencontrez, car ceci:

@Mick33

j’ai sélectionné l’instant où la transmission s’arrête et cela peut durer des heures et même 2 jours, avant que cela reparte sans savoir pourquoi

On ne pouvait pas le deviner avec le log que vous avez donné sans que vous ne le précisez !

@Mick33

car il détecte sur l’E500, un mauvais code 0a0c2f01 « wanted protrocol » et ensuite il s’arrête pendant des heures et des jours, l’erreur est bien là.

C’est un log en debug, pas en erreur.
Pourquoi pensez-vous que c’est une erreur ?

A quelle distance se trouve votre sonde pour le test ?

[Mick33]

Oui c’est un log en debug, qui indique qu’il ya eu une mauvaise transmission de code et le plugin + jeedom se bloque, pourtant j’ai bien vérifié que le demon était actif, et je l’ai même relancé plusieurs fois sans succés. Pour moi c’est une erreur pour le plugin car il détecte certainement un protocole inconnu 0a0c2f01 « wanted protocol »? et il s’arrête.
Une info supplémentaire, parfois et je ne sais pas quand et pourquoi, l’affichage du log oscille entre l’anglais et le francais
Le capteur est positionné à une dizaine de mètre et j’ai même essayé à un mètre sans succés. Mais je me répéte à la même distance RFX manager + PC détecte et rafraichit toutes les minutes et l’autre Jeedom + plugin se bloque? pourtant c’est le même module/antenne, mais pas le même plugin ou interface?
Pour info , j’ai eu de longs échanges avec le sav RFXcom, qui a jeté l’éponge et prétend qu’il faut voir avec Jeedom, donc je pense qu’il y a réellement un problème.

[Mips]

Donc le problème à la base c’est que les valeurs ne remontent pas dans jeedom (je ne parle pas de logs mais sur la commande de l’équipement) ?
Question con mais j’aimerais comprendre pourquoi on se jette dans un log directement.

Si ça ne remonte pas (dans la commande donc), cela veut dire quoi exactement ? Jamais ? De temps en temps ?
Est-ce que le concept de répétition de valeur vous est connu ? Par défaut si une valeur remontée est identique à la précédente alors il n’y a pas de mise à jour.
J’explique cela car cela pourrait expliquer pourquoi vous pensez qu’il n’y a pas de mise à jour.

Pour éliminer une source de problème je ferais tous les tests avec la sonde dans la même pièce; chez moi la plupart des sondes rfx ne sont plus captées après 5 à 8m (avec les murs entre).

[Mick33]

Je pense ou c’est mon interprétation, c’est qu’après avoir reçu un protocole erroné (dû certainement à une erreur de communication , j’en conviens), Jeedom/plugin se fige et doit partir en timeout, et ne renvoi (remonte) plus les infos pour le dashboard, contrairement à RFX manager qui reçoit le même type d’erreurs certainement, mais l’interface est capable de rejeter ou de ne pas prendre en compte ces valeurs et attendre les prochaines correctes, puisque régulièrement il envoie les messages décodés.
Je ne crois pas à votre remarque si valeur égale il ne renvoi pas les données, car la température a évolué en plusieurs heures ou jour. Je peux vous transmettre des historiques en exemple.

Attention à l’interprétation les zones linéaires correspondent à des coupures.Le système trace des droites entre l’ancienne et la nouvelle valeur

[Mick33]

@Mips

Dans la configuration de l’équipement, onglet alerte.
Pour la documentation, tout le temps valable, c’est le bouton aide ? en haut à droite de l’écran. Cela affichera la documentation de la fenêtre ouverte.

Je ne vois rien dans cet onglet "alerte"qui clarifie le sujet timeout, comment interprète t-on « alerte communication » danger (en minutes), je ne vois rien qui ressemble à un réglage de timeout
Pour l’aide je connais la doc, mais ce que je vous expliquais c’est la procédure de ce que l’on met dans les champs, certains sont évidents d’autres beaucoup moins? la doc n’est pas suffisamment claire pour Monsieur tout le monde.
Concernant mon Pb, J’ai trouvé le même sur un forum domoticz et problème résolu apparemment par le réglage du timeout et avec l’alim du PI ( PJ). Pour info j’ai changé et raccourci le cable pour le pb potentiel d’alimentation sans succès. L’alim du Jeedom est elle suffisante pour le RFXcom? car apparemment c’est le point faible du RFXCom et c’est aussi l’écart entre une alim de PC et l’alim de Jeedom, avec un comportement différent, bon dans le premier cas et mauvais dans le second?

Citation
Pour éliminer une source de problème je ferais tous les tests avec la sonde dans la même pièce; chez moi la plupart des sondes rfx ne sont plus captées après 5 à 8m (avec les murs entre).

J’ai déjà fait cette manip sans succès même pièce et à 1 m de distance. Mon avis le plugin n’est pas robuste aux perturbations du protocole, un exemple concret pour étayer mes dires et qui parait peut être débile, en voulant inclure un autre objet 433 Mhz (mode inclusion), cela a réactiver la communication avec les sondes.
Par contre, je ne suis pas d’accord avec vous, sur la portée voir extrait d’article(PJ). C’est de la physique, plus la fréquence est basse et plus la portée est grande donc 433 Mhz meilleur que Zigbee, Zwave et Wifi

Fréquence :

• Plus la fréquence est basse, mieux elle pénètre à travers les obstacles, ce qui permet théoriquement de meilleures distances de communications à consommation égale ou une plus faible consommation à distance égale.
• Plus la fréquence est haute, plus le volume d’informations transmis en une seconde peut potentiellement être élevé.
• Des protocoles utilisant la même bande de fréquence peuvent se perturber (ex : ZigBee, WiFi et Bluetooth utilisent la même bande de fréquences).

[Mips]

@Mick33

Par contre, je ne suis pas d’accord avec vous, sur la portée

Y a pas à être d’accord ou pas, je vous dit ce qui est un fait chez moi
La théorie je connais aussi. Ceci dit il y a un élément clé que vous n’avez pas cité: la puissance d’émission.

Pour le reste, je ne sais pas faire de capture d’écran pour montrer la config en question pour le moment

[Mick33]

Vous vous focaliser encore sur les détails et non pas sur les vrais problèmes et les questions que je pose au début et que d’autres se sont posés:
1- Agir sur le timeout
2- Vérifier si la puissance fournie par le port USB est suffisante pour alimenter le RFXcom

[Mips]

Si j’ai déjà répondu à ceci:

@Mick33

Agir sur le timeout

Il n’y a aucun timeout configurable qui aurait la moindre influence sur le comportement du plug-in.

Réponse donnée lors de ma première intervention:

@Mips

Ce ne sont donc pas des paramètres que le plug-in gère ni n’utilise et ils n’auront aucune influence sur le comportement du module ou du plug-in.
En l’occurrence le « timeout » va juste ajouter un warning dans jeedom à different endroits, lisez la documentation du core pour avoir plus d’informations.

@Mick33

2- Vérifier si la puissance fournie par le port USB est suffisante pour alimenter le RFXcom

C’est la première fois que vous parlez de ceci, original de m’accuser de ne pas y répondre (et le prochain message vous allez m’accuser de polémiquer )

Et donc la réponse : non il n’y a aucun moyen via jeedom de vérifier la puissance électrique délivrée par un port usb (une honte, jeedom ne met pas à disposition le outils de monitoring de base pour le matériel fourni !)

[Mick33]

quote=« Mips, post:11, topic:88621 »]
C’est la première fois que vous parlez de ceci, original de m’accuser de ne pas y répondre (et le prochain message vous allez m’accuser de polémiquer )
[/quote]

[quote=« Mick33, post:8, topic:88621 »]

Concernant mon Pb, J’ai trouvé le même sur un forum domoticz et problème résolu apparemment par le réglage du timeout et avec l’alim du PI ( PJ). Pour info j’ai changé et raccourci le cable pour le pb potentiel d’alimentation sans succès. L’alim du Jeedom est elle suffisante pour le RFXcom? car apparemment c’est le point faible du RFXCom et c’est aussi l’écart entre une alim de PC et l’alim de Jeedom, avec un comportement différent, bon dans le premier cas et mauvais dans le second?

Je vous excuse le message est long et il faut tout lire?

Il ne s’agit pas de monitorer, il s’agit de vérifier par design et test de dev, si les spécifs de sortie de l’USB Jeedom sont capables de fournir la puissance demandée par RFXCom car apparemment ce n’était pas le cas pour les PI anciens, c’est tout , une simple vérif de spécif, pas de tests
C’est aux ingénieurs Jeedom de vérifier cela et dommage que l’on ne puisse agir sur le timeout que Jeedom a du supprimer car existait avant et toujours présent dans la doc de configuration du plugin? Le concurrent indiqué dans mes captures d’ecran le prévoyait et cela a permis de masquer au moins le problème et éviter des interruptions.
Vous me proposez peut être d’'investir dans une grande antenne 433Mhz sans être convaincu du résultat? Cela fait cher pour une mesure de température après l’achat de RFXcom.

[Mips]

@Mick33

Je vous excuse le message est long et il faut tout lire?

Oui c’est ça. Je n’ai pas assez de compétence pour déchiffrer les pavés de textes sans fin; je n’ai pas le niveau et je n’en suis pas désolé.

@Mick33

Vous me proposez peut être d’'investir dans une grande antenne 433Mhz sans être convaincu du résultat?

Absolument pas, je n’ai jamais écrit ça.

Par contre ce que je vous propose c’est d’utiliser domoticz au lieu de jeedom.

Sur ce je vais laisser la place à d’autres et retourner profiter de la piscine et prendre l’apero avant d’aller au resto, c’est ce que je n’aurais pas dû arrêter de faire vu que je suis en vacances

[Mick33]

Bonne baignade, bon apéro et bonnes vacances, je suis d’accord c’est mieux.Il faut savoir profiter du bon temps

[Mick33]

Bonjour à tous
Maintenant que les vacances sont terminées et que j’ai pris le temps d’analyser ce problème qui me tenait à coeur, de part les critiques ou le mépris que j’ai pu avoir par certains de la communauté? Voici mon analyse, qui n’engage que moi et j’accepte volontiers les critiques ou autres solutions:
D’abord les faits:
Cas 1- Pas de problème de perte de communication de sondes de températures RFXtr avec RFX manager sur PC, et portée de la communication satisfaisante (> 20 m)
Cas 2- RFXTr couplé à Jeedom, portée limitée (< 6m) et pertes de communications aléatoires.
Mon analyse suite à mesures à l’oscilloscope
Cas 1: bruit sur alimentation 5V USB:< 70 mV crête à crête
Cas 2: bruit sur alimentation 5V USB:< 1000 mV crête à crête
Après échange avec le sav RFXCom, ils préconisent une tension de bruit <200 mV crête à crête, donc Jeedom serait hors spécification. Après communication avec le support Jeedom, on me dit que le bruit relevé serait anormal. Donc un deuxième échange du matériel, mais à réception du nouveau matériel je mesure la même chose. De plus le sav Domadoo, serait incapable de mesurer ce bruit à l’oscillo car pas de moyen? mesure à l’oreille uniquement pour validation??
Donc j’en conclue qu’il faut accepter ce matériel hors spécification puisque ce bruit serait la norme (3/3 équipements)
Solution:
La seule solution que j’ai trouvée et préconisée par la communauté et qui marche dans mon cas:

• Alimenter RFXtr au travers d’un hub USB
• Rallonger de 1 à 2 m le cable USB pour éloigner le RFXtr de Jeedom
  En fait cette solution masque le problème initial de bruit d’alimentation, car le hub USB et le cable font office de filtre RF. En effet, j’ai pu démontrer que l’antenne RFXtr placée à moins de 1m de Jeedom fonctionnait parfaitement avec RFXmanager+ PC. J’en conclue donc que le problème est dû à une perturbation électromagnétique par conduction et non pas par rayonnement, comme la communauté le laisser penser.

En conclusion, si on veut améliorer la communication de RFXtr, il est indispensable que Jeedom, respecte la spécification de RFXCOM (bruit alim < 200mV), aussi je recommande une amélioration de l’alim 5V USB Jeedom par ajout de filtres EMI, afin de minimiser ce bruit important sur les sorties USB, qui perturbe le fonctionnement de RFXCom. La solution du rajout d’un hub USB alimenté + rallonge n’est qu’un palliatif pas très sexy pour masquer un problème de conception.

[Mick33]

Suite à mes investigations sur un problème de détection de capteur température avec RFXCOM (portée limitée < 5 m). J’ai pu mesurer (sur 2 box différentes) un niveau de bruit anormalement élevé (1V crête à crête) sur l’alimentation fournit par l’USB. Alors que le constructeur RFXCom (info SAV RFXCOM), spécifie un bruit < 200mV. Lorsque l’on couple RFXtr à un PC et avec RFX manager, le problème de portée est résolu, pour info l’alim USB a un bruit < 70mV, ce qui confirme la cause du problème avec Jeedom. Le bruit de 1 Vcac sur Jeedom a une fréquence de 25 Khz avec des sur-oscillation lors des commutations de l’alim à découpage je suppose.
Aussi, il faudrait améliorer le filtrage de cette alim USB, de manière à respecter la spécification de RFXCom, pour avoir un fonctionnement optimum (sans hub USB et rallonge de cable, qui masque en fait le problème). D’autre part, je pense que ce bruit anormalement élevé n’est pas du tout sain, et pourrait perturber d’autres fonctionnalités ( Zigbee, Zwave…)
A moins que ce problème n’existe pas et que je sois tombé malheureusement sur des box hors spécification, mais 3 box sur 3 me semble statistiquement peu probable ou peut être même lot de fabrication défectueux?

[JeedGeek]

Bonsoir @Mick33 ,
Très intéressant.
Perso j’ai changé l’Alim pour une raison différente : pendant les fortes chaleurs j’ai trouvé qu’elle chauffait vraiment trop (ce n’est que mon avis personnel mais je n’aime pas du tout avoir une alim qui est bien « chaude »).

Cela fait un peu plus d’un mois que j’ai remplacé l’alimentation de mon Jeedom Atlas par une Alim Apple « Adaptateur secteur USB‑C 67 W » que j’avais sous le coude et depuis c’est nickel et « mon » Atlas fonctionne toujours bien ().

(Il y a plusieurs mois j’ai aussi changé l’Alim de mon AirSend pour la même raison (Chauffait trop et tension trop élevée à mon gout (5.52V à vide) pour du 5V).

Il faut prendre conscience que beaucoup de constructeurs (pas tous) fournissent avec leurs matériels des alimentations au plus juste, en puissance et qualitativement (question de marge et d’ €€€).

Perso, le sachant, je change l’alim quand cela ne me conviens pas.

[Mick33]

Bonjour @JeedGeek
Intéressant ton commentaire, mais le souci de réception avec RFXCOM est un problème de bruit et non de puissance. Les mesures de bruit important que j’ai faite à l’oscillo, ont été effectuée à vide et avec un cable USB sectionné pour avoir accés aux 2 fils d’alimentation. RFXCom ne demande pas beaucoup de puissance:

• Receive mode: 28 mA (0.14Watt)
• Transmit mode: 45 mA

Malgré cela, je trouve que ta modification me semble intéressante, car du bruit sur une alimentation n’est jamais sain et peu provoquer des dysfonctionnements sur Zigbee, Zwave et Wifi. Je vais essayer ta manip, pour voir si cela améliore la réception RFXCom et également ma réception wifi, qui me parait trés limitée?