Go Down

Topic: RFLink open source (Read 1 time) previous topic - next topic

mrives

#45
Sep 20, 2019, 08:42 pm Last Edit: Sep 20, 2019, 08:53 pm by mrives
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.


Code: [Select]

//==================================================================================
      // 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;

etimou

lien corrigé
https://github.com/etimou/RFLink/tree/esp

J'ai évité de toucher à tous les plugins pour l'instant, j'ai fait une fonction publishMsg() qui publie pbuffer quand un plugin connu a été détecté.

Il faudra soit faire en sorte que pbuffer (ou une autre chaine de caractères) soit correctement rempli avec ce qu'on veut publier, ou alors appeler une fonction de publish dans le plugin...

Mais bon, ça montre que ça marche :-)

mrives

J'ai mis à jour ma version en me basant sur les rajouts d'Etimou.
Il y a quelques variantes sur la connexion Wifi (plus de paramètres et IP Statique).

On gère l'envoi de messages via la chaine MQTTBuffer ...
... Et les protocoles 4, 43 et 46 (resp. Kaku, LascrosseV1 et Xiron) sont adaptés ;)

Voilà ;)

https://github.com/couin3/RFLink.git

mrives

J'ajoute que j'ai dans la foulée modifié le RFLink-MQTT-Gateway du mec avec un accent Suisse.
Ce sont les mêmes modifications que pour le rajout de MQTT au RFLink (esp).

Petite remarque, avec dans les deux cas un récepteur [RXB6] alimenté en continu, en 5V :
- Mon couple RFLink (uno) [Arduino Nano] + MQTT Gateway [ESP-01S] consomme au total 40mA (de rares pics à 50~60mA);
- Mon RFLink (esp) [ESP-01S] consomme 80mA.


https://github.com/couin3/RFLink-MQTT-Gateway.git

al1fch

#49
Sep 26, 2019, 09:16 am Last Edit: Sep 26, 2019, 09:22 am by al1fch
Bonjour

Quote
Mon RFLink (esp) [ESP-01S] consomme 80mA.
quand l'ESP8266 est en 'modem-sleep' ?  (je n'utilise  que le deep-sleep et n'ai donc jamais fait le test des autres modes ,'modem' et 'light') ,  mais je vois que les valeurs de courant annoncées par Espressif pour le modem-sleep sont inférieures à 20mA
https://www.espressif.com/sites/default/files/9b-esp8266-low_power_solutions_en_0.pdf


mrives

#50
Sep 26, 2019, 11:06 am Last Edit: Sep 26, 2019, 11:56 am by mrives
Bonjour
quand l'ESP8266 est en 'modem-sleep' ?  (je n'utilise  que le deep-sleep et n'ai donc jamais fait le test des autres modes ,'modem' et 'light') ,  mais je vois que les valeurs de courant annoncées par Espressif pour le modem-sleep sont inférieures à 20mA
https://www.espressif.com/sites/default/files/9b-esp8266-low_power_solutions_en_0.pdf

Oui, justement!
Avec "WiFi.setSleepMode(WIFI_MODEM_SLEEP)", mon ESP-01S consomme autour de 18mA seul, quand il n'est pas ou peu sollicité.

Mais quand l'ESP effectue la boucle d'écoute RF, il reste en mode actif et consomme 70mA (80mA-10mA pour le RXB6). Sous-traiter cette tache à un ATMega (le Nano) apparaît plus efficient.

Enfin, c'est la conclusion à laquelle j'aboutis pour le moment...


Je tâtonne beaucoup sur les modes WIFI_MODEM_SLEEP et WIFI_LIGHT_SLEEP, en jouant avec les commandes yield(), delay(0) et delay(1) pour laisser respirer le process en arrière plan.

Bref, toute aide est la bienvenue!

mrives

#51
Sep 26, 2019, 02:26 pm Last Edit: Sep 26, 2019, 02:28 pm by mrives
Voilà, le MODEM_SLEEP est ajouté au RfLink (esp)... avec quelques remaques.

En effet, on ne peut pas rajouter de delay(1) dans la partie FetchSignal().
Mais on peut en mettre un dans le cran au dessus, ScanEvent().

Il reste à jouer avec la valeur de SIGNAL_SEEK_TIMEOUT_MS :
- Plus c'est court, plus on réduira la consommation;
- Mais plus c'est court, plus on risque de rater des débuts de messages!

Bref j'arrive à un compromis qui me fait passer de 70mA à 45mA.


https://github.com/couin3/RFLink.git

al1fch

#52
Sep 26, 2019, 02:38 pm Last Edit: Sep 26, 2019, 02:52 pm by al1fch
45mA cça devient concurrentiel avec l'option ESP+ATMega !

En fait on trouve peu de retours sur l'utilisation des modes sleep autres que  le deep-sleep

Je suppose qu'en sortie du RXB6 il y trop  a peu de 'temps calmes' pour que ça vaille le coup de mettre l'ESP en deep-sleep et le réveiller par une implusion externe sur RST (arrivée d'un préambule)

L'ESP32 semble un peu plus souple et apporte en complément des deux coeurs un processeur "ultra basse consommation" qui peut faire pas mal de choses .....à condition de le programmer en assembleur si j'ai bien compris.

Artouste

45mA cça devient concurrentiel avec l'option ESP+ATMega !

En fait on trouve peu de retours sur l'utilisation des modes sleep autres que  le deep-sleep

Je suppose qu'en sortie du RXB6 il y trop  a peu de 'temps calmes' pour que ça vaille le coup de mettre l'ESP en deep-sleep et le réveiller par une implusion externe sur RST (arrivée d'un préambule)

L'ESP32 semble un peu plus souple et apporte en complément des deux coeurs un processeur "ultra basse consommation" qui peut faire pas mal de choses .....à condition de le programmer en assembleur si j'ai bien compris.
bonjour
Je dirais que dans la vie réelle  la sortie data d'un RXB6 (hors conditions de labo :  chambre de test anécho ou autres)
n'est jamais...  calme trés longtemps  :smiley-mr-green:




mrives

#54
Sep 26, 2019, 03:48 pm Last Edit: Sep 26, 2019, 03:55 pm by mrives
Je suppose qu'en sortie du RXB6 il y a trop peu de 'temps calmes'
Je confirme, ça crépite pas mal ;)
D'autant plus que le RXB6 est proche ... de l'ESP (ou du Nano).
On peut utiliser ça : attiny-pre-filter

[...] ça vaille le coup de mettre l'ESP en deep-sleep
L'ennui du deepSleep (en tout cas pour l'ESP8266), c'est que cela équivaut à un reset.
Et se reconnecter au WiFi, cela prend 3 à 4s...

L'ESP32 [et son] processeur "ultra basse consommation" qui peut faire pas mal de choses .....à condition de le programmer en assembleur si j'ai bien compris.
Assembleur avec quelques macros toutes prêtes pour aider ... Je passe ;)


On peut aussi brancher la version Uno directement (avec un adaptateur de tension logique) sur le Raspberry Pi ...

al1fch

#55
Sep 26, 2019, 04:07 pm Last Edit: Sep 26, 2019, 04:44 pm by al1fch
Quote
L'ennui du deepSleep (en tout cas pour l'ESP8266), c'est que cela équivaut à un reset.
Et se reconnecter au WiFi, cela prend 3 à 4s...
ce n'est pas un ennui pour toutes les applications vu la possibilité  de conservation de données en 'rtcRAM '. Pour RFlink effectivement ça peut ne pas convenir.

De plus 3 à 4s secondes de reconnection n'est pas une fatalité

J'arrive, (pour les sondes situées  à moins de 10m de la box) , après qq bidouilles, à 0,8s en moyenne pour :  Réveil + mesure de t° DS18B20 en mode 10 bits + connection Freebox +envoi de qq octets vers ThingSpeak (get ou mqtt)

Je  supervise sur ThingSpeak la 'durée totale de session' de chacun  de mes thermomètres
(valeur de millis juste avant la mise en sommeil , sauvegardée en ramRTC  et publiée au réveil suivant)


D'ailleurs vu le service rendu par ces petits thermomètres WiFi (D1 Mini modifées,  alimentées en 3,2V LiFePo4) les qq sondes 433MHz antérieures sont dans mon cas particulier et pour l'instant à la retraite
Qui sait elles  vont peut être reprendre du service avec RFLink !!

Mais il est clair que cette petite seconde de reconnection+envoi de données  peut être excessive dans certains  cas et amener à renoncer au deep-sleep.

mrives

#56
Sep 26, 2019, 06:50 pm Last Edit: Sep 26, 2019, 06:51 pm by mrives
Je suis le chemin inverse en passant de D1 mini modifiés  à des sondes 433 low cost (protocole Xiron)!
J'utilisais aussi la RTC RAM de l'ESP.
Pourrais-je lire ton code pour voir si je peux gagner qq secondes à la connexion Wi-Fi ?
Je suis en IP statique, je ne vois pas trop quoi améliorer.
Je soupçonne que c'est mon routeur qui traine...

mrives

D'autre part, il m'arrive d'appuyer consécutivement sur deux interrupteurs radio jumelés. Je ne peux pas rater le second message !

al1fch

#58
Sep 26, 2019, 07:01 pm Last Edit: Sep 26, 2019, 09:32 pm by al1fch
Quote
Pourrais-je lire ton code pour voir si je peux gagner qq secondes à la connexion Wi-Fi ?
Ci joint un des codes en service. La box est une Freebox V6

Mon choix ESP résulte sans doute du fait que je n'ai pas  de domotique en service, juste des capteurs de T° et %H, j'ai  préféré faire homogène en WiFi ..... sauf que 2 jolis capteurs Xiaomi BLE se sont invités  ainsi que deux capteurs  en LoRa  plus récement (200 à 300m en zone urbaine dense "bétonnée"pour ces derniers... ça se complique un peu (passerelle)

Je  suis dans de la collecte de données, donc pas vraiment dans la course pour RFLInk Open Source mais suit vos avancées avec intérêt.

etimou

#59
Sep 28, 2019, 07:40 pm Last Edit: Sep 28, 2019, 07:42 pm by etimou
On peut aussi brancher la version Uno directement (avec un adaptateur de tension logique) sur le Raspberry Pi ...
Perso j'ai cette configuration.

J'ai testé la version actuelle en mode Serial et ça bogue à la réception du deuxième message...



20;00;Nodo RadioFrequencyLink - RFLink Gateway V1.1 - R99;
20;01;NewKaku;ID=00b6e3f2;SWITCH=2;CMD=OFF;
20;02;NewKaku;ID=00b6e3f2;SWITCH=3;
 ets Jan  8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v951aeffa
~ld



Go Up