Je me permet de relancer la machine sur ce sujet qui a déjà fait de grand pas pour les possesseurs de chaudière gaz Frisquet équipé du system Eco Radio System Visio.
Le Topic ayant était archivé par l’équipe du forum car trop de message, j’ouvre ici la suite ici afin de continuer d’échanger et de faire avancer le projet.
Résumé du premier topic et liens utiles :
Objectif :
Rendre possible de simuler une sonde extérieur pour la chaudière (avec une mesure de température provenant de HA.
Se faire passer pour un satellite (thermostat) frisquet et donner les consignes/température ambiante à la chaudière via HA
Se faire passer pour un frisquet connect (si chaudière compatible) pour piloter le chauffage (tout en gardant le(s) satellite Frisquet en fonction).
Matériels :
Le choix se tourne vers un Heltec LoRa 32 v3 trouvable assez facilement sur divers site marchant.
Merci @Spanky pour l’initiative. Je t’avoue avoir été aussi désemparé en voyant le thread précédent être fermé alors qu’il y avait une belle dynamique. Possesseur d’une chaudière Frisquet Eco Radio Visio de 2012, je crois avoir une configuration similaire à la tienne (Chaudière avec satellite mais sans connect). Ce n’est que cet été que je me suis décidé à acheter un Lora 32 v3 pour passer à la pratique. J’ai reparcouru l’historique et testé les repositories de Burn (main et dev), FabAng et le tien. A date, le main de Burn est celui qui compile et fonctionne le mieux chez moi. La branche de dev adopte des spécifiques Connect qui ne correspondent pas à ma configuration.
Sur cette première expérience concluante, je souhaite voir quels moyens pourraient être trouvés pour se substituer au satellite pour changer les consignes, par exemple.
En ce sens, je crois que @aymeric_pournain suivait une piste prometteuse.
Au plaisir de contribuer dans la limite de mon temps et mes moyens.
j’ai ressayé chacun des codes proposés dans le précédent thread pour voir les directions prises par chacun. J’ai pu constater que des parts importantes de code sont pensées pour un système Connect. J’ai donc remanié le code pour ne supporter que la sonde extérieure et le satellite Z1 en plus de la chaudière avec module Visio pré2015.
Dans l’idéal j’aimerais fusionner le fonctionnel de burn adapté à Frisquet Connect avec le mien pour proposer une solution clé en main indépendamment de la version de Visio. Mais si déjà j’arrive à piloter ma chaudière ce sera bien
Avec le code actuel, j’ai les fonctions suivantes :
Automatisme pour envoyer la température de MétéoFrance à l’ESP - opérationnel
Automatisme pour enregistrer l’historique des payloads dans un fichier - opérationnel mais activé uniquement pour besoins ponctuels.
publication MQTT des capteurs
température extérieure - opérationnel
température de consigne du satellite Z1 - opérationnel
température ambiante du satellite Z1 - opérationnel
dernier payload reçu sur le réseau radio - opérationnel
Publication MQTT des switchs
association sonde extérieure - opérationnel
réinitialisation de la mémoire nvs - pas testé
mode satellite Z1 - opérationnel vers l’ESP mais en réception
Je considère que la chaudière est la référence pour toutes les informations. La mise à jour des capteurs est donc déclenchée à réception d’un payload radio issu de la chaudière.
J’ai un bug sur le selecteur mode satelliteZ1 dans Home Assistant qui refuse de se mettre à jour à réception d’un payload MQTT. Quelqu’un aurait-il une idée ?
Actuellement, je commence à tester le pilotage de la chaudière en substituant l’ESP au satellite en me basant sur les travaux de @aymeric_pournain
@Spanky je n’ai pas pu compiler ton code qui semblait contenir une variabilisation du code du satellite dans des paquets pré-définis. As-tu été au bout de tes expérimentations ? Je suis curieux d’en apprendre le résultat .
Alors de mon côté j’ai tourné tous l’hiver dernière avec mon code. Jusque j’ai parfois des manque de réactivité après quelques jours, malgré l’envois d’une trame “satellite” toutes les 10min, au bout d’un moment la chaudière ne répond plus à chaque fois (mais les infos de temp’ sur la chaudière correspondent bien…).
Donc de temps en temps je redémarré l’ESP pour que ça repasse par l’étape de synchro.
Mais en tout cas, j’ai pas eu de souci à me substitué au satellite qui est resté sans pile dans un tiroir toute la saisons de chauffe.
Il faut que je m’y replonge, je suis pas certain que le code que j’ai mis sur git soit la dernière version que j’ai. (Edit : effectivement j’ai “SatZ1_id” dans les trames ce qui fait référence à un variable inclus dans le fichier config.h mais que je n’ai pas mis à jour sur git. tu peux simplement remplacer ça par l’ID de ton satellite ou ajouter la variable dans ton fichier de config).
Mais j’ai codé ça comme un cochon et je pense que c’est loin d’être optimisé et clé en mains c’est certain.
Dès que j’ai du temps à la maison je rouvre VS code
Bonjour tout le monde ! Content de voir que le projet n’est pas à l’abandon. Je n’ai pas chômé de mon côté.
J’ai repris tout le code de 0 en reprenant les infos d’un peu tout le monde, et j’ai tenté un système quasi clé en main.
Il me manque encore une trame pour réussir à faire ce que je veux, et on pourrait avoir un système vraiment pas mal ! Je vais mettre en ordre et partager mon code si ça intéresse des gens !
Voici un aperçu des fonctions actuelles:
Association Frisquet Connect
Association Sonde extérieure
Récupération Température extérieure (automatique si DS18B20 connecté au Heltec)
Définir température extérieure via MQTT (si pas de DS18B20)
Température de consigne actuelle Z1
Température ambiante Z1
Mode actuel (Z1, Z2)
Définir le mode (Z1, Z2)
Définir les température consigne pour chacun des modes (Z1 et Z2)
Mode Boost (ajoute + 2 à la température de consigne et force confort)
Réception payload
Reset mémoire NVS
Mode portail qui permet de configurer le WiFi et les infos MQTT .
Je pense aujourd’hui avoir pas mal décodé la plupart des trames à ma disposition, dont le satellite (je vois qu’il y a besoin là-dessus), donc n’hésitez pas à me demander je pourrais peut-être vous demander.
Si il y a des détenteurs du Frisquet Connect, je suis preneur ! J’aimerai en finir avec ce code
Hello les gens,
c’est chouette de lire vos progrès. @Freedom tu dis avoir une connect. Dans ce que j’ai lu, j’ai l’impression que la gestion pilotée par l’ESP devrait être différente avec ou sans Connect. Avec Connect, on a des données supplémentaires dans des trames de 63 octets. Sans Connect, il faut se contenter des trames à 49 octets pour la lecture des données de la chaudière, et celles à 23 octets pour la gestion des trames satellite (en lecture ou usurpation).
Je m’appuie beaucoup sur le wiki de @Burn pour interpréter les trames. Mais cette documentation aussi claire et fournie soit-elle ne me paraît pas à jour
Pour ma part, je n’ai pas de Connect, et j’essaie donc de me faire passer pour le satellite, sans succès pour le moment. La fraicheur arrivant, j’essaie de presser le pas.
J’ai perdu un peu de temps car mon association de sonde extérieure était en fait incomplète : j’avais pu récupérer le network id et l’id de sonde mais la chaudière ne l’avait pas enregistrée (oups)… Résultat je ne voyais pas une partie des trames attendues. Bref, c’est rentré dans l’ordre après une suppression de sonde puis réassociation dans le menu radio de la chaudière. Maintenant la température extérieure s’affiche bien sur la chaudière et le satellite (sans Connect).
@Spanky comme toi mon code est plutôt moche. Je cherche à l’assainir et lui faire ressembler à du code objet en m’inspirant d’autres codes. Mais la tâche est ardue car de nombreuses sources sont conçues avec gestion du connect, et en « work in progress » qui plus est.
J’ai découvert la semaine dernière sur Github un nouvel acteur qui a fait une première publication de code orienté objet, ressemblant à ce que je voudrais faire. Il y a également pas mal de bonnes idées dans le fonctionnel (gestion d’entité climat dans HA, gestion des 3 zones, publication d’énergie dans HA…). Mais là encore ce n’est pas encore opérationnel : GitHub - hpoussin/ESPsquet: Frisquet boiler integration to HomeAssistant using MQTT and ESP32 Heltec LoRa V3
J’aimerais également pouvoir mettre à jour et monitorer l’ESP en Wifi pour ne pas avoir besoin de le conserver branché au PC, mais le code OTA ne fonctionne pas chez moi. Peut-être un problème de firewall du PC. Avez-vous rencontré le problème ?
Merci pour cette information concernant le GitHub, il y a peut-être une données que je recherche (la récupération du mode et du planning en cours).
Je réécris le code complet pour être sûr d’avoir un truc propre à partager.
Je n’ai pas de Connect, c’est bien le soucis, je n’ai pas de moyen d’analyser les trames de mon côté. Je joue uniquement avec mon Heltec V3. Pour le satellite, on peut l’usurper sans soucis, mais ça me parait pas possible d’utiliser le satellite en plus du Heltec pour la température ambiante (n’hésitez pas à me corriger si je me trompe). Ou alors il faudrait capter le moment ou le satellite envoi l’information, et écrire par dessus directement en envoyant la même trame mais avec une température ambiante différente.
Pour le système OTA, j’ai réussi à le mettre en place sur mon système depuis le début. Je vous partage ça dans la semaine si j’y arrive.
Comme tu le dis, Avec une telle approche le satellite peut envoyer des commandes en parallèle de l’ESP. Mais il ne tient jamais compte de la surcharge de celui-ci. Au final, son utilité se limite à fournir la cadence des trames et la température ambiante. Ca a quand même de l’intérêt pour assurer la continuité de service en cas de défaillance de l’ESP. Le seul test que j’ai fait en ce sens pour le moment n’est pas concluant, mais ça semble normal parce que je n’ai pas calé mon envoi de surcharge juste après l’envoi d’un paquet de satellite.
Je vais m’y réattaquer maintenant que la chaudière doit chauffer la maison
Autre sujet, côté interface Home Assistant cette fois :
J’ai repris du code d’un projet récent pour tester l’interaction HA<-> ESP au travers d’un carte climat. Le résultat est encourageant.
Les topics sont majoritairement repris sur des configurations déjà déclarées dans des portions de code déjà partagées sur les autres repositories pour données les entités suivantes dans HA.
Les mises à jour d’états fonctionnent à peu près correctement. Je soupçonne d’avoir qq écarts parfois en raison du code ESP un peu fouilli.
Et @Freedom je pense avoir compris pourquoi je n’arrive pas à mettre à jour en OTA : PlatformIO demande la création d’un compte que je n’ai pas voulu faire.
C’est pas mal et plus propre que de simple champ effectivement, je voulais faire ça cette semaine, merci pour le code !
Par ailleurs, est-ce que tu as toi aussi (si tu analyses un peu les trames), l’impression que l’envoi de la consigne est la plus laborieuse ? J’ai l’impression que le satellite “ignore” dans un premier temps la requête, et qu’il faut insister sur la requête d’envoi de consigne pour que ça fonctionne.
Je m’explique : la requête de demande des infos (comme la températures ou la consommation), la réponse est directe, y a pas de raté. Idem l’envoi de la consigne de température extérieure. Par contre, l’envoi de la consigne des températures et du mode, la chaudière envoi la demande au satellite qui s’en fou royalement , il faut envoyer plusieurs fois la requête pour que la chaudière accepte de répondre.
Tout en écrivant ça je suis en train de me demander si c’est pas simplement un problème de distance radio entre le satellite et la chaudière….
Par ailleurs, est-ce que tu as toi aussi (si tu analyses un peu les trames), l’impression que l’envoi de la consigne est la plus laborieuse ?
Oui je sors toutes les trames sur la liaison série dans le monitoring de VSCode et ces derniers temps j’y ai ajouté tous les payloads MQTT pour vérifier les causes et conséquences.
Pour les trames radio, j’ai intégré un bout de code que @Burn a écrit dans sa branche dev pour investiguer le même genre de problème:
if (receivedFlag)
{
// reset flag
receivedFlag = false;
// you can read received data as an Arduino String
byte byteArr[RADIOLIB_SX126X_MAX_PACKET_LENGTH];
int state = radio.readData(byteArr, 0);
if (state == RADIOLIB_ERR_NONE)
{
// packet was successfully received
DBG_PRINTLN(F("[SX1262] Received packet!"));
// print data of the packet
DBG_PRINT(F("[SX1262] Data:\t\t"));
int len = radio.getPacketLength();
handleRadioPacket(byteArr, len);
// print RSSI (Received Signal Strength Indicator)
DBG_PRINT(F("[SX1262] RSSI:\t\t"));
DBG_PRINT(radio.getRSSI());
DBG_PRINTLN(F(" dBm"));
// print SNR (Signal-to-Noise Ratio)
DBG_PRINT(F("[SX1262] SNR:\t\t"));
DBG_PRINT(radio.getSNR());
DBG_PRINTLN(F(" dB"));
// print frequency error
DBG_PRINT(F("[SX1262] Frequency error:\t"));
DBG_PRINT(radio.getFrequencyError());
DBG_PRINTLN(F(" Hz"));
}
else if (state == RADIOLIB_ERR_CRC_MISMATCH)
{
// packet was received, but is malformed
DBG_PRINTLN(F("CRC error!"));
}
else
{
// some other error occurred
DBG_PRINT(F("failed, code "));
DBG_PRINTLN(state);
}
}
En complément des vérifications de qualité réseau, il a repris une structure de code proposée par @aymeric_pournain qui consiste a juste mettre un flag à réception d’un code radio, pour déporter le traitement de trame dans la fonction loop(). D’où la présence de la condition receivedflag dans l’extrait de code.
Et je constate aussi parfois des pertes de paquets et des CRC Errors. Mais l’ESP passe plus de temps entre mes PC, écrans et clavier que dans une zone dégagée à portée de chaudière
C’est pourquoi j’aimerais régler mon problème de connexion OTA. J’ai réussi à initier une connexion après avoir configuré un arduinoOTA.setPassword("monpassword"); dans le code plus un upload_flags = --auth=monpassword dans platformio.ini. Mais les uploads s’interrompent à 10%.
Je me demande si mon problème ne viendrait pas des partitions disponibles sur l’ESP. Mais logiquement nous avons la même, et je n’ai aucune idée de comment elle aurait pu changer. Des idées ?
Pour l’OTA, je te conseil d’ajoute cette ligne à l’initialisation :
ArduinoOTA.setTimeout(25000); // Augmenter le délai d'attente à 25 secondes
ça devrait t’aider. Si c’est pas ça, c’est qu’il y a un process bloquant dans ta loop().
Moi je traite mes frames effectivement en bloquant après envoi (donc avec receive), mais après avoir penché un peu dessus hier soir, je me dis plutôt que le problème ne vient pas de l’ESP mais plutôt du satellite lui-même.
Je m’explique. J’envoi la trame de changement de consigne, la chaudière la reçoit bien et envoi une trame démarrant par 0x08 0x80, ce qui correspond à l’identifiant du Sat. Z1. Mais sa réponse n’est pas toujours immédiate, voir très longue. Alors pour moi il y a plusieurs possibilités :
Soit le satellite est trop loin, et donc ne capte pas toujours super bien en récéption
soit le satellite fait dodo, et n’écoute que périodiquement pour économiser les piles.
Je ferais un essai ce soir en mettant le Sat à côté de la chaudière pour voir si ça change quelque chose. Sinon, c’est que c’est probablement la deuxième solution, et donc à part spammer l’envoi jusqu’à obtenir une réponse du satellite il y a pas grand chose à faire (mais au moins ce sera clair).
Je viens de comprendre l’origine du problème en te lisant! Le code de @Burn dans la branche de dev contient 25 au lieu de 25000. Effectivement la doc arduino stipule que la fonction arduinoota attend une valeur en millisecondes. vivement ce soir que je puisse retester. Ca permettra de laisser l’ESP à côté de la chaudière.
Pour ton problème de délai de prise en compte des trames, ne serait -ce pas plutôt l’ESP qui pourrait etre trop loin? En échange radio, l’appareil envoi son message sans s’assurer préalablement que le destinataire l’entend et tous les appareils autour avec le même networkid peuvent le capter. Donc si tu mets du temps à voir la trame avec ton code, c’est soit que la chaudière est partie fumer (private joke) soit que c’est l’ESP qui ne capte pas sa réponse. Le satellite me semble hors de cause sur ton cas de figure.
Détrompes-toi, la chaudière capte bien mon message puisqu’elle répond direct en envoyant une trame à 0x08 , donc le satellite, qui lui par contre ne répond pas ! Mais j’ai essayé en rapprochant le satellite ça ne semble pas améliorer l’échange. Je cherche toujours… je commence vraiment à me demander si ce n’est pas caler sur des espèces de cycles d’écoute, à des minutes précises (d’où la récupération régulière de l’heure par les différents appareils).
Je ne suis pas certain de comprendre ta description. As-tu possibilité de partager une copie des trames radio échangées entre ta chaudière, ton satellite et ton esp sur le scénario que tu décris ?
Bien sûr. Voila un exemple (à lire de bas en haut, ça vient de HA) :
A changé en 7E 80 AA 80 08 17 A1 54 00 15 A1 54 00 18 30 9B 5A 1E 06 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 20:39:51 - Maintenant A changé en 80 08 AB 80 7E 17 A1 54 00 15 A1 54 00 18 30 9B 5A 1E 06 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 20:39:50 - Maintenant A changé en 08 80 AB 80 7E 17 A1 54 00 15 A1 54 00 18 30 9B 5A 1E 06 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 20:39:49 - Il y a 2 secondes A changé en 80 7E AA 80 08 17 A1 54 00 15 A1 54 00 18 30 9B 5A 1E 06 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 20:39:48 - Il y a 3 secondes A changé en 7E 80 AA 80 08 17 A1 54 00 15 A1 54 00 18 30 9B 5A 1E 06 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 20:39:48 - Il y a 3 secondes A changé en 80 08 AB 80 7E 17 A1 54 00 15 A1 54 00 18 30 9B 5A 1E 06 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 20:39:48 - Il y a 3 secondes A changé en 08 80 AB 7C 81 17 2A 00 74 00 00 25 10 07 20 45 16 28 02 00 CF 00 CD 00 01 00 00 00 00 04 F6 00 00 00 00 00 00 00 00 04 F6 00 00 00 00 00 00 00 00 20:39:47 - Il y a 3 secondes A changé en 80 08 AB 7C 01 17 A0 29 00 15 A0 2F 00 04 08 00 CF 00 CD 00 01 00 00 20:39:47 - Il y a 4 secondes A changé en 7E 80 AA 7D 88 17 2A 9B 5A 1E 06 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 20:39:45 - Il y a 6 secondes A changé en 80 08 AB 7D FE 17 2A 9B 5A 1E 06 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 20:39:44 - Il y a 6 secondes A changé en 08 80 AB 7D 7E 17 A1 54 00 15 A1 54 00 18 30 9B 5A 1E 06 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 20:39:43 - Il y a 8 secondes A changé en 08 80 AB 7A 7E 17 A1 54 00 15 A1 54 00 18 30 9B 5A 1E 06 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 20:39:39 - Il y a 12 secondes A changé en 08 80 AB 79 7E 17 A1 54 00 15 A1 54 00 18 30 9B 5A 1E 06 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 20:39:35 - Il y a 16 secondes A changé en 08 80 AB 78 7E 17 A1 54 00 15 A1 54 00 18 30 9B 5A 1E 06 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 20:39:31 - Il y a 20 secondes A changé en 08 80 AB 77 7E 17 A1 54 00 15 A1 54 00 18 30 9B 5A 1E 06 01 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
Il manque seulement la requête d’envoi, mais tu peux deviner qu’elle est précède celle en 08 80 (qui vient de la chaudière vers satellite).
Tu vois qu’il faut plusieurs envoi avant que le satellite daigne bien répondre ( 80 08 ) et enfin la réponse à l’ESP (7E 80) .
Ce délai de réponse est complètement variable. Parfois c’est rapide comme ici, des fois ça peut prendre jusqu’à 1min . D’où mon hypothèse, le satellite n’écoute pas en continue et se met en sommeil, ce qui serait assez logique étant donné qu’il fonctionne sur pile.
Je suis embêté pour te répondre car selon tes traces, ton ESP est configuré pour se faire passer pour un relais connect (7E), ce qui expliquerait les nombreuses trames d’une taille de 63.
Ma chaudière ne supporte pas Connect, j’ai dû faire passer mon ESP pour une sonde extérieure et je regarde comment faire passer l’ESP également pour le satellite pour contrôler les consignes en tant que satellite virtuel. La nature des échanges et les formats de trame sont différents des échanges avec un module connect.
Je vois que vous êtes déjà bien plus avancé que moi ! C’est top pour la possibilité de maj OTA !
de mon côté j’ai redémarré la chaudière, ça fonctionne toujours aussi “bien”, mais il faut quand même que je reset de temps en temps l’ESP pour redémarrer le programme histoire que ça se resynchronise.
Dans le cas où l’on veux faire passer l’ESP pour le satellite :
Si aucun changement de consigne volontaire n’est fait : le satellite envoi ça trame 23toute les 10min avec les valeur courante temp ambiante, mode de chauffage etc…
0x08(satellite) to 0x80(chaudière) trame 23 > réponse de la chaudière 0x80 to 0x08 trame 49 (avec la température et consigne à jour).
Si changement de consigne, le satellite envoi sa trame 23 à laquelle la chaudière répond également par une trame 49. Cet échange ne modifie ou décale la cadence d’envoi toute les 10min. (si à T0 j’ai un trame 23 qui part, a T2 je change de consigne, la prochaine trame sera quand même a T10 et non T12) j’espère que vous me suivez
Au démarrage du satellite une trame 17 est envoyé du satellite à la chaudière qui répond par une trame 49. C’est répété 3 fois avec a chaque fois une incrémentation du numéro de message de 1 et non de 2 comme pour les trame 23.
Ensuite le satellite envoi un trame 8 à laquelle la chaudière répond une trame 6 et le satellite répond une trame 23 (je vous met l’exemple malheureusement j’avais pas le timestamp)
Ca c’est ce que j’ai interprété en jouant avec le satellite et en écoutant ce qui se trame (haha ).
Il s’avère que la chaudière ne réponde pas toujours lors d’un changement de consigne volontaire même si elle la bien prise en compte. En revanche elle répond toujours aux trames du satellite toute les 10min. C’est là que je fini par ne pas toujours avoir de réponse.
Je pense que hors action manuelle, frisquet a hard codé le fait que la sonde ext envoie ses infos a un temps bien précis, le satellite Z1 à un autre temps précis etc dans cette boucle de 10min.
toujours supposition, je pense qu’il faudrait exploiter l’heure que la chaudière fournis afin de “synchro” les échanges sonde ext et sat dessus avec un décalage.
Dans mon code c’est créer un décalage de 3min entre sonde et satellite mais ça fini peut-être par merdouiller une fois que le code a boucler pendant 4-5j.
Que veux-tu dire par la chaudière ne répond pas à la consigne volontaire ? Lorsque tu changes la valeur sur le satellite lui même ?
Complètement d’accord, c’est ma prochaine étape de synchro la date.
Je vais mettre en ligne je pense demain mon code sur Git, je n’ai absolument pas gérer la partie Satellite encore car pas spécialement l’utilité en Connect, mais ce n’est pas difficile à ajouter avec ma structure de code.
)
Remercîment @mgre , @Burn , @Gib , @FabAng , @0xd33d33, @dgeppert et tout ceux que j’oublie qui on contribué à tout ça !
.
!
, il faut envoyer plusieurs fois la requête pour que la chaudière accepte de répondre.
