J’ai vu hier soir que la consigne ECS ne changeait pas dans les paramètres, j’ai l’impression que j’ai pas le droit de la modifier, même en rentrant le code installateur avec la télécommande
*** début hors sujet ***
On aurait dit que tu avais un abonnement genre TEMPO de EDF, et comme je me pose la question d’y passer, bien que je soit full électrique (chauffage et voiture comprises), m’étais dis au cas ou ^^
*** fin hors sujet ***
@djtef Pour la date il y a une typo, c’est 0x0010 et c’est un timestamp directement exploitable par HA.
Ma config :
uart:
baud_rate: 19200
tx_pin: GPIO16
rx_pin: GPIO17
parity: EVEN
modbus_controller:
- address: 0x1
binary_sensor:
- platform: modbus_controller
name: "Changer filtre"
device_class: problem
entity_category: diagnostic
icon: mdi:air-filter
register_type: holding
address: 0x0082
number:
- platform: modbus_controller
name: "Thermostat 1"
icon: "mdi:thermostat"
unit_of_measurement: "°C"
address: 0x96
value_type: U_WORD
min_value: 16
max_value: 31
use_write_multiple: true
multiply: 100
# - platform: modbus_controller
# name: "Thermostat 2"
# icon: "mdi:thermostat"
# unit_of_measurement: "°C"
# address: 0x97
# value_type: U_WORD
# min_value: 16
# max_value: 31
# use_write_multiple: true
# multiply: 100
- platform: modbus_controller
name: "Thermostat 3"
icon: "mdi:thermostat"
unit_of_measurement: "°C"
address: 0x98
value_type: U_WORD
min_value: 16
max_value: 31
use_write_multiple: true
multiply: 100
- platform: modbus_controller
name: "Thermostat 4"
icon: "mdi:thermostat"
unit_of_measurement: "°C"
address: 0x99
value_type: U_WORD
min_value: 16
max_value: 31
use_write_multiple: true
multiply: 100
- platform: modbus_controller
name: "Tarif HP"
icon: mdi:currency-eur
entity_category: config
mode: box
unit_of_measurement: "€"
address: 0xA0
value_type: U_WORD
min_value: 0.05
max_value: 1
use_write_multiple: true
multiply: 1000
step: 0.001
- platform: modbus_controller
name: "Tarif HC"
icon: mdi:currency-eur
entity_category: config
mode: box
unit_of_measurement: "€"
address: 0xA1
value_type: U_WORD
min_value: 0.05
max_value: 1
use_write_multiple: true
multiply: 1000
step: 0.001
select:
- platform: modbus_controller
name: "Mode air"
icon: "mdi:hvac"
address: 0x007A
value_type: U_WORD
use_write_multiple: true
optimistic: true
optionsmap:
"Eteint": 0
"Chauffage confort": 1
"Chauffage économique": 2
"Programme chauffage A": 3
"Programme chauffage B": 4
"Climatisation confort" : 5
"Climatisation boost" : 6
"Programme climatisation C" : 7
"Programme climatisation D" : 8
# "Ventilation" : 9
sensor:
- platform: modbus_controller
name: "Version logiciel"
disabled_by_default: true
entity_category: diagnostic
icon: mdi:package
register_type: holding
address: 0x0001
value_type: U_WORD
- platform: modbus_controller
name: "Identifiant IHM"
disabled_by_default: true
entity_category: diagnostic
icon: mdi:identifier
register_type: holding
address: 0x000E
value_type: U_DWORD
- platform: modbus_controller
name: "Date et heure"
device_class: timestamp
disabled_by_default: true
entity_category: diagnostic
icon: mdi:calendar-clock
register_type: holding
address: 0x0010
value_type: U_DWORD
- platform: modbus_controller
name: "Temperature principale"
device_class: "temperature"
state_class: "measurement"
register_type: holding
address: 0x0078
value_type: S_WORD
unit_of_measurement: "°C"
accuracy_decimals: 1
filters:
- multiply: 0.01
- platform: modbus_controller
id: mode_air
internal: true
register_type: holding
address: 0x007A
- platform: modbus_controller
id: thermostat_1
internal: yes
register_type: holding
address: 0x96
value_type: U_WORD
unit_of_measurement: "°C"
accuracy_decimals: 1
filters:
- multiply: 0.01
- platform: modbus_controller
id: thermostat_2
internal: yes
register_type: holding
address: 0x98
value_type: U_WORD
unit_of_measurement: "°C"
accuracy_decimals: 1
filters:
- multiply: 0.01
- platform: modbus_controller
id: thermostat_3
internal: yes
register_type: holding
address: 0x99
value_type: U_WORD
unit_of_measurement: "°C"
accuracy_decimals: 1
filters:
- multiply: 0.01
- platform: modbus_controller
id: hp
register_type: holding
address: 0xA0
value_type: U_WORD
unit_of_measurement: "€"
accuracy_decimals: 4
filters:
- multiply: 0.001
- platform: modbus_controller
id: hc
register_type: holding
address: 0xA1
value_type: U_WORD
unit_of_measurement: "€"
accuracy_decimals: 4
filters:
- multiply: 0.001
text_sensor:
- platform: modbus_controller
name: "Aiguillage vanne"
icon: mdi:valve
entity_category: diagnostic
register_type: holding
address: 0x0064
raw_encode: HEXBYTES
lambda: |-
uint16_t value = modbus_controller::word_from_hex_str(x, 0);
switch (value) {
case 0: return std::string("Etat initial");
case 1: return std::string("ECS");
case 2: return std::string("Air");
case 3: return std::string("Standby");
case 4: return std::string("Standby sécurité");
case 5: return std::string("En cours de modification");
default: return std::string("Inconnu");
}
return x;
1 « J'aime »
Hello les amis,
Bon je n’ai plus aucun signe de vie de ALDES, que ca soit l’email support ou l’email technique …
Il faudra faire avec ce que l’on a … 
Mais c’est déjà plutôt pas mal avancé du coup 
D’ailleurs, on en est où (enfin plutôt, vous en êtes ou ^^) ?
Est-ce qu’il y a des choses qu’ils manquent ? à optimiser ? c’est prêt à être utilisé ?
@djtef, j’attends le retour d’absence de mon installateur pour lui demander pour l’activation de la partie clim’ (réponses d’ici jeudi ou vendredi normalement 
)
Salut @visvic
Pour résumer on arrive à lire et écrire toutes les informations fournies par la doc que t’as récupérée, donc c’est déjà pas mal.
Le code esphome complet (corrigé avec les retours de @guix77) est ici
Selon moi ce qui manque d’intéressant ce sont les températures mesurées par les thermostats de chaque pièce, on peut uniquement envoyer une consigne.
Ensuite il est vrai que via la télécommande centrale on a beaucoup plus d’info disponible donc l’étape d’après ce serait d’arriver à interpréter les échanges (modbus aussi) entre la carte mère et la télécommande.
Il s’avère également que la passerelle dialogue en modbus via l’USB et simule un port série. Il semble que ce soit une 3e liaison avec une adresse 2 cette fois. Quand on la branche au PC on voit qu’elle envoie en boucle une requête, surement elle attend un retour de la carte mère pour débuter la com. Donc là aussi il y a de quoi explorer.
Merci 
Je viens de faire un test, j’ai essayé de faire communiquer un esp32 sur le port USB de la carte mère (où se branche la passerelle) avec une carte ftdi de manière à faire :
esp32 (Rx)<-----(Tx) FTDI (USB)----- (USB)T.One
esp32 (Tx)----->(Rx)
Je vois les LED Rx de la carte FTDI clignoter qu’une fois, comme si ça faisait qu’une requête, alors que quand je le branche au PC ça ne s’arrête pas et le logiciel qui espionne voit bien les trames passer 
Je comprends pas.
Et j’ai fait un second test « marrant » : j’ai connecté mon PC à l’USB de la carte mère en faisant : PC----USB/RS4585----RS485/TTL—TTL/USB—T.One.
Je voyais les led RX ou Tx scintiller, je pense que le problème vient du fait que le PC et la carte mère alimentent l’USB des deux côtés car j’ai essayé en faisant PC USB1 vers PC USB2 mon montage fonctionnait, je recevais bien les trames d’un port vers l’autre.
Bref dommage.
Mais je comprends pas pourquoi je n’arrive pas à brancher l’esp32 sur l’USB du T.One via l’USB, je me dis que peut-être le ftdi ne détecte pas de hôte et s’arrête de fonctionner ? Pourtant avec la passerelle ça fait bien la même chose puisqu’elle est vue comme un port série.
Les températures c’est ce qui manque le plus, après selon moi c’est l’état actuel de fonctionnement : est-ce que c’est en train de chauffer / refroidir ou pas ? Mais l’essentiel est là : on peut régler les consignes et choisir le mode. Dans l’état on peut dire que c’est utilisable et bien mieux qu’AldesConnect : la fiabilité et le local compensent largement l’absence de température selon moi. D’autant qu’on peut éventuellement les mesurer indépendamment.
Hier j’ai demandé la doc Modbus à Aldes et j’ai reçu la même chose que @visvic a posté. J’ai demandé à avoir une table plus complète et on m’a répondu que c’est le seul document qu’ils ont. De plus, ces jours-ci j’ai testé beaucoup de registres en me basant sur la logique et les autres doc Modbus d’Aldes, et je n’ai rien obtenu. A ce stade je conclus qu’il n’y a plus grand chose à tirer de cette interface Modbus et qu’il faut effectivement regarder du côté de la passerelle et de la télécommande.
A propos de l’interface télécommande, @djtef as-tu trouvé des adresses intéressantes ? Il y en a de la doc qui marchent ?
Et sinon est-ce qu’il ne faut pas tout simplement brancher le signal D+ et D- de l’USB directement sur Tx et Rx de l’ESP (avec un level shifter quand même) ? J’ai commandé un USB breakout, je pourrai essayer. Le but ultime est de toute façon de passer par l’USB sur le T.One de façon à ne même pas avoir besoin de l’ouvrir.
Salut,
J’ai regardé, il n’y a aucune correspondance dans les adresses des registres. Il faudrait que je fasse un gros dump de tous les registres pour voir si j’arrive à reconnaitre certains qu’on a déjà.
Je ne suis pas spécialiste en la matière mais j’ai pas mal réfléchi sur cette interface USB, et voilà ce que j’en conclus :
Le protocole USB n’a rien à voir avec le protocole série TTL qui sort de l’UART des esp, sur la couche bas niveau déjà, l’USB utilise une paire de transmissions différentielle pour les données alors que le TTL ce sont des niveaux logiques 0 ou 3.3/5V. De plus le protocole USB est composé de plusieurs couches de protocoles assez complexes contrairement au TTL qui n’en a pas.
Par contre, effectivement ils auraient pu utiliser l’USB en tant que simple connecteur mécanique pour relier 2 UART en série en n’utilisant pas du tout le protocole USB. Mais ce n’est pas le cas car en branchant la passerelle elle est reconnue en tant que port série, et si ça avait été du TTL ça ne lui aurait pas plu je pense.
Etant donné qu’à l’origine les ports série pouvaient connecter 2 PC, je pense qu’on doit pouvoir relier le PC à la carte mère en convertissant l’USB en TTL puis TTL en USB. Il faudrait peut-être essayer d’avoir deux cartes FTDI, mais je ne sais pas si elle serait reconnue du côté carte mère. Ou alors il faut un câble USB vers USB, j’ai vu qu’il existait des câbles appelés USB Null modem, en lisant la doc j’ai l’impression que ça correspondond à cette utilisation.
En tout cas je pense que le modbus via l’USB offre plus d’infos et de possibilités donc ça me parait être la voie à explorer. Avec la télécommande j’ai pas l’impression qu’on peut changer les consignes des thermostats par exemple.
Voilà l’état de ma réflexion 
Et juste pour finir, je ne comprends pas pourquoi la liaison esp32—ftdi—T.One ne fonctionne pas.
En effet le couple esp32/ftdi fonctionne sur le PC, c’est vu en tant que port série et ça envoie du modbus, tout comme quand on branche la passerelle, alors pourquoi ça ne communique pas quand on le branche à la carte mère… mystère.
Oui je pensais en simple connecteur mécanique, mais c’est vrai que dans ce cas la passerelle ne devrait pas agir en device USB. Piste à éliminer donc.
Ca pourrait marcher, ça serait marrant car la carte mère fait sûrement TTL => USB et le PC fait, comme la passerelle USB => TTL via le driver USB CDC (cf Chauffe Eau ALDES => B200-FAN_T.Flow® Hygro+ - #53 par guix77), on aurait donc TTL => USB => TTL => TTL => USB => TTL
On est seulement sûrs qu’il y a les températures mesurées, mais ça vaut le coup.
Edit: C’est peut-être pas du modbus qui passe sur l’USB
Edit: Quoique si, puisque j’ai chopé du modbus en branchant la passerelle sur le PC
Edit: Je suppose que tu interroges bien le T.One sur l’adresse 2
Oui c’est ce que je me dis, il faut deux convertisseurs USB/TTL mais je n’en ai qu’un. Sinon il faut se piquer directement sur le TTL de la carte mère 
Effectivement, selon moi il y a peu de doutes, surtout avec un checksum OK. Le problème que j’ai eu n’est pas au niveau du protocole, c’est vraiment un problème de com, la led du FTDI ne clignotait pas, alors que branchée sur mon PC ça fonctionnait.
Tout à fait :
modbus_controller:
- address: 0x2
update_interval: 5s
sensor:
- platform: modbus_controller
name: "Test1"
register_type: holding
address: 1056
value_type: U_WORD
Et tu as essayé avec un autre baud_rate ? Rien ne dit que c’est encore 19200
Attends je vais tester en rebranchant la passerelle sur PC pour voir si j’obtiens du traffic avec un autre baud_rate. De mémoire j’en avais vu passer mais c’était peut-être le master
Selon moi si tu ne mets pas le bon baudrate tu n’as pas de checksum OK
J’obtiens la même chose (le read holding sur le device 2 à l’adresse 1056) avec les baud_rates suivants:
- 115200, bcp de checksum KO mais des bonnes aussi
- 110 (oui 110), que des OK
Inutile de continuer, soit y’a un souçi, soit la passerelle et le PC sont capables de dialoguer à n’importe quelle vitesse, par contre pour le T.One il doit avoir la sienne
Il faudrait peut-être essayer de simuler un esclave en mettant des valeurs sur le registre 1056 pour voir si ça permet à la passerelle d’aller plus loin.
Il y a un logiciel Modbus Slave qui permet de faire ça, je viens de le télécharger pour voir.
@djtef Quand je branche la passerelle sous linux, j’obtiens avec dmesg:
[490347.970170] usb 1-13: new full-speed USB device number 56 using xhci_hcd
[490348.120228] usb 1-13: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
[490348.120243] usb 1-13: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[490348.120249] usb 1-13: Product: STM32 Virtual ComPort
[490348.120253] usb 1-13: Manufacturer: STMicroelectronics
[490348.120257] usb 1-13: SerialNumber: 00000000001A
[490348.123469] cdc_acm 1-13:1.0: ttyACM0: USB ACM device
et lsusb:
Bus 001 Device 056: ID 0483:5740 STMicroelectronics Virtual COM Port
et usb-devices:
T: Bus=01 Lev=01 Prnt=46 Port=12 Cnt=01 Dev#= 56 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=02(commc) Sub=02 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=0483 ProdID=5740 Rev=02.00
S: Manufacturer=STMicroelectronics
S: Product=STM32 Virtual ComPort
S: SerialNumber=00000000001A
C: #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=01 Driver=cdc_acm
E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=16ms
I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
Le driver est donc cdc_acm.
Le T.One, agissant en host USB, a donc forcément ce driver.
Quand tu mets ton FTDI avec l’ESP32 sur ton PC, le PC charge quel driver ? Peut-être que c’est un autre et que le T.One n’a pas ce driver.
Effectivement je pense que tu es sur la bonne piste, j’ai fait quelques recherches sur ce driver et on trouve plein d’exemples d’implémentation sur du STM32, ce qu’utilise Aldes dans ses cartes électroniques.
Malheureusement il n’a pas l’air d’exister de FTDI qui implémentent CDC/ACM. J’ai trouvé un forum où quelqu’un a le même besoin, si je résume il existe des puces qui font directement cette conversion :
MCP2200
MCP2221A
CY7C65213/A
STM32 Nucleo-64 development board
Les puces Microchip ne sont pas chères et je sais qu’un collègue arrive à se faire envoyer des échantillons gratuitement. Ça mériterait de tester :esp32(TxRx)—(TxRx)CDC/ACM(USB)—(USB)T.One
Edit : il existe une carte toute faite chez Adafruit pour le MCP2221A
S’il faut payer, dans une limite raisonnable, je peux faire du PayPal 