Oui. bien qu’il faudrait que je refasse des tests car à relire mes captures de packets, ça semble répondre à chaque fois. Ou alors, c’est que au niveau de l’ESP que je loupe la réponse que je me fais passé pour le satellite 
D’accord je vois, moi jusque ici je n’ai pas constaté de non-réponse de la chaudière sur le satellite, mais l’inverse oui 
Idem, jusque là je recevais en général une réponse de la chaudière aux sollicitations du satellite (pas de la sonde) avec les trames 0x01 pour les questions, et 0x81 pour les réponses au 4e octet.
Depuis que j’ai essayé de forcer une trame simulant le satellite, j’ai de nombreuses trames satellite en CRC Error. et d’autres comportements bizarres.
La mise à jour OTA a fonctionné avec le setimeout à 25000. En revanche, cela ne permet pas de monitorer à distance. Du coup ça perd bcp d’intérêt pour moi qui loggue tous les échanges en mode debug.
@freedom tu parles d’une autre structure de code. Aurais-tu restructuré en déclarant des objets ?
Je pense qu’en voulant forcer, tu fausses le requestID tournant et ça doit poser problème.
Ça me parait compliquer de vouloir conserver le satellite version matériel et de vouloir le simuler malheureusement. Par contre le remplacer complètement par l’ESP, oui , ça c’est possible.
Oui mon code est effectivement en objet.
Et voici pour le dépôt.
Soyez indulgent, c’est mon premier public.
Pour le satellite comme je l’ai dit, je ne l’ai absolument pas gérer étant donné que je ne le contrôle pas. Mais il est très simple d’ajouter un Device Satellite pour lire les trames qui circulent.
Haaa, ça ressemble plus à du développement objet déjà 
. Cette structure est déjà plus facile à adapter à divers cas de figure. Forcément, ton implémentation est conçue pour une liaison Connect, ce qui la rend incompatible avec les échanges historiques. Je vous propose de la récupérer et essayer de l’adapter pour une configuration sans Connect comme la mienne et celle de @Spanky.
Je crois avoir vu que tu avais prévu la récupération de date/heure depuis le connect. Le code doit pouvoir repris pour récupérer l’heure dans des trames de communication historiques.
En relisant le code j’ai buté sur un point (j’ai programmé en cpp, mais c’était il y a plus de 20 ans): comment la configuration mqtt est-elle récupérée ? Je vois une mention à un objet cfg sans trouver comment il est initialisé.
Ok j’ai compris. Tu prévois la saisie de la config MQTT via le serveur web, puis tu la sauvegardes dans le NVS pour l’avoir sous la main après reboot de l’ESP 
Effectivement j’ai prévu ce code pour du Connect, mais comme je te l’ai dit , il est très facile d’ajouter un Device Satellite pour en faire ce que tu veux sans Connect, suffit de mettre une constante USE_CONNECT pour désactiver le système de Connect ^^ . Je vais essayé de préparé un petit truc ce matin pour vous aider.
EDIT : J’ai envoyé une première partie (dans la branche develop), un squelette de départ pour son utilisation. J’essayerai d’en pousser de temps en temps. D’ailleurs je me rend compte que je n’ai même pas coder l’association via MQTT , mes appareils sont associés depuis le 1er jour alors j’y pensais même plus.
Oui il manque de petites choses à droite à gauche, mais normal pour du work in progress. C’est déjà du beau boulot. Et nous avons déjà tellement de bouts de code à droite à gauche dans les historiques de discussions que c’est plus simple que de partir d’une feuille blanche.
Accessoirement, je pense pouvoir dire que la plupart d’entre nous ne savons pas développer ainsi 
Merci 
!
Je suis développeur de métier, ca aide un peu
Une réflexion me venait à l’esprit en pensant à nos différences de fonctionnement. Nous pourrions imaginer de conditionner l’envoi des configs HA selon les informations dont dispose l’ESP.
Exemple pour le choix d’afficher les températures CDC et autres : Publier les configurations uniquement à réception d’une trame avec un correspondant 0x7E.
Exemple pour le choix d’afficher une zone 2 ou zone 3 : publier les configurations correspondantes uniquement à réception d’une trame avec un correspondant 0x09 et 0xA0.
@freedom Déjà dans un premier temps, je crois que je vais regarder comment intégrer dans ton code la récupéreration de la température extérieure depuis MQTT.
Pour la température extérieure, je t’ai fait un push sur le commit.
Tu envois la température extérieure via “homeassistant/sensor/frisquet/tempExterieure/set”
La configuration automatique, tu veux dire pour le MQTT ? Oui le module là est clairement à améliorer, il est très fouillis. Dès que j’aurais résolu le soucis du boost qui veux pas rester actif je m’en occuperai !
quand tu dis que le boost qui refuse de rester actif, tu veux dire que quand tu l’actives dans HA, il revient désactivé au bout de qq secondes ?Si c’est le cas, j’ai galéré aussi plusieurs fois avec ce comportement. J’ai l’impression que HA a besoin qu’un tiers lui renvoie le statut actif pour confirmer la prise en compte (comme l’ESP qui renverrait un topic “state” à “on”.
Je vais regarder ton push quand j’aurai un peu de temps.
C’est bon j’ai corrigé, c’était ma faute. Calcul de date pourri ;p .
Je pense que le boost est géré sur la box Connect à la base (donc pas visible sur les satellites). Mais malgré tout, il y a un flag dans les modes visible sur les trames de consignes. J’utilise ce flag mais je gère le timing de boost sur mon ESP. Et c’est évidemment transposable sur une config non-Connect.
Cool, le travail est bien mâché pour l’utilisation sans Connect. Mais il n’est pas utilisable en l’état car les codes de modes sont différents en ancien mode avec satellite, et avec Connect. A l’ancienne, les codes sont ainsi :
| Code radio | Mode |
|---|---|
| 0x00 | Nuit ? |
| 0x01 | Dérogation Jour |
| 0x02 | Dérogation Nuit |
| 0x04 | Auto Nuit |
| 0x05 | Auto Jour |
| 0x10 | Hors Gel |
Alors que je crois que le Connect a des codes de 6 à 9 pour les mêmes statuts…ou presque.
Hum, je pense que rien n’empêche d’avoir deux modes avec le meme numero dans la structure enum Mode_zone. Vu que le traitement sera en dehors. Ou alors il faut une classe ZoneV1 et ZoneV2
Je veux bien que tu me donnes quelques exemples de trames pour que je les analyses et que je captes la différences de mode avec Connect. Je peux essayé ensuite d’adapter quelque chose
En fait j’utilise beaucoup un fichier Excel de @aymeric_pournain pour analyser mes trames et les comparer : Tram_Visio avant 2015_Chaud+2Sat+ModuleHydrau.xlsx - Google Sheets
Il a mis des exemples de changement dans le 5e onglet en plus du premier onglet d’interprétation.
En complément pour le jour où nous nous demanderons quoi faire de plus, j’ai remarqué comme d’autres que le 6e octet est parfois à 0x43 au lieu de 0x17, quand il y a des évènements comme les piles du satellite à plat. D’autres ont reporté voir des trames avec cet octet à 43 une fois par nuit, mais je pense que c’était le fait des dysfonctionnements consécutifs aux premiers tests dans le thread original de discussion.
Effectivement j’ai une chaudière de 2014 mais compatible Connect, mais je vais essayer de voir des similitudes pour pouvoir aider.
Oui il parait que chaque nuit une trame est envoyé, il faudrait que je regarde, vers 4h du matin à priori.
En fait, j’ai eu du mal à trouver comment étaient lu les trames parce je n’avais pas remarqué le zone.h dans le sous-répertoire types 
Donc si je comprends bien ton code, la lecture des trames radio vers les objets “device” se fait via le struct ZONE_TRAME. Autrement dit pour lire par exemple une trame [49] venant de la chaudière vers le satellite, il faut adapter quelque chose cette liste des modes possibles :
enum MODE_ZONE : uint8_t {
INCONNU = 0x00,
CONFORT = 0x01,
REDUIT = 0X02,
AUTO = 0X04,
AUTO = 0x05,
CONFORT = 0x06,
REDUIT = 0X07,
HORS_GEL = 0x08,
HORS_GEL = 0x10
};
et ce struct pour le format de trames [49] venant de 0x80 vers 0x0n (selon la zone):
struct ZONE_TRAME {
byte idZone = 0x00;
byte code = 0x17; // Lecture + écriture
[...]
ou les trames [23] venant du 0x0n vers 0x80 pour remplacer un satellite.
Je manque de temps ce weekend pour tester une adaptation, mais je crois que j’ai saisi la logique.