Go Down

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

etimou

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

mrives

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!

etimou

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.

mrives

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).


https://github.com/couin3/RFLink


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 

mrives

#35
Sep 17, 2019, 02:32 pm Last Edit: Sep 17, 2019, 02:48 pm by mrives
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é.

etimou

#36
Sep 17, 2019, 05:10 pm Last Edit: Sep 17, 2019, 05:11 pm by etimou
Même expérience avec StuntTeam…

Le projet n'a pas l'air complétement arrêté.
Message datant du 9 juillet:
Quote
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...

mrives

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...

etimou

Quote
- 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?

mrives

@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.

etimou

ç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.

mrives

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

etimou

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

https://github.com/SensorsIot/RFLink-MQTT-Gateway/blob/master/RFLinkV1/RFLinkV1.ino

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!

mrives

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 ;)

etimou

#44
Sep 20, 2019, 03:48 pm Last Edit: Sep 20, 2019, 09:47 pm by 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.

Go Up