briseis

Bonsoir Amaury Si tu as la régulation correspondant a cette documentation : http://inovatherm.free.fr/lesite1/cariboost_files/notice_20technique_20tableau_20de_20commande_20diematic_203_20_28fm129_29.pdf J'ai l'impression qu'il faut, dans les paramètres de configuration, activer la fonction 'hors gel par télécommande téléphonique". Regarde page 31, le paramètre E-TEL Si E-TEL est bien configuré en "ANTIGEL", alors le fait d'établir le contact entre la pin 1 et 2 de la prise "relais téléphonique" devrait déclencher l'antigel. ( cf https://www.jeanpaulguy.fr/notice/NOTICE REGULATION DD/Notice installation Tableau de commande DIEMATIC 3 (FM129).pdf page 7, les pin 1 et 2 sont les entrées a connectées, et 3 et 4 la sortie alarme. Si E-Tel est bien configurée et que pour tester, tu relie les bornes 1 et 2, la chaudière devrait se mettre en antigel. Sinon, je suis "largué" et je donne ma langue au chat ... A+

Bonjour, Si ton objectif est uniquement de pouvoir activer / désactiver la fonction hors gel à distance, pourquoi ne pas. simplement utiliser la prise relais téléphonique ? Dans mon cas, j'ai une régulation diematic delta, la carte est équipée d'une broche 2 pin "relais téléphonique" et il suffit de connecter ces deux broches pour que la chaudière se mette en hors gel. Si ta carte est aussi équipée de ce connecteur "relais téléphonique", tu tire 2 cables faible section, (cable téléphonique, internet, etc ...) de cette prise de ta chaudière jusqu'a l'endroit ou tu veut mettre ton pilotage (par exemple la ou tu as ton raspberry), puis tu connectes ces deux fils à un relais. La tension et l'intensité sont très faible, et un relais analogique (et pas electro mécanique) est largement suffisant. J'ai pris un CMOS 4066 ( 4 switch) à 0,5€, et tu pilote le relais directement par une de tes broches du GPIO du rasbery. Laurent

Effectivement, je suis intéressé par la gestion du hors gel ... Mon email n'a pas changé. Merci

Bonjour, Heureux que ma contribution t'ai été utile. Peut tu préciser le "confit" que tu avait ? Sinon, de mon côte, j'utilise l'interface modus pour contrôler chez moi ou a distances la plus part des paramètres. MAIS, je n'ai jamais réussit, avec cette approche, a contrôler la bascule "hors gel" / "normal" (alors que qu'il semble y avoir des registres pour cela dans la pages des paramètres) Du coup, j'ai "bêtement" utiliser un switch CMOS, type CD4016B, que je met en "relais" entre les deux fils de l'interface "relais téléphonique" de la carte DELTA, et que je pilote bêtement avec un des GPIO du raspberry. C'est hyper simple et ça marche très bien. Briseis

Bonjour Yves et Lionel, Malheureusement, de mon côté, j'ai eut une surtension liée à la foudre qui a détruit mon raspberry et donc, le système de contrôle de la chaudière. (surtension arrivée via la ligne téléphonique qui a bousillée ma box et le raspberry connecté en filaire à la box. La chaudière n'a rien eut). Je n'ai pas eut le courage de m'y remettre pendant l'été. Cependant, l'hiver étant a nouveau là, je vais racheter un raspberry, et recommencer ... Sinon, sur le principe : Oui, on arrive à décoder les informations que la chaudière "diematic delta" et à lui envoyer des informations qu'elle comprend. Donc, oui, le principe est validé. Maintenant, le code est "brut" et manque de finition ... Laurent

diematic_scan.c

Diemtatic Delta : 4ème point : mini interface web. Le programme esclave "diematic_scan" n'a pas d'interface pour modifier les paramètres. On peut cependant, en ligne de commande, lui fournir les informations : La commande suivante, par exemple, demande de mettre sur la page de paramètre 1, le registre 14 (température de consigne jour, circuit A), à 195 (ie 19,5 °C) et le registre 15 (T. Consigne Nuit, A) à 155 (ie, 15,5°C) echo '14 195 15 155' >> /tmp/diematic_update_params_p1 L'interface web va se contenter (de façon très frugale) de lire les fichiers /tmp/diematic_params_P(x) pour afficher les parametres de la chaudirèes et écrire les fichiers /tmp/diematic_update_params_p(x) pour les faire modifiers. (attention, il y a un gag entre minuscule et majuscule sur P ... ) le serveur (diematic.js) (node diematic.js pour le lancer) var express = require('express'); var fs = require("fs"); var app = express(); var input_params_p1 = "/tmp/diematic_params_p1"; var update_params_p1 = "/tmp/diematic_update_params_p1"; var buffer = Buffer.alloc(246); function b2int16(buffer,key) { return buffer[(key-1)<<1] + (buffer[((key-1)<<1)+1]<<8); } var jours= ["Lundi", "Mardi", "Mercredi", "Jeudi", "Vendredi", "Samedi","Dimanche"]; function jour(n) { return jours[n+1] } app.get('/params_p1', function(req, res) { fs.open(input_params_p1, 'r', function(status, fd) { if (status) { console.log(status.message); return; } fs.read(fd, buffer, 0, 246, 0, function(err, num) { res.render('params_p1.ejs', {buffer, b2int16, jour}); }); }); }); app.get('/update_p1', function (req, res) { fs.open(update_params_p1, 'w', (status, fd) => { if (status) { console.log(status.message); return; } for( var key in req.query ) { fs.write(fd, Number(key.slice(2)) + ' ' + req.query[key] + '\n', (err, num) => {}); } }); res.redirect('/params_p1'); }) app.use(function(req, res, next){ res.setHeader('Content-Type', 'text/plain'); res.send(404, 'Page introuvable !'); }); app.listen(8080); Ensuite, la vue ( dans le répertoire view de la ou vous avez créer le fichier serveur", le fichier "params_p1.ejs" pour la gestion de quelques paramètres de la page 1: <h1> Diematic Delta, page 1</h1> <p> <%= jour( b2int16(buffer, 6) )%>, <%= b2int16(buffer,4) %>h<%= b2int16(buffer,5) %> , le <%= b2int16(buffer,108)%>/<%= b2int16(buffer,109)%>/20<%= b2int16(buffer,110)%> </p> <p> T° Exterieur : <%= b2int16(buffer,7)/10 %> °C <br> T° Intérieur, Circuit A : <%= b2int16(buffer,18)/10 %> °C <br> T° Ballon ECS : <%= b2int16(buffer,62)/10 %> °C </p> <form action = "http://127.0.0.1:8080/update_p1" method = "GET"> Nombre de jour d'antigel: <input type = "number" value = <%= b2int16(buffer,13) %> name = "r_13"><br> Temperature consigne Jour, Circuit A, (0,1°C): <input type = "number" value = <%= b2int16(buffer,14) %> name = "r_14"><br> Temperature consigne Nuit, Circuit A, (0,1°C): <input type = "number" value = <%= b2int16(buffer,15) %> name = "r_15"><br> Temperature antigel, Circuit A, (0,1°C): <input type = "number" value = <%= b2int16(buffer,16) %> name = "r_16"><br> <input type = "submit" value = "Submit"> </form> </p> Voila, si tout se passe bien, vous devriez avoir un début d'interface web pour modifier les paramètres de la chaudière a distance (sur le port 8080) Dès que possible, je met cela au propre dans une archive GitHub ... Laurent

diematic_scan.cdiematic_scan.cdiematic_scan.cdiematic_scan.cdiematic_scan.cDiematic Delta : 3 / L'esclave 0x32 Par ce que je suis un "gros faisant", je me suis mis dans le répertoire test de libmodbus, afin de profiter du makefile pour compiler l'esclave. le fichier, dans ce répertoire test, s'appel "diematic_scan.c" Il faut donc rajouter 3 lignes dans le Makefile.am : diff tests/Makefile.am ~/libmodbus/tests/Makefile.am 11d10 diematic_scan 37,39d35 diematic_scan_SOURCES = diematic_scan.c diematic_scan_LDADD = $(common_ldflags) Ensuite, le fichier "diematic_scan.c" (en attaché) Le principe du programme de l'escale est d'attendre un message de la chaudière, soit un multiple write, soit un multiple read. Pour le multiple write, l'esclave répond puis sauvegarde les registres sur un fichier externe pour permettre a d'autres programmes de les utiliser. Pour le multiple read, l'esclave, avant de répondre, regarde si il faut modifier les registres, et si oui, le fait, puis renvois les registres à la chaudière. Il y a encore des "zones de maladresse" / "debug" (car c'est tout chaud) A noter que la bibliothèque libmod s'attend a ce que a chaque message du maitre, il y ait une réponse d'un esclave. Elle va donc "sauter" le prochain message, car elle pense que c'est une réponse. Dans notre cas, les escalates 71, 72 et 73 ne répondent pas ... et par défaut, la bibliothèque modifiée (les 3 zeros) ne gère pas bien cette situation. Les deux lignes suivantes sont pour "forcer" la bibliothèque" a considérer que tous les messages sont a "décoder" et a donc consommer les 3 zeros. modbus_rtu_t *ctx_rtu = ctx->backend_data; ctx_rtu->confirmation_to_ignore = FALSE; Si tout ce passe bien, en mode "DEBUG", vous devriez avoir les 2 premières pages de 123 registres qui s'affichent. Afin de ne pas alourdir le code, j'ai mis dans un fichier .h, les libellés de ces 246 registres : (j'ai rajouté un registre vide à zero car en C les tableaux commence à zero et pas à 1. (fichier attaché) Voila pour l'esclave. Le dernier post est sur une mini interface web. diematic_modbus.c diematic_delta_parameters.h

Diematic Delta : Le protocole "Modbus" avec ces 3 zeros. Dans la sortie précédente, on a vu que DD rajoutait 3 zero a la fin de chaque message modbus. Il va donc falloir, a la fois dans la lecture d'un message, et aussi dans l'envois d'un message, "ajouter" ces zeros pour que la chaudière accepte de nous parler ... J'ai utiliser la bioblithèque libmodbus . Il existe une version qui est porté pour le raspberry disponible sous GitHub : https://github.com/stephane/libmodbus/wiki/Libmodbus-on-Raspberry-pi Il faut suivre les instructions et l'installer. Malheureusement, il va falloir la modifier à 2 endroits : 1/ Dans le fichier src/modbus.c pour "consommer" et "ajouter" les 3 zeros. 2/ Dans le fichier src/modbus-rtu.c pour ajuster le temps de maintien des signaux "Enables" pendant la phase d'écriture du max485, piloté par un des GPIO du raspberry (le 28 dans mon cas) Ci-joint le patch (diff) pour le fichier modbus.c : diff src/modbus.c ~/libmodbus/src/modbus.c 178,183d177 < // ajoute les 3 zero du protocole "Modbus de diematic" < // ajoute 1 bit de bourrage < msg[msg_length++] = 0; < msg[msg_length++] = 0; < msg[msg_length++] = 0; < 460,461d453 < // Allonge de 3 la longueur et oblige la "lecture" des 3 zeros du protocole modbus diematic < length_to_read += 3; // 3 zeros 484,485c476 < // return ctx->backend->check_integrity(ctx, msg, msg_length); < return ctx->backend->check_integrity(ctx, msg, msg_length-3); // on calcul le check sum sans les 3 zeros ajoutés par diematec. --- > return ctx->backend->check_integrity(ctx, msg, msg_length); et celui pour le fichier modbus-rtu.c : diff src/modbus-rtu.c ~/libmodbus/src/modbus-rtu.c 337,338c337,338 < size = write(ctx->s, req, req_length); < usleep((ctx_rtu->onebyte_time+10) * req_length + 1200 ); --- > size = write(ctx->s, req, req_length); > usleep(ctx_rtu->onebyte_time * req_length); Pour ce dernier, la modification consiste a attendre "10 us x la taille du message + un delta " de plus avant de relâcher la pin GPIO dans l'état correspondant à la lecture du bus Une fois la biblothèque installé, modifié et compilé, on va écrire le code de l'esclave : Etape 3

Diematic Delta : 1 / La connection J'ai utilisé un Raspberry pi 3 et je lui ai mis un module de convertion RS485 -TTL en mode RTU. Il y en a plein de disponible sur le Web ( mots clefs: RS485 TTL) à 2 ou 3 € ... De même il existe plein de doc sur comment connecter ces modules à un raspberry (chercher max485 raspberry). (par exemple https://www.homegear.eu/index.php/RS485_Serial_Module) les 5/6 connections sont VCC sur le 5V du pi GND sur le GND du pi DI (driver In du max485) sur le port serie du PI, pin "transmit" TX / UART TXD RO (Receiver output du max485), sur le port série du pi, pin "received", RX / UART RXD Ensuite, il faut piloter les drivers Enable et receiver Enable. Comme ces deux signaux sont en logique "opposé", il est possible de les réunir et de les piloter par un seul port GPIO du raspberry. Dans mon cas, j'ai utilisé le GPIO 28 du PI, mais n'importe quel GPIO libre fait l'affaire. (La gestion de ce Enable sera un peu délicat ... ) Ensuite, il faut configurer le raspberry pour avoir le port serie fonctionnel. Attention, le "bon port serie" est /dev/ttyS0. Tant que vous n'avez pas configurer le port serie correctement, et que vous n'avez pas tester votre connection, ce n'est pas la peine de passer à la suite. Pour tester si tout va bien, vous pouvez allez "écouter" ce qui se passe sur la ligne RS485 (connecté a la fois au PI et à la chaudière). Ci dessous un petit programme en python : pi@raspberrypi:~ $ more serial_read.py #! /usr/bin/python import sys import time import serial import os ser = serial.Serial( port='/dev/ttyS0', baudrate = 9600, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE, bytesize=serial.EIGHTBITS, timeout=10 ) # a 9600 baus, 1 caractere time = 1,2 ms, 3.5ct = 4 ms os.system ( "gpio mode 28 out") os.system ( "gpio write 28 0") old_time = time.time() while 1: x=ser.read() new_time = time.time() delta_time = new_time - old_time old_time = new_time # print(x.encode('hex')) if delta_time > 0.004 : sys.stdout.write('\n') if delta_time > 5: sys.stdout.write('new cycle\n') sys.stdout.write(x.encode('hex')) Et la sortie doit répéter le message suivant : ... new cycle 4703001100029aa8000000 4803001a0002eb95000000 4903002600022a48000000 32100001007bf6010a0002001e001000370006003000dc001e000100040001000000c300a0003c008800cc0003001901d4000000c800a0003c0088ffff0003000700c802ee0000ffff000000c800a0003c0088ffff0003000700c802ee0000ffff000000c800c800c80088ffff0003000700c802ee00000000000002580000000402730000000000010000000000960096012c02ee0028005001d40214ffff001400010000000000000000000000000000000000000000009100300080008000000010001000000000000000000009000000300000000000000000000000040003001100310000800100110001000002140000000000000000000000007626000000 new cycle ... Cette sortie correspond a 4 messages de la chaudière adressés à 4 esclaves différents : les 3 esclaves 0x47 (71), 0x48 (72) et 0x49 (73) et l'esclave 0x32 (50). Les 3 premiers ne nous intéresse pas. C'est le dernier esclave qui l'on va émuler. Pour l'instant, compte tenu qu'il n'y a pas d'esclave sur la ligne RS485, on ne capture que des demandes de la chaudière et ces demandes restent sans réponse. Enfin, a noter que dans le protocole modbus de dd, dd va rajouter 3 "int16" à zéro à la fin des messages (donc 6 octets) (IL faudra donc modifier le protocole standard "modbus" pour prendre en compte cet ajout des 3 "mots" à zero dans le protocole. C'est le post suivant. laurent

Bonjour à tous. Merci beaucoup pour ce post, ca ma beaucoup aidé a résoudre mon problème. En particulier Domip et sa solution web pour piloter a distance une "Diematic ISystem". Dans mon cas, j'ai une Diematic Delta et la solution proposée ne marche pas. Par contre, il est quand même possible d'arriver à dialoguer via le protocole modbus avec la Diematic Delta. La différence essentielle entre les deux, c'est que dans la Delta, DD n'utilise pas un protocole modbus bi-maitre, c'est à dire, pendant 5 secondes, la chaudière est maitre et interroge les esclaves pendant qu'elle a envie, puis pendant 5 seconde elle devient esclave et répond éventuellement à un maitre qui aurait pris le controle du bus pendant cette période. Pour la Delta, c'est un protocole bi "Maitre / Absence" : La chaudière est maitre pendant 5 secondes, puis va libérer le bus pendant les autres secondes, mais n'écoute plus du tout ce qui se passe sur le bus. Elle ne peut donc pas répondre a une éventuelle question d'un autre maitre. Pour confirmer cela, si on regarde le chip 'ADM483' qui transforme la liaison RS485 en TTL, on s'aperçoit que la PIN RE (active à 0) est à 1 quand la chaudière libère le bus. Elle ne peut donc "rien entendre". Par contre, ce qui est intéressant, c'est que pendant sa période maitre, la chaudière interroge un esclave particulier, à l'adresse 0x32 (50) et que si cet esclave répond, elle va modifier ces paramètres. Le fonctionnement est le suivant : La chaudière envoi une commande de "Multiple Write Register" contenant les 123 registres de sa "première page de paramètres". Puis si l'esclave 0x32 lui répond, alors elle lui demande les même 123 registres (Multiple Read Register"), et si l'esclave répond, en ayant modifier éventuellement 1 ou plusieurs registres, alors la chaudière met a jours cette première page de registres, puis passe à la page 2 (registres de 124 à 246), puis à la page 3 (de 247 à 369). On peut donc programmer cet esclave 0x32 pour recevoir et modifier / renvoyer les paramètres de la chaudière. C'est cette programmation qui va "suivre" dans le reste du post. Cependant comme c'est assez long, je vais le découper en 4 étapes : 1/ La connexion 2/ Le protocole "Modbus" a la façon de DD, en utilisant la bibliothèque libmodbus 3/ l'esclave 0x32 4/ Une mini interface web pour afficher et modifier les paramètres. A tout de suite pour le post "1". Sinon, ce qui m'a "motivé", c'est que c'est la deuxième fois que l'électronique / programmation me lache sur cette chaudière. La première fois j'ai changé les cartes et ca m'a couté un bras ... la deuxième fois (la chaudière ne me permettait plus de modifier les températures de consigne jour et nuit), j'ai décider de "prendre la main" .... Laurent

Bonjour, Je voulais juste apporter mon retour d'experience sur le pilotage "modbus" d'une de dietrich Diematic Delta en ajoutant une réponse au sujet " Mais apparemment, il n'est pas possible d'ajouter un message, tant que on ne s'est pas présenté ... Je ne sait pas si je vais être autorisé ou non a faire mon retour d'expérience dans ce post ... En qq mots, une différence importante entre la version Isystem et la version Delta : En Delta, le protocole modbus utilisé n'est pas "bi-maitre", au sens ou la chaudière est maitre pendant 5 secondes et interroge les esclaves, puis "esclave" pendant 5 secondes, et répond a un éventuel maitre, mais fonctionne en "maitre-absence", c'est a dire que la chaudière est maitre pendant 5 secondes, puis libère le bus pendant 5 secondes mais ne l'écoute plus. La solution du post en référence , basé sur une interrogation de la chaudière quand elle est "esclave" ne marche donc pas, puisque celle-ci ne se met pas en mode escalate, mais se retire du bus pendant les 5 secondes ou elle n'est pas maitre, car elle n'écoute plus rien ... Par contre, ce qui est intéressant, c'est que pendant qu'elle est maitre, elle va échanger avec un esclave particulier, ayant l'adresse 0x32 (50). L'échange consiste, pour la chaudière en mode maitre, à envoyer à l'esclave 0x32, les 123 premiers registres, puis, si l'esclave a répondu, lui demander les mêmes 123 registres, ce qui permet à l'esclave de modifier la valeur de un (ou plusieurs) des registres renvoyés, (comme le 14, pour la température de consigne jour du circuit A). Ca marche bien. On peut ainsi piloter a distance tous les paramètres de la chaudière. Si j'arrive a répondre au topic en question, j'expliquerais plus en détail la solution. Cordialement, Laurent