Temp1 : 21,5 à 20:25:07
Temp2 : Pas actualisé
Temp3 : 17,7 à 20:25:07
Je vais te partager un autre échantillon de trames, temp1 vient de s’actualiser, je vais éditer.
temp1 : 21.7 à 20:35:07
Trame sniffer la plus proche : 12/01/2026 20:36:42.411;87 00 1B 4B 03 01 00 01 EE 02 65 00 00 00 5D 2A 70 5E 62 2A DC 02 17 FF EE 02 4A AA
C’est possible qu’il soit supérieur, il est en pleine montée car ma compagne est sous la douche, c’est pour ça que j’en profite pour partager car il s’actualise assez vite en ce moment.
EDIT: 23,5 à 20:45:07
Trame la plus proche : 87 00 1B 4B 03 01 00 01 EE 02 65 00 00 00 5F 2A 73 5E 64 29 DC 02 17 FF EE 02 4A A4
bathroom1 : 21.7
bathroom2 : à 20:15:07 : 18,7 et 20:40:07 : 19 donc en augmentation aussi
kitchen : pas de donnée actuelle (mais 20:25:07 : 17,7 puis 20:45:07 : 18 donc en augmentation)
J’essaye d’avoir des données factuelles, mais très difficile avec des capteurs aléatoires
Indicateur associé au polluant (pas une valeur brute)
21
0x03
Type de polluant dominant
22
0x17
État système
23
0x03
Puissance / variation liée au polluant
Valeurs observées (confirmées par tes trames)
Index 21
Signification
0x02
Humidité dominante
0x03
Monoxyde / pollution dominante
C’est cet octet 21 qui bascule quand l’UI Aldes change de polluant prioritaire.
Pourquoi on est sûr que c’est un état (et pas une mesure)
Valeurs discrètes (02, 03)
Changement instantané
Synchronisé avec :
l’UI Aldes
la puissance (index 23)
Aucune cohérence physique si interprété comme ppm ou %RH
C’est donc un flag de décision interne du firmware.
Formulation prête à transmettre (propre)
Dans les trames VMC EasyHome (28 octets), le polluant dominant est indiqué par un octet d’état situé à l’index 21 (indexation 0-based).
La valeur 0x02 correspond à une régulation basée sur l’humidité, tandis que 0x03 correspond à une régulation basée sur la pollution (monoxyde).
Ce champ est un indicateur logique et non une mesure brute.
Aussi, d’après mon message plus haut #76 (tous les modes) et #105 le mode BOOST hygro :
Salut. Désolé pour mon absence de ces derniers jours. J’ai passé un peu de temps à comprendre pourquoi ca ne fonctionne pas sur le raspberry. En fait, je créé un image mono platforme linux/AMD64.
Je me suis documenté et je viens de créer une version 0.3.0 qui je l’espère va fonctionner.
Pour le polluant dominant, j’ai déjà vu sur ma VMC 3 valeurs différents : humidité, CO2 mais aussi temperature. J’ai constaté sur l’ensemble des trames que tu nous partage que le byte 22 e eu les valeurs 01, 02 et 03. Dans le dernier exemple il passe de 03 à 02. Je me demande si ca ne pourrait pas être 00: pas de pollant, 01 : temperature, 02 : co2 et 03 : humidité.
PS : je parle de numéro de byte qui commence à 1 et toi d’index qui commence à 0. On parle donc du même octet. lol
La valeur du QAI ne dépasse pas 100. Ici on arrive à 113, donc je serai surpris que ca soit ça.
La valeur de cet octet a toujours été de 17 en hexa sur toutes les trames que tu nous as partagé, même lorsque on est en mode self_controlled, donc pas sûr que ce soit la bonne signification.
Cet octet a pris les valeurs hexa suivantes : 11, 00, 08, 05, 02, 01.
Je constate qu’on a soit 1 bit ou 2 bits à 1 au plus. Ca me semblerait plus être en rapport avec l’état du système. Je vais creuser.
Sur ton add-on, les valeurs sous MQTT Eplorer remontent tout les combien de temps ?
Depuis son installation, elles sont figées, je n’ai aucun mouvement, j’ai déjà vidé le cache et reboot HAOS mais c’est toujours pareil lol
EDIT:
Autant pour moi, les valeurs via ton add-on c’est celle-ci :
Les autres valeurs au-dessous sont celles via l’outil de @yanoooou et le fichier ualdes. Ce qui m’a induit en erreur c’est que sous l’add-on j’avais configuré le nom « Aldes » et il m’en a mis un autre, sans doute car il était déjà utilisé…
Tu peux le configurer dans le module complémentaire. Par défaut c’est 30 secondes. Je te recommande de mettre 10 secondes car ça semble être l’intervalle de com entre le hub et la Vmc mais aucune garantie que le hub envoie dans le cloud toutes les 10 secondes.
PS : j’ai reçu hier le matos pour faire le sniffer. Je m’y colle ce weekend et pourrai ensuite investiguer avec toi.
Salut. Je viens de découvrir quelque chose de très intéressant. Je ne sais pas si vous aviez l’info, mais le 3eme octet (en partant de 1) code la taille des données utiles. Il faut ajouter 1 pour l’octet de checksum. C’est vrai aussi bien pour les trames reçues que celles envoyées.
On peut donc facilement décoder les bons découpages de trames en se basant sur la valeur de cet octet.
Je constate également que juste après la longueur de la trame, on a toujours 4B. Et que devant le checksum on a toujours 4A, quelque soit la longeur de la trame. Je pense que ce sont des patterns de début et de fin.
Info très intéressante oui, donc si je comprends bien ça permet de bien positionner nos octets d’informations ?
Que ce soit trames VMC ou Aldes Box alors avec 18 ou 28 bytes ?
Par contre trames de 56 bytes c’était juste un exemple ? Je n’en ai jamais eu d’aussi longue lol
C’est cet octet 21 qui bascule quand l’UI Aldes change de polluant prioritaire.
C’est donc un flag de décision interne du firmware.
