Forum Domoticz en français

Stuntteam a écrit :We have extensively tested RFLink with interrupts but that did not work as well..
Also, Nijablocks/rc-switch etc. are not even close to RFLink when it comes to the number of supported protocols and devices.

(Sorry for the english) Hi,

I was talking about how the code get the RF data, RawSignal structure in RFLink code, sure not comparing RFLink with rc-switch. I'm surprised you got unaccurate results using interrupt, this is the proper way to trap io changes. As I've said, you absolutely need to only get pulses length in the interrupt section code not doing anything else that may take time and so will corrupt the data you collect.

Not sure I've enough time (and all the required hardware) but I will try to write some code and give you more feedback.

snips a écrit : Je ne suis absolument pas sur que c'est la solution .... et si tu mesures que par miiliseconde on a bien 345 boucles alors il faudrait chercher ailleurs !!

C'est loupé.... j'ai mesuré LoopsPerMilli et j'obtiens bien 345,19 à 345,20 boucles par milliseconde !
epsilon =0,2 c'est beaucoup trop faible pour induire une variation entre les deux algo... La vérité est donc ailleurs ! je continue à chercher.

Charly86
I- j'ai lu le code qui marche pour le décodage d'Oregon avec ESP8266 et il n'y a rien de particulier......
------
explication plus détaillée
a) L'algo est adapté spécifiquement à l'Oregon (1000 usecondes le bit),donc plus dépouillé...
il n'utilise pas la méthode consistant à mesurer la durée d'un pulse pour détecter une inversion du bit (pulse long) .. mais une autre méthode très proche consistant à déterminer après 1/4 de 1000 usec du départ d'un bit, puis à 3/4 du départ du bit si la valeur du bit est inversée ou pas.... Je n'ai pas le sentiment que le problème vient de là (même s'il y a quelques valeurs seuil différentes : exemple 750 usecondes d'un côté versus 675 usecondes de l'autre...

b) Une petite différence c'est que l'algo ESP8266 utilise la fonction "delayMicroseconds()" alors que pour ta version de RFLINK tu utilises micros()...
QUestion : tu constates des pertes de trames oregon avec RFLINK sur Esp8266 comment ? avec une console sur le port USB/série de l'esp8266 comme pour l'arduino ? ou après retransmission via le WIFI ?

si c'est via le WIFI : Je ne suis pas expert de l 'ESP8266.. mais en lisant https://github.com/esp8266/Arduino/blob ... ference.md je crois comprendre que le wifi et TCp/ip est "traité" pendant les délais d'attente - delayMicroseconds()- et en fin de "loop()" sur Esp8266.
Or des fins de boucle loop il n'y en a pas beaucoup ainsi que des delayMicroseconds() dans le code RFLINK.. le problème peut-il venir de là ? (des pertes de trames WIFI en fait...)???

c) une autre différence c'est dans la structure du programme : RFLINK.. il "écoute" le 433 mhz et si un signal est détecté, il bloque une fenetre d'écoute... puis ensuite écoute la liaison série et peut bloquer une fenetre d'écoute de la liaison série.
je ne sais pas si un problème peut venir de là (RFLINK écouterait moins le 433 dans la version esp8266)

II- je ne sais pas si tu as aussi converti les fonctions de débug du RFLINK sur ESP8266 sur console série, si oui cela vaut le coup de faire un RFUDEBUG (trame inconnue) ou RFDEBUG (protocole identifié)

ou en console série (terminal) taper :
10;RFUDEBUG=ON;
ou
10;RFDEBUG=ON;

cela permet de voir si certaines trames oregon sont bien reçues par l'ESP8266 mais pas reconnues (RFUDEBUG)... et avoir la durée des pulses permettant de localiser les problèmes
et si celles qui sont reconnues (RFDEBUG)mais avec une durée des pulse qui "glissent" par rapport à version RFLINK / Arduino, ce qui peut aussi donner une piste.

P.S. tu peux aussi m'envoyer ton programme RFLINK pour ESP8266, je viens de recevoir mon NODEMCU et je suis prêt à "débuguer".

@snips & Charly86,

Je ne sais pas si ça peut vous aider mais j'ai bricolé quelque chose en me basant sur le code IRRemote utilisé dans ESPEasy https://github.com/markszabo/IRremoteESP8266 Plus exactement, j'ai extrait et copié/adapté le code de réception: IRremoteESP8266.cpp (lignes 430 a peu près jusqu'au début de la méthode decode()) de sorte a pouvoir extraire une "trame". Je ne m'explique pas pourquoi ce code n'utilise pas les versions habituelles de gestion des interruptions mais bon, il est intéressant car il gère un time out si rien n'est plus reçu pendant xxx ms (os_timer).

Au final j'ai réécrit une version rflink (heu d'ailleurs avec pas mal de soucis pour recompiler pour esp ...) en m'appuyant là dessus mais j'ai beau insister pour le moment, je sèche. J'ai bien des portions de trame tout a fait correctes mais pas complètes, j'ai peut-être raté quelque chose et je dois avouer que je ne comprends absolument rien a la façon dont rflink identifie/tronque les trames ... Il y a du bruit maintenant chez moi en RF, il faudrait que j'arrive a isoler tout ça.

Mon code rflink (attention largement modifié ...): https://drive.google.com/open?id=0B51Jz ... 2V6QmVvcW8

Bonjour rimram31,
Vacances obligent, je n'ai ni esp8266 ni PC sous les bras pour tester ! Mais dans une semaine je pourrai tester.

PS mais il me reste encore la tête pour lire le code.

Bonjour,

La partie "réception" est dans le code c et dans les grandes lignes est la reprise du code original de lecture des codes IR (interruption + timer). Cette partie remplit un tableau, time diff, lors du passage d'une trame, tableau a lire régulièrement (decode) pour "réarmer".

Après le code rflink original, je l'ai un peu sacrifié pour intégrer "a la va vite" cette partie, c'est ce que je voulais dire par "largement modifié".

je suis hors sujet, mais je voulais remercier pour l'info concernant ser2net..
je ne connaissais pas et ça m'a permis d'aller coller mon rfxcom usb sur une autre machine mieux placée dans la maison..

bon si domoticz avait pensé à nous permettre de facilement aller modifier le matériel associé à un dispositif
ou d'une manière générale, totalement pouvoir modifier un dispositif j'aurais gagné un temps précieux..
mais tout de même ça a fonctionné directement

Bonjour,
je viens de faire des essais avec un ESP12-E et un RXB6, cela fonctionne parfaitement dans mon cas.
décodage de NewKaku, chuango et Alecto dans ma configuration.

Bonjour,

J'ai intégré pour ma part RCSwitch & IRRemote avec du MQTT sur ESP8266, cela permet d'avoir une passerelle à moindre coût et facilement intégrable avec les systèmes de domotiques supportant le MQTT
https://1technophile.blogspot.fr/2016/1 ... p8266.html

J'aimerais ajouter des protocoles RF à la gateway et pour cela j'essaye de faire marcher RFLink également sur esp8266, la version R27 décode du Blyss juste en ajoutant la méthode strncasecmp mais ne décode pas le kaku, le newkaku ni la sonde météo qui est en Alecto.
Sur quel code te bases tu pour décoder le newkaku et l'alecto?

Bonjour,

Ce sujet m'intéresse voulant mettre domoticz sur une tablette je voudrais monter une passerelle rflink en wifi. Avez vous vu que nodo vend une platine pour ajouter un nodemcu sur l' arduino du rflink?

Voici le lien
https://www.nodo-shop.nl/nl/home/191-rf ... print.html