OK nickel ça confirme ce qu’on pensait sur le driver à implémenter pour dialoguer avec la carte mère.
Je viens de lire que l’usb du Pico pouvait jouer le rôle de host ou device, ce qui signifie qu’on doit pouvoir le brancher aussi à la passerelle pour voir ce qu’elle envoie comme requête.
Normalement les lib modbus se débrouillent pour calculer le checksum. Je n’ai jamais eu eu de problème avec les programmes que j’ai utilisés. Tu utilises pymodbus ?
J’étais aussi tombé sur ce message en utilisant Modbus Slave, ça interroge le registre 1024.
Normalement tu devrais aussi retrouver un read holding sur 1056.
Excellente idée d’utiliser un Pico W, c’est potentiellement le hardware parfait car alimenté par l’USB, permettant le CDC/ACM en même temps, programmable en micropython avec des librairies modbus et MQTT disponibles, et pour couronner le tout sous Home Assistant il y a les intégrations water_heater.mqtt pour ici et climate.mqtt pour le T.One.
1 « J'aime »
J’ai monté un sniffer USB (toujours à base d’un raspberry pico https://github.com/ataradov/usb-sniffer-lite) entre la passerelle et le chauffe eau.
Voici par exemple, une trame lorsque j’envoie la commande « mode invité » depuis l’application:
1001 : SOF #403
3 : OUT: 0x01/1
5 : DATA0 (64): 33 ff 4c 33 26 00 01 01 96 03 00 00 87 00 00 28 9f 05 76 02 00 00 00 00 00 00 00 ff 00 00 00 00 4e 4e 4e 00 94 90 ff 03 00 00 00 00 00 00 00 00 00 8d c1 6c 01 00 00 00 00 90 63 2a 00 00 00 00
51 : ACK
85 : OUT: 0x01/1
87 : DATA1 (13): 00 26 00 00 00 00 00 00 00 00 00 32 84
99 : NAK
1000 : SOF #404
3 : OUT: 0x01/1
5 : DATA1 (13): 00 26 00 00 00 00 00 00 00 00 00 32 84
17 : ACK
... : Folded 785 frames
1000 : SOF #1190
4 : IN: 0x01/1
Je ne pense pas que le protocole soit du MODBUS…
Et je ne vois pas pourquoi, dans la trame qu’envoi en permanence la passerelle, le CRC n’est pas bon!
J’ai essayé d’envoyer les commandes ci dessus au CE, sans succès.
N’hésitez pas si vous avez des idées!
@yanoooou Je n’arrive pas non plus alors que j’arrive avec un simulateur Modbus, cf Aldes T.One AIR / AquaAIR - #217 par guix77
@guix77 , moi j’ai reussi à envoyer la requête
02 03 04 00 01 02 0B a2
mais directement en écrivant les bytes sur le port série du pico W.
Oui, je veux dire que mes tests soutiennent ton hypothèse selon laquelle ça ne serait pas du Modbus.
C’est étonnant qu’en branchant la passerelle au PC on reconnaisse du modbus, CRC compris et que ensuite ça ne fonctionne pas sur la carte mère.
Est-ce que la passerelle n’aurait pas 2 protocoles implémentés en fonction d’où elle est branchée ? Du genre un driver pour du debug sur PC et un autre implémenté pour la com directe avec la carte mère ?
Même si si ça avait été du modbus, tu ne verrais pas des trames modbus passer sur le sniffer si ? J’aurais dit que les trames modbus sont encapsulées dans le protocole usb et interprétées par le driver.
Possible mais peu probable. Ça commence à faire du monde dans la passerelle, y’a plusieurs UART déjà qui servent sûrement à la programmation / debug.
Sauf que les checksum ne sont pas toujours OK, comme certaines qu’on obtient avec un simulateur. Mais après c’est vrai que ça ressemble diablement. Est-ce qu’une coïncidence est possible à ce niveau et que ça ressemble à du Modbus sans en être ?
La couche software du EBUS ressemble au MODBUS…
J’essaye de comprendre l’intérêt d’implémenter un autre protocole alors qu’ils ont déjà du modbus sur les autres appareils (VMC ou Pompe à Chaleur) 
Si c’est pas du modbus c’est une sacrée coïncidence que ce soit reconnu comme tel sur la première trame envoyée mais je ne sais pas à quel point d’autres protocoles pourraient ressembler.
Bref ça se complique 
T’arrives à voir sur quel composant est branché l’USB ?
J’ai du mal à lire les circuits, à l’occasion je pourrais l’ouvrir à nouveau.
Ça peut aider, pour la télécommande il n’y avait pas de doute, c’était un convertisseur RS485-TTL
Je viens de relire le fil depuis le début pour me rafraichir la mémoire, on avait pas mal exploré de pistes déjà, c’est intéressant j’avais oublié.
@guix77 t’avais déjà étudié la carte visiblement sur ce post
Je vois aussi que @PaC avait vu que c’était du modbus sur l’adresse 4 pour sa VMC ici
Quant à @AirV il a confirmé que ce n’était pas du ebus ici
Et c’est vrai que @yanoooou est arrivé assez loin dans le décodage du ibus mais le décodage du CRC bloque aussi.
En gros via l’USB ça ressemble à du modbus et de l’ebus mais on n’a pas trouvé complètement comment décoder.
Comment tu as trouvé cette trame ? Il semblerait que sur la pompe à chaleur on ait un 7e octet en plus et que du coup le CRC soit bon.
Pour avoir la trame 02 03 04 00 01 02 0B a2, j’ai simplement branché la passerelle sur mon pc.
Et j’ai ouvert un moniteur série sur le port /dev/ttyACM0. La passerelle envoi périodiquement cette trame.
J’obtiens la même chose que toi @yanoooou, avec le même procédé.