En fait on envoi la requête a la chaudière qui sert uniquement de routeur vers le satellite. Mais oui c’est pertinent d’attendre une trame satellite pour communiquer mais cela reporterai a 20min le temps de prise en compte d’un changement
je ne pige pas…Si la chaudière ne sert que de routeur vers le satellite (et donc ne prend pas directement la consigne), en quoi cela retarderait la prise en compte ?
Ou alors il faudrait envoyer le changement de mode tout de suite puis attendre le réveil du satellite pour le ré-envoyer afin qu’il le prenne en compte aussi ?
En fait, pour faire simple, tu as un associationID propre à la communication entre Chaudière + Connect, et un autre entre Satellite + Chaudière. Pour faire les choses proprement, le Connect ne peut pas utiliser son associationID directement pour parler au satellite, donc la chaudière sert de relais pour que les deux communiquent. Elle envoie la donnée sans même regarder ce qu’elle contient (j’ai déjà fait l’essai en envoyant d’autres requêtes bidons).
Et comme le satellite est à pile, il faut attendre qu’il soit en mode écoute, donc on envoi régulièrement jusqu’à ce que le satellite réponde. Cela peut prendre 2 minutes. Ensuite une fois ce changement pris en compte par le satellite, il envoi normalement (comme toutes les 10 min) sa consigne, l’ambiance et le mode, et donc c’est à ce moment là que la chaudière le prend véritablement en compte.
Mais du point de vue du Heltec, on le prend en compte dès le moment ou le satellite réceptionne la donnée. Donc environ 2min. Tu as réussi depuis à faire un changement de mode ou de température ?
Finalement, et avec ton conseil de patience, oui !
Suggestion peut-être une peu stupide: pourquoi, dès que le satellite a pris en compte la consigne, et donc avant les 10 mn, ne pas simuler un message du satellite vers la chaudière lui transmettant sans délai la (nouvelle) consigne, l’ambiance et le (nouveau) mode, a priori le heltec connaît ces infos ? Plus tard, dans les 10 mn, le satellite retransmettra ces infos (ambiance mise à jour), à moins qu’entre temps on ait modifié sur le satellite, dans tous les cas, la synchro des données sera OK..
Non, il est assez près (2 m du répéteur mesh, au même endroit, mon smartphone affiche toutes les barres de wifi). Apparemment, je n’ai cette paire de messages "Connexion au service MQTT…” et “Connection MQTT établie” que pendant les tentatives répétées d’envoi zone.
Ta réflexion n’est pas stupide, et effectivement c’est quelque chose que j’ai prévu dans la prochaine version réécrite. Je peux même faire mieux que ça, je peux écrire la consigne directement en tant que Connect, ce qui simplifie les choses. J’ai simplement voulu conserver au maximum le fonctionnement du vrai Connect (qui lui ne fait pas ça bizarrement…) .
La mise à jour des consignes depuis HA est toujours assez aléatoire : ex, je change la consigne T° Hors gel dans HA et 9 fois sur 10, 1 heure après le changement n’est pas pris en compte…
La température de consigne ne change qu’à l’envoi de l’info par le satellite, toutes les 10 minutes normalement. Il y a deux types de trame : la trame de Zone, et la trame d’infos chaudière consigne et ambiance. La deuxième est envoyé par le satellite avec un décalage. Et c’est pour ça que même si tu récupère l’infos du changement de consigne “nuit”, la consigne chaudière peu mettre un peu plus de temps à la récupérer. Par contre petit détail important : ta température réduite est plus élevé que la confort, il y a un soucis. C’est pour ça que ce n’est pas pris en compte. D’ailleurs tu ne peux pas le faire sur le satellite… Mais c’est vrai que c’est une question que me posais, est-ce que je ne devrais pas retirer cette bride…
Je suis en pleine réécriture du code, on va voir si ça aide à stabiliser certains passage de consigne.
Pas de soucis. Je signalais l’étrangeté, mais effectivement, empêcher Réduit d’être supérieure à Confort, ça ce tient !
Quand ton code sera prêt, dis moi, je re-testerai de mon coté.
Si je comprends bien il y a une grosse différence entre les échanges de type connect et ceux à l’ancienne. En mode connect, il y aurait des échanges de températures, et d’autres pour les consignes de zones ?
Sans le connect, les échanges ressemblent en gros à ça :
@Freedom Je pense que tes définition de trames reflètent assez bien les types d’échange possible avec ou sans connect. Il reste à revoir comment exploiter les données échangées dedans, selon ce qu’on veut en faire.
Je n’ai pas eu de temps pour me reposer sur ton code cette semaine. Mis à part le temps libre, ce qui me freine est la variable adoption par les membres du foyer en remplacement du satellite.
j’essaie de regarder tout çà demain en commençant par l’eumulation de la sonde.
@Freedom Pas de risque si j’emule un second Connect alors que j’ai le vrai que cela entraine des problème de reception de donnée ou de données corompues ?
Non pas de risque. Le Rolling code sert à ca. Bien vu pour le schéma @haribo77 . Je suis en train de tout récrire justement pour inclure un systeme de lecture ecriture de trame propre universel. J’avance. Honnêtement si vous êtes pas a la minute, patientez encore une petite semaine et ca devrait etre pas mal