mrives:
hardware de référence ("vanilla") D1 Mini + RXB6.[/b]
Idéalement, si vous reprenez des protocoles ("plugins"), un Arduino Mega avec RFLink R29 pourrait aider!
OK, parfait !
mrives:
Ceci dit mon code ESP est normalement déjà compatible ESP32 (cf #define)... mais je n'ai (pour le moment) rien pour le tester.
J'ai également un Sonoff RF Bridge, pas encore modifié (pas le temps pour le moment).
Bref, je prends en compte les retours sur les autres hardwares, mais j'essaye de compartimenter!
Restons concentré sur le matos que tu as défini ci dessus, ne nous fermons cependant pas de portes pour des évolutions futures.
mrives:
Je vais ressortir de mon placard un srx882. jusque là, pas eu de chance avec 
Pas d'urgence, je ferai les tests pour voir comment ça se comporte d'un module à l'autre si tu veux.
mrives:
Le RFM69 est très intéressant... car utilisé dans plein de projet! J'ai donné celui de Charles Halard, mais il est partout.
Et même... J'ai un hardware target : le couple ESP32 + RFM96. Le RFM96 ajoute LoRa au RFM69. Quel intérêt? Et bien toute les cartes déjà prêtes! Cf. Andreas Spiess #182
Il est partout ce Charles Halard c'est vrai 
Je lui ai envoyé un message hier d'ailleurs à propos de son code téléinfo 
Par contre je ne suis pas sûr que l'antenne du module d'Andreas soit adaptée au 433mhz (je suppose que les antennes LORA n'ont pas les memes specs)
mrives:
Depuis hier, après un après midi de lutte... J'ai une version PlatformIO fonctionnelle.
Elle fonctionne aussi avec l'Arduino IDE.
Seul problème, elle ne fonctionne qu'avec les plugins déjà modifiés.
Oui pas simple d'avoir un truc fonctionnel avec l'intellisense au début...
Moi j'aime bien créer des environnements portables avec VScode, ça permet de faire des tests sans impacter son principal IDE quand on installe des add-ons.
mrives:
Je suis fidèle au pubSubClient, parce qu'il marche et que je commence à y être habitué.
A ce sujet, j'ai augmenté le temps de SocketTimeout et KeepAlive. Je soupçonne une zone aveugle que l'ESP se reconnecte. C'est un possible problème quand on reçoit deux messages très rapprochés après une longue inactivité (Cf. protocole Lascrosse 043 : Un msg Temp. et son jumeau Hum.)
J'utilise déjà BearSSL, je devrais pouvoir porter ça aussi (attention les clefs!).
No problemo, si je parle de choses asynchrone pour mqtt et pour FetchSignal() c'est parce que tu as évoqué des latences, et le FetchSignal() en est clairement la cause dans le code d'Etimou (même si à l'utilisation c'est sacrément réactif finalement). Ca permet aussi de garder une loop réactive si un jour on souhaite ajouter d'autres fonctionnalités (oui oui laissez moi rêver 
)
mrives:
Idéalement, est-ce que tu a un ATMega avec RFLink R29, pour savoir si ça marche avec?
Tu veux dire pour tester mon lot de télécommandes chinoises sur un RFlink R29 c'est ça ?
Je peux flasher mon ATmega avec une R29 oui... Faut juste que je trouve le binaire... A moins de le recompiler avec les sources mais bon si je peux faire simple... 
mrives:
De mon côté, je note 003 et 005 dans la liste des 1er protocoles à adapter pour avoir le message MQTT.
Un mode AP pour la configuration initiale, avec tous les paramètres WiFi/MQTT et cie.
ça marche, pour éviter tout quiproquo : pour l'instant ça ne remonte même pas sur le port COM.
Du coup d'ailleurs je suis un peu pommé : j'avais cru comprendre que ton code fonctionnait avec les plugins d'origine sans modifiation, je me plante ?
Ensuite, vu que tous les protocoles une fois décryptés envoient un message sur le port série, je suppose que l'on peut créer une fonction générique, quelque soit le protocole RFlink, qui viendra : écrire sur le port série et envoyer le message MQTT (puis un jour peut-être afficher les data sur l'éventuelle UI, voir meme exposer les datas sur un websocket...)
Sinon pour info j'ai également un oscillo sous le coude, si un jour on a envie d'essayer de comprendre pourquoi tel ou tel module RF ne renvoie rien...
