J’ai l’impressions que je ne les ai qu’au démarrage. De toute manière, plus la peine de raisonner taille fixe de trame puisque maintenant on sait déconder leur taille.
PS : je viens de voir que ces trames sont envoyés par la VMC lorsque la box envoie la valeur FF sur le mode (octet 9).
C’est génial, on avance dans la bonne direction.
En me concentrant sur l’octet de consigne du mode de la VMC, je pense aussi que je viens de comprendre comment il est codé.
| Commandes | Mode | Prise de contrôle par hub ? | CRC ? | |||||
|---|---|---|---|---|---|---|---|---|
| Mode | HEX | BIN | Bits(0-2) | DEC | Bits(3) | Bits(4-7) | DEC | |
| Programming ? | 10 | 00010000 | 000 | 0 | 1 | 0000 | 0 | BITE(0-3)-1 |
| HOLLIDAY | 21 | 00100001 | 001 | 1 | 0 | 0001 | 1 | BITE(0-3)-2 |
| DAILY | 43 | 01000011 | 010 | 2 | 0 | 0011 | 3 | BITE(0-3)-3 |
| BOOST | 65 | 01100101 | 011 | 3 | 0 | 0101 | 5 | BITE(0-3)-4 |
| GUEST | 87 | 10000111 | 100 | 4 | 0 | 0111 | 7 | BITE(0-3)-5 |
| Init ? | FF | 11111111 | 111 | 7 | 1 | 1111 | 15 | ??? |
Les 3 premiers bits code la valeur du mode qu’on retrouve ensuite renvoyée par la VMC 0,1,2,3,4.
Le 4eme bit, j’ai pas encore bien compris. Ca reste à confirmer.
Les 4 derniers bits pourraient être un contrôle. La valeur des 4 premiers bits -1. Ca marche sauf pour la valeur FF qui pourrait être un cas particulier.
Ca reste à confirmer.
Autres éléments intéressants dans l’analyse des trames de 54 octets :
Salut !
Super travail !
Niveau octets identifiés, on se retrouve avec quoi d’identifier et quoi à isoler encore ?
Salut @Quentin57520
Ca dépend des trames. Actuellement, j’ai indentifié 3 types de trames :
Hub => VMC
VMC => Hub les plus fréquentes
VMC => Hub moins fréquentes
Salut,
Ok donc pour les trames VMC → AldesBox, en comparant avec l’add-on AldesMQTT, il pourrait potentiellement manquer :
Le reste je n’ai pas d’idée sur ce qu’on pourrait trouver.
Pour les trames de VMC → AldesBox de plus grandes longueurs, ca m’est arrivé d’en avoir mais uniquement au démarrage du AldesBox, autrement je ne la vois jamais, je suppose que c’est aussi ton cas ?
Oui également au démarrage uniquement. Di ça se trouve on a des info sur la conversion des températures en fonction du calibrage. Je continuerai à creuser ce weekend.
Pour les valeurs manquantes c’est bien celles la. Elles doivent être dans les octets non identifiés. On va les trouver 
Salut. Juste pour être sûr de ne pas faire le travail pour rien.
Je suis en train de modifier le code du sniffer pour intégrer la connection MQTT depuis le code du T.FLOW. J’ai besoin de plus d’historique pour déterminer les octests que ce que nous offre le serveur web.
Si tu as déjà fait, peux-tu m’envoyer ton code ?
Salut,
Je pense que tu peux laisser tomber le code du sniffer et plutôt partir avec la librairie que j’ai developpé : https://github.com/YannDoublet/Open-connect-box/tree/main/Software/Raspberry%20Pico%20W/uAldes
Merci @yanoooou je vais regarder ça.
En parallèle, je viens de trouver une nouvelle chose. Lorsque le polluant dominant est l’humidité le QAI est égal à la variation d’humidité. Octet 24
As tu réussi a envoyer des commandes à la VMC?
Je n’ai pas encore essayé. J’essai déjà de bien comprendre les données échangées.
Je viens aussi de trouver PwmQAI. Il est codé par les octets 25 (poid faible) et 26 (poid fort). Ca marche bien pour les 2 valeurs 400 et 750 que j’ai pu constater.
Pour les trames de la VMC vers le hub qui sont sur 28 octets, je pense qu’on a tout.
| Identifiant esclave | Taille de la trame | Pattern de début | Toujours à 03 ? | Toujours à 01 ? | Toujours à 00 ? | Toujours à 01 ? | PwmQAI 1 poid faible | PwmQAI 2 poid fort | Mode de la VMC | Toujours à 00 ? | Toujours à 00 ? | Toujours à 00 ? | Temperature cuisine | %humidité cuisine | Temperature sdb1 | %humidité sdb1 | Temperature sdb2 | %humidité sdb2 | CO2 poid faible | CO2 poid fort | Toujours à 17 ? | Variation humidité | PwmQAI 2 poid faible | PwmQAI 2 poid fort | Pattern de fin | Checksum | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Octets | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 |
Pour le PwmQAI, on le retrouve à 2 endroits. Mais Les valeurs ne change pas en même temps. Je ne comprends pas encore pourquoi les valeurs peuvent mettre du temps à changer. Commande et statut ?
Salut !
Je viens pas une journée et tu as beaucoup avancé avec @yanoooou ! lol
Pour en venir à ta trame de 28 octets émise par la VMC, tu as des octets qui sont toujours à 00, question bête mais as-tu checker ces octets lorsque que tu passes en mode boost automatique lorsque l’humidité augmente ou CO2 ? Rien n’indique la puissance du ventilateur en W ou le RPM pour la ventilation ? j’extrapole mais je trouve étonnant de ne pas le retrouver 
EDIT: Je viens de penser que les capteurs dans la VMC sont : CO2, H²0 et COV, or celui-ci on ne l’a pas et je pense qu’il doit encore se cacher lol.
Je viens de penser à une seconde possibilité, on peut forcer le mode boost de manière temporaire avec un BP cablé sur la VMC. Celui-ci donne peut-être une information lorsque ce mode est activé ?
Dernière chose, lorsque qu’on planifie un mode Holiday avec une plage d’absence, on peut peut-être y retrouver des informations ?
Finalement encore une chose, les octets à 00 pourrait être lié à des codes erreurs ou des évènements ?
Je fais peut-être fausse route mais je préfère exposer mes idées que de passer à côté de quelque chose 
Hello. oui c’est probable. C’est pour ça que j’essaie d’apadter le code de ualdes pour avoir de l’historique sous HA. Je fais un truc générique pour ça s’adapte au T.FLOW comme aux EASYHOME.
Dès que fonctionnera correctement je pourrai plus investiguer.
Actuellement les trames reçues font toutes 1 octet. Mais j’ai compris mon erreur. Je refais un essai demain.
Bon, je ne comprends pas pourquoi ça ne marche pas. La fonction uart.read() retourne 1 seul octet et très rarement quelques octets.
@yanoooou le fonctionnement est très différent du sniffer qui gère une mise en buffer à ce que je vois dans le code. Tu es sur que sur le GitHub c’est la dernière version ?
@Quentin57520 j’avais vu dans tes screenshots que tu envoyais les infos sur mqtt. Tu as une version du code qui fonctionne ?
Salut @Frederic_Duloum ,
Écoute oui ça fonctionnait pour ma part. Je vais regarder sur mon PC, je dois avoir encore les fichiers. Je regarde ce soir et je te fais un retour 
EDIT: Check tes MP
@Frederic_Duloum , effectivement pour le T.Flow la partie lecture est faite par un STM32 et envoie les données sur le Raspberry pico.
Pour la VMC il faudrait recoder la fonction de lecture en détectant le caractère de début, la longueur de la trame. Si je trouve un moment, je vais essayer de recoder cette partie la.
@yanoooou Je suis en train de le faire. Je voulais juste gagner du temps si c’était dû à un pb de compréhension de mon côté.
