Si tu fais ton propre fork, il faut faire un fork des 2 projets :
Je viens de voir que moi aussi j’ai l’erreur 503. Pourtant ca fonctionne très bien depuis l’appli Android…
J’ai peur qu’il y ait fait une mise à jour de l’API très récemment et que ca ne fonctionne plus.
EDIT :
En utilisant la commande curl pour récupérer un token j’ai une erreur.
curl --location ‹ ``https://aldesiotsuite-aldeswebapi.azurewebsites.net/oauth2/token`` ›
–header ‹ Content-Type: application/x-www-form-urlencoded ›
–data-urlencode ‹ grant_type=password ›
–data-urlencode ‹ username=*************** ›
–data-urlencode ‹ password=*************** ›
{« code »:« 503 »,« message »:« The SSL connection could not be established, see inner exception. »}#
Ah, je comprends pourquoi tu as revu son add-on du coup 
.
Étonnant que nous avons la même architecture et que ça plante dès le démarrage avec ta version lol.
Je suis pas assez à l’aise avec ce genre de montage 
Et ça fait que nous sommes dans l’impasse totale avec cet add-on malheureusement. Le sniffer de @yanoooou fonctionne bien mais pour l’instant, il n’affiche qu’une trame et écrase la précédente. Voici une capture d’écran de l’interface pour te donner une idée :
Il a prévu de modifier pour faire un historique et pouvoir extraire les logs afin de les exploiter :
Bon en fait, pas de changement pour l’API. C’est la génération de token qui est en panne. Si j’essai de me logguer sur ma tablete android qui n’avait pas encore l’appli, impossible. J’en déduis que le token sur mon portable est stocké et qu’il n’en demande pas un autre. Ca devrait donc refonctionner dans les prochains jours.
Hello,
Voici avec un peu de retard la nouvelle version du iBUS Aldes Sniffer avec l’ajout d’un historique (20 trames par défaut).
Salut !
Top tout ça, je vais mettre tout ça à jour dès demain et je te donnerai du neuf.
Pour l’update, il faut effectuer une procédure comme si le pico était vide je suppose ?
Merci pour le taf 
Pour la mise à jour il faut juste changer le code "main.py” dans ton pico avec Thonny ou un autre ide.
Ok, je ferais l’update demain matin avec Thonny IDE, je ne vais pas monter au grenier ce soir. Ca me permettra, je l’espère, de collecter des trames et de les déposer ici pour vous les partager voir si ça peut être exploitable 
Salut @yanoooou ,
Mise à jour du main.py effectué sans soucis (ou presque, je me suis fait avoir avec le WiFi )
J’ai une multitude de trames qui remontent, sûrement des infos capteurs ect, plusieurs par minute. Je vais en recolter sur 5 minutes et les déposer ici
Après amélioration du programme de sniff du bus série Aldes, il apparaît clairement que le changement de mode (boost ↔ normal) ne repose pas sur une trame isolée, mais sur une séquence complète de trames échangées.
Avant, en ne voyant qu’une partie des échanges, on pouvait croire que la trame contenant 4A suffisait. En réalité, envoyer uniquement cette trame n’a aucun effet. (après plusieurs essais)
Séquence observée : passage en mode BOOST → NORMAL :
00 90 01 4A CB
23 5F 22 F4 01 17
00 00 00 5C 24 64
01 00 01 90 01 43
87 00 1B 4B 03
Points importants :
4A correspond bien à une commande de changement de modeCB est associé au mode normal4B 03 correspond à la publication / confirmation d’état00 90 01 4A CB seul ne provoque aucun changementAutre séquence observée (extrait précédent)
01 4A B2
22 0E 02 17 00 90
00 5B 24 63 23 5F
01 90 01 43 00 00
00 1B 4B 03 01 00
Même constat :
4A n’est qu’un élément déclencheurCe point explique pourquoi certaines tentatives de reproduction échouent malgré une trame apparemment correcte.
C’est un condensé fait avec chatgpt de mes observations faites suite aux essais fait ce matin, après mise à jour. Sans cette dernière, je pense, qu’il aurait été impossible de savoir que c’est une séquence de trames qui est envoyée et non un trame isolée. À présent, il faudrait pouvoir envoyer également des séquences et non des trames isolées.
En revanche, les deux séquences que j’ai partagé juste au-dessus, sont différentes et pourtant issue de la même commande (BOOST → NORMAL). Alors pourquoi ne sont-elles pas identiques ?
Peut-être car elle prends différentes capteurs en compte à l’instant T de la commande, exemple :
@yanoooou qu’en penses-tu ? Je peux faire des essais en live si tu veux une fois pour confirmer cette hypothèse.
@Quentin57520 Peux tu publier un historique de 20 trames sans envoyer de commande? Et la même chose sans brancher la passerelle ( juste le sniffer connecté à la vmc)?
Autre possibilité, il y a un code chainé pour synchroniser le maître et les esclaves.
Ou autre possibilité, il y a un identifiant de qui émet la trame. Ça semble le cas dans le protocole ebus.
Voici un échantillon de trame sans rien toucher avec ALDES BOX connectée :
| # | Date/Heure | Trame | Taille | Type |
|---|---|---|---|---|
| 175 | 05/01/2026 10:22:00.967 | FF FF 4A 94 | 4B | RX |
| 174 | 05/01/2026 10:22:00.906 | 43 FF 00 00 FF FF | 6B | RX |
| 173 | 05/01/2026 10:21:59.845 | 11 4B 02 02 00 00 | 6B | RX |
| 172 | 05/01/2026 10:21:59.785 | FD 87 | 2B | RX |
| 171 | 05/01/2026 10:21:50.888 | 4A 94 | 2B | RX |
| 170 | 05/01/2026 10:21:49.827 | 00 00 FF FF FF FF | 6B | RX |
| 169 | 05/01/2026 10:21:49.766 | 02 02 00 00 43 FF | 6B | RX |
| 168 | 05/01/2026 10:21:49.705 | FD 87 11 4B | 4B | RX |
| 167 | 05/01/2026 10:21:39.755 | FF FF FF 4A 94 | 5B | RX |
| 166 | 05/01/2026 10:21:39.695 | 00 00 43 FF 00 00 FF | 7B | RX |
| 165 | 05/01/2026 10:21:39.625 | FD 87 11 4B 02 02 | 6B | RX |
| 164 | 05/01/2026 10:21:29.676 | FF 4A 94 | 3B | RX |
| 163 | 05/01/2026 10:21:29.616 | FF 00 00 FF FF FF | 6B | RX |
| 162 | 05/01/2026 10:21:29.555 | 4B 02 02 00 00 43 | 6B | RX |
| 161 | 05/01/2026 10:21:29.495 | FD 87 11 | 3B | RX |
| 160 | 05/01/2026 10:21:19.545 | FF FF FF FF 4A 94 | 6B | RX |
| 159 | 05/01/2026 10:21:19.484 | 00 00 43 FF 00 00 | 6B | RX |
| 158 | 05/01/2026 10:21:19.424 | FD 87 11 4B 02 02 | 6B | RX |
| 157 | 05/01/2026 10:21:09.487 | 4A 94 | 2B | RX |
| 156 | 05/01/2026 10:21:09.426 | 00 00 FF FF FF FF | 6B | RX |
| 155 | 05/01/2026 10:21:09.365 | 02 02 00 00 43 FF | 6B | RX |
| 154 | 05/01/2026 10:21:09.304 | FD 87 11 4B | 4B | RX |
| 153 | 05/01/2026 10:20:59.356 | FF FF FF 4A 94 | 5B | RX |
| 152 | 05/01/2026 10:20:59.295 | 00 43 FF 00 00 FF | 6B | RX |
| 151 | 05/01/2026 10:20:59.234 | 87 11 4B 02 02 00 | 6B | RX |
| 150 | 05/01/2026 10:20:59.175 | FD | 1B | RX |
| 149 | 05/01/2026 10:20:49.275 | FF 4A 94 | 3B | RX |
| 148 | 05/01/2026 10:20:49.214 | 43 FF 00 00 FF FF FF | 7B | RX |
| 147 | 05/01/2026 10:20:49.146 | 11 4B 02 02 00 00 | 6B | RX |
| 146 | 05/01/2026 10:20:49.086 | FD 87 | 2B | RX |
| 145 | 05/01/2026 10:20:39.144 | 00 FF FF FF FF 4A 94 | 7B | RX |
| 144 | 05/01/2026 10:20:39.076 | 02 00 00 43 FF 00 | 6B | RX |
| 143 | 05/01/2026 10:20:39.015 | FD 87 11 4B 02 | 5B | RX |
| 142 | 05/01/2026 10:20:29.064 | FF FF 4A 94 | 4B | RX |
| 141 | 05/01/2026 10:20:29.004 | 43 FF 00 00 FF FF | 6B | RX |
| 140 | 05/01/2026 10:20:29.944 | 11 4B 02 02 00 00 | 6B | RX |
| 139 | 05/01/2026 10:20:29.884 | FD 87 | 2B | RX |
| 138 | 05/01/2026 10:20:19.395 | 01 17 00 90 01 4A 07 | 7B | RX |
| 137 | 05/01/2026 10:20:19.327 | 21 63 20 5D 20 C7 | 6B | RX |
| 136 | 05/01/2026 10:20:19.266 | 01 43 00 00 00 58 | 6B | RX |
| 135 | 05/01/2026 10:20:19.205 | 4B 03 01 00 01 90 | 6B | RX |
| 134 | 05/01/2026 10:20:19.142 | 87 00 1B | 3B | RX |
| 133 | 05/01/2026 10:20:19.983 | 4A 94 | 2B | RX |
| 132 | 05/01/2026 10:20:19.923 | 00 00 FF FF FF FF | 6B | RX |
| 131 | 05/01/2026 10:20:18.863 | 02 02 00 00 43 FF | 6B | RX |
| 130 | 05/01/2026 10:20:18.803 | FD 87 11 4B | 4B | RX |
| 129 | 05/01/2026 10:20:09.311 | 90 01 4A 07 | 4B | RX |
| 128 | 05/01/2026 10:20:09.251 | 5D 20 C7 01 17 00 | 6B | RX |
| 127 | 05/01/2026 10:20:09.191 | 00 00 58 21 63 20 | 6B | RX |
| 126 | 05/01/2026 10:20:09.131 | 00 01 90 01 43 00 | 6B | RX |
| 125 | 05/01/2026 10:20:09.070 | 87 00 1B 4B 03 01 | 6B | RX |
Voici un échantillon de trame sans rien toucher avec ALDES BOX déconnectée :
Bah rien, sans AldesBox de connecté, aucune trame ne circule…
J’ai ajouté des colonnes à ton snifer (numéro pour aider le suivi en cas de refresh), étendu juste la plage à 200 et ajouté si la la trame est rx et ou tx, pour faciliter la compréhension pour moi 
OK donc c’est bien la box qui fait des requêtes à la vmc (différent du chauffe-eau T.Flow qui lui envoi des trames toutes les 10 secondes), sinon la colonne RX/TX n’est pas trop représentative car on ne sait pas si ce sont des trames qui viennent de la vmc ou qui viennent de la box…
Oui c’est la AldesBox qui interroge la VMC et comme tu peux le voir, il y a pas mal d’échanges.
Oui pour la colonne RX c’est une bonne remarque, je l’ai mise au cas où c’est moi qui envoie des trames et que ca fonctionne mais je n’ai pas pensé à ce point là. D’ailleurs c’est difficile à identifier lol.
Peux tu essayer d’envoyer la trame : FD 87 11 4B ?
Ok trame envoyée, mais il ne sait rien passé. Tu visais quelle action ?
cette trame : 4A 94 00 00 FF FF FF FF 02 02 00 00 43 FF FD 87 11 4B est visiblement envoyée ou reçue toutes les 10 secondes
Oui il y une redondance, tu veux que je tente cette envoie ?
Pour rappel, il n’y aucune action de mon côté dans cet extrait
oui tu peux essayer de l’envoyer ca ne coute rien .
Un autre test : peux tu enregistrer toutes les trames depuis un reboot de la box? On pourrait peux être voir ce qu’elle envoie au début de la connexion?