RFLink open source

Bonjour à tous,

Pour avoir survolé les échanges sur le forum officiel (Let's control it - RFLink), le gestionnaire actuel est visiblement échaudé dès qu'on parle de ré-ouvrir le code et se cache derrière une close de NDA (sur quoi au juste?) et qu'un Arduino Méga est indispensable (et ne coûte pas cher).
Au point qu'après avoir relancé hier le sujet (de ce même forum officiel) sur l'ouverture partielle du code ... Le sujet entier a été effacé, sans explication bien sûr!

Je crois hélas qu'un fork est le bienvenu, le projet en lui même gardant un grand intérêt!

Pour ma part, je suis parti de la dernière release ouverte (R33), que j'ai adaptée et recompilé pour un Arduino Nano, avec seulement les 3 plugins dont j'ai besoin (Newkaku, Lascrosse et Xiron)
Par dessus, j'ai connecté un ESP01S pour faire passerelle MQTT.

Voilà pour mes 10 cents :wink:

Bonjour,
Effectivement je pense aussi qu'un fork est indispensable pour continuer à faire vivre le projet.
Je remarque qu'il y a eu plusieurs tentatives et qu'il est difficile de faire converger vers un projet unique.
Il serait intéressant de réussir à fédérer les efforts

Premier portage sur ESP (plus actif depuis 1 an)

Une branche que j'ai créée qui fonctionne sur ESP et Mega

Personnellement je pense qu'il faudrait continuer sur cette branche car une solution qui tourne sur un ESP sans un autre Arduino est un net avantage par rapport à Arduino + ESP.

L'avantage du couple Arduino "R33" + ESP est qu'il marche de façon fiable.
C'est déjà assez compact et facile à tester.

Mais c'est vrai qu'une solution avec seulement un ESP paraît séduisante.
Je vais faire quelques tests dans ce sens :wink:

Bonjour

Je n'ai pas actuellemnt de projet avec RF-LINK mais je garde le lien du portage de RFLINK sur ESP32 d'ettimou
En cas de besoin c'est sur cette base (ESP32 ou ESP8266 en solo, 'débarassés de cartes Arduino'...) que je partirai !

super! n'hésitez pas à essayer cette version et me faire des retours.

etimou:
super! n'hésitez pas à essayer cette version et me faire des retours.

Quelques retours alors!

Par défaut, j'ai le "compiler warning" de l'Arduino IDE sur "More". Il y a pas mal de petits défauts remontés (incohérence du format de variables, méthode dont le booléen de retour est aléatoire, formatage des sprintf erronées) ...

Mais ça marche!!! Le protocole Kaku détecte directement mes interrupteurs DIO.
J'utilise pour le moment un ESP8266 (NodeMCUv2 pour les tests, ESP01S en cible).

J'ai surtout retravaillé la fonction FetchSignal(), pêle-mêle :

  • Plus de traces des numloops et cie (une alternative pour mesurer les pulsations, utilisée dans le RFLink initial, mais qui est liée à la vitesse d'exécution, qui elle même dépend du MCU et des optimisations du compilateur...)
  • Ma version commence à partir d'une pulsation longue de niveau bas ("Preamble") et non du niveau haut qui la précède (dont on ne peut que minorer la durée)
  • On ne travaille que sur des durées (écart entre deux timestamps), ce qui enlève tout problème d'overflow.
  • Le nombre de variables a été réduit au minimum et passé en static (adieu min, max et mean).
  • Les #define généraux ont été repris et/ou revus (entre autre on explicite dans le nom si ce sont des ms ou µs).
  • Des #define macros ont été créés pour la lisibilité.
  • La table Rawsignal.Pulses[] contient de nouveau des bytes (après une division par RAWSIGNAL_SAMPLE_RATE). Ceci permet de réutiliser les plugins existant de la R33! (Kaku, Lascrosse V1 et Xiron fonctionnent).

Voilà! Pour le reste et toujours pour minimiser le travail sur les plugins, je réintègre du code R33 complété par la classique gestion du WiFi et de MQTT (PubSubClient).

A présent, j'ai une passerelle ESP8266 433 vers MQTT autonome! Plus qu'à longuement éprouver le tout!

génial!
C'est exactement le type de coopération que j'attendais!
Je pense qu'il est temps de créer un dépôt commun ou chacun puisse mettre sa pierre à l'édifice. Et pour les autres, tester les évolutions.
Quelqu'un peut le faire? (je ne suis pas très calé)

Concernant les prochaines améliorations, je pense qu'il faut continuer dans le nettoyage du code et l'optimisation, pour éventuellement le faire tourner sur un ATMega328p. Beaucoup d'utilisateurs semblent freinés par l'utilisation d'un Mega ou ESPxxxx.

Voici mon repository, mis à jour a posteriori, avec les versions communication série.
J'avoue que ce n'est pas simple à gérer, alors je prends tous les conseils!

La branche master correspond à l'Uno.
La branche esp aux ESP8266 et cie (Série, sans MQTT).

Bonjour
Je garde ce topic à l'oeil
Je n'ai pas beaucoup de temps en ce moment pour regarder vos aavancées

Mais j'avais bien aimé le concept RFLINK avec ses modules "protocoles

C'est dommage que son concepteur ai "jeté l'éponge" du suivi , d'aprés ce que j'en ai compris , il en a eu marre de se faire engueuler

Artouste:
Bonjour
Je garde ce topic à l'oeil
Je n'ai pas beaucoup de temps en ce moment pour regarder vos aavancées

Mais j'avais bien aimé le concept RFLINK avec ses modules "protocoles

C'est dommage que son concepteur ai "jeté l'éponge" du suivi , d'aprés ce que j'en ai compris , il en a eu marre de se faire engueuler

J'aime également ces protocoles à rajouter comme on le souhaite.
Je partage la même déception sur l'arrêt/point mort du projet initial.
C'est sûr qu'il est difficile de tester des équipements que l'on a pas... Et la frustration se trouve des deux côtés.

StuntTeam, pour l'avoir lu récemment est très échaudé.
Brider le projet au Mega (avec tous les protocoles actifs) permet d'en simplifier énormément le support et de fournir une firmware unique compilé par ses soins.
Cela offre une prise en main très facile pour celui qui ne veut pas mettre les mains dans le cambouis... Mais cela annihile toute volonté d'évolution de la communauté.
Est-ce que ce bridage est pour continuer de vendre les cartes filles de NodoShop? Je doute que ce soit très lucratif.
En tout cas, comme dit avant, quand j'ai relancé le sujet de réouvrir le code sur le forum RFLink, mon post (et tout le sujet en fait) a été supprimé.

Même expérience avec StuntTeam…

Le projet n'a pas l'air complétement arrêté.
Message datant du 9 juillet:

We are still around and working on additions and improvements including a massive rewrite of the code. There are various ideas that are being worked out and there are also a bunch of different versions that we are testing. However, this all takes a lot of time.

J'ai peur que ces améliorations ne soient malheureusement pas partagées...

Il y a même un message plus récent, le 6 septembre :
« Holidays are over and work is progressing.. more soon. »
S’agit-il d’un RFLink sur ESP8266, avec l’interface d’ESP Easy?
Mystère insoutenable!

Pour rappel, la dernière release, R48, date d’octobre 2017...

  • Plus de traces des numloops et cie (une alternative pour mesurer les pulsations, utilisée dans le RFLink initial, mais qui est liée à la vitesse d'exécution, qui elle même dépend du MCU et des optimisations du compilateur...)

@mrives: J'ai pas regardé en détail mais je vois qu'il y a encore des numloops et maxloops...
Tu as uploadé la bonne version?

etimou:
@mrives: J'ai pas regardé en détail mais je vois qu'il y a encore des numloops et maxloops...
Tu as uploadé la bonne version?

La version que tu cherches est sur la Branche "esp".

Pour la branche Master ("uno"), je reste sur les numloops.
Cette torture doit permettre une mesure plus précise et/ou moins saturer le MCU
J'ai juste changé LoopsPerMilli de 345 à 480, certainement à cause (ou grâce) aux améliorations de compilateur.

ça me semble finalement être la bonne base pour continuer les développements: un code basé sur le RFLink d'origine, simplifié et optimisé permettant de reprendre les plugins.
C'est quoi la prochaine étape? Ajouter la partie WiFi/MQTT. Je vois qu'elle n'y est pas encore.

Ensuite tester les plugins? Pour cela j'avais écrit un petit sketch permettant de "rejouer" les séquences obtenues en mode debug
20;3F;DEBUG;Pulses=74;Pulses(uSec)=525,1725,425,3600,425,1725,425,3600,42....

Comme Stunteam a eu la gentillesse d'inclure ces séquences en commentaire du code de chaque plugin, on peut simuler n'importe quel matériel avec un arduino et un émetteur 433MHz.

Oui, faire une version Wifi + MQTT ....simple.
Par ma part, j'avais repris des librairies perso que je traine depuis qq temps, mais c'est une grosse usine à gaz

Tu peux partir de l'exemple suivant fait par un Suisse célèbre:

Il s'agit d'une passerelle RFLink (série) vers MQTT (WiFi), donc à peu près tout ce qu'on veut.

Je me proposerais bien de faire l'exercice mais j'avoue que je ne connais pas le côté collaboration multi contributeurs de github. Je prends donc tous les conseils!

C'est un très bon exemple qui marche (je m'en suis servi pour l'ESP01S accolé à la version Uno).
Ce code convertit un message Serial en MQTT, c'est une très bonne base de départ!

Je manque un peu de temps en ce moment, n’hésitez pas à broder :wink:

Voilà, j'ai ajouté la fonction MQTT à partir de l'exemple ci-dessus

Il faudra voir ce qu'il faut publier comme donnée. Pour l'instant c'est le buffer série brut.

etimou:
Voilà, j'ai ajouté la fonction MQTT à partir de l'exemple ci-dessus

https://github.com/etimou/RFLink/tree/esp

Il faudra voir ce qu'il faut publier comme donnée. Pour l'instant c'est le buffer série brut.

Lien cassé ?!

Et un morceau représentatif de code plugins (partie OutPut de Kaku dans ce cas).
Tout ce code génère une seule ligne RFLink, mais fait une dizaine d'appel Serial.print pour cela.

//==================================================================================
      // Output
      // ----------------------------------
      sprintf(pbuffer, "20;%02X;", PKSequenceNumber++);    // Node and packet number 
      Serial.print( pbuffer );
      // ----------------------------------
      Serial.print(F("NewKaku;"));                         // Label
      sprintf(pbuffer, "ID=%08lx;",((bitstream) >> 6) );   // ID   
      Serial.print( pbuffer );
      sprintf(pbuffer, "SWITCH=%x;", ((bitstream)&0x0f)+1 );
      Serial.print( pbuffer );
      Serial.print(F("CMD="));                    
      int command = (bitstream >> 4) & 0x03;
      if (command > 1) command ++;
      if (i>140 && dimbitpresent==1) {                     // Command and Dim part
          sprintf(pbuffer, "SET_LEVEL=%d;", dim );     
          Serial.print( pbuffer );
      } else {
          if ( command == 0 ) Serial.print(F("OFF;"));
          if ( command == 1 ) Serial.print(F("ON;"));
          if ( command == 3 ) Serial.print(F("ALLOFF;"));
          if ( command == 4 ) Serial.print(F("ALLON;"));  
      }
      Serial.println();
      // ----------------------------------
      RawSignal.Repeats=true;                              // suppress repeats of the same RF packet         
      RawSignal.Number=0;
      return true;