vincentteam53 Posté(e) le 17 octobre 2016 Signaler Posté(e) le 17 octobre 2016 Bonjour àtous, Je possède une MCA25 avec une régulation diematic3 isystem, Je trouve la solution autour d'une interface ethernet/RS485 USR-TCP232-24 proposée par Domip particulièrement intéressante. Je possède une HC2, et je souhaiterai aussi piloter le Diematic via l'interface Ethernet/RS485 mais directement depuis le HC2 sans passer par un serveur Php Rasperry ou autres ... L'interface USR est en commande, si quelqu'un a commencé àtravailler sur le sujet je suis preneur, car je galère un peu àporter le code Php en Lua... En tout cas bravo et merci àtous pour vos partages. Vincent
supercyprien Posté(e) le 22 novembre 2016 Signaler Posté(e) le 22 novembre 2016 Le 29/02/2016 à 22:00, nico68 a dit : Au fil de mes recherches, je suis tombé sur une documentation LACROIX (anciennement SOFREL), fabricant connu pour ses solutions industrielles de télégestion, qui donnent des infos sur l'adressage MODBUS de la Diematic : http://espace-technique.lacroix-sofrel.fr/uploads/tx_oxcssofrel/S500-doc_20-10-DE_DIETRICH_-_Diematic.pdf Salut à tous, apparemment le fichier n'est plus dispo sur leur serveur. Est-ce quelqu'un l'aurait conservé ?
lipon67 Posté(e) le 23 novembre 2016 Signaler Posté(e) le 23 novembre 2016 Il y a 6 heures, supercyprien a dit : Salut à tous, apparemment le fichier n'est plus dispo sur leur serveur. Est-ce quelqu'un l'aurait conservé ? Bonjour. Tout est sur mon Gdrive, voir mon post du 29/09/16 en page 5/6.
nico68 Posté(e) le 10 décembre 2016 Signaler Posté(e) le 10 décembre 2016 Bonjour, Les températures négatives sont arrivées. J'ai un souci lors de la lecture de la température extérieure. J'utilise le script : temp_ext = instrument.read_register(7, 1) J'ai en retour la valeur 3277,6 pour une température réelle (relevée sur l'afficheur de la chaudière) de -0,8 ° et 3277,4 pour -0,6° En cherchant un peu, il y aurait une histoire de complément à 2 : https://pypi.python.org/pypi/MinimalModbus/0.4 Negative numbers (INT16 = short) Some manufacturers allow negative values for some registers. Instead of an allowed integer range 0-65535, a range -32768 to 32767 is allowed. This is implemented as any received value in the upper range (32768-65535) is interpreted as negative value (in the range -32768 to -1). This is two’s complement and is described at http://en.wikipedia.org/wiki/Two%27s_complement. Help functions to calculate the two’s complement value (and back) are provided in MinimalModbus. Quelqu'un aurait-il solutionné ce problème ? Merci d'avance
domip Posté(e) le 10 décembre 2016 Signaler Posté(e) le 10 décembre 2016 Bonjour, avec les regulation Diematic les valeurs négatives ne sont pas codés en compléments à deux. Le bit de poids fort (b15) est à 1, et les bits 0 à 14 contiennent la valeur absolu du paramètre. En php pour ça se décode comme ça: if ($this->rxReg[$regAddr+$i] >= 0x8000) $this->rxReg[$regAddr+$i]=-($this->rxReg[$regAddr+$i] & 0x7FFF); Benoit
nico68 Posté(e) le 11 décembre 2016 Signaler Posté(e) le 11 décembre 2016 Le 10/12/2016 à 12:15, domip a dit : Bonjour, avec les regulation Diematic les valeurs négatives ne sont pas codés en compléments à deux. Le bit de poids fort (b15) est à 1, et les bits 0 à 14 contiennent la valeur absolu du paramètre. En php pour ça se décode comme ça: if ($this->rxReg[$regAddr+$i] >= 0x8000) $this->rxReg[$regAddr+$i]=-($this->rxReg[$regAddr+$i] & 0x7FFF); Benoit Bonjour, Merci Domip. En m'inspirant de votre script, j'ai finalement trouvé quelque chose de fonctionnel de mon côté. C'est certainement optimisable mais çà a le mérite de fonctionner : ## Lecture temperature exterieure registre 7 avec calcul valeur negative ## temp_ext = instrument.read_register(7, 1) # Registernumber, number of decimals print '==========================' print 'Temperature exterieure : ' print temp_ext temp_extn = - (temp_ext - 3276.8) print 'variable temp_extn' print temp_extn # Ecriture Domoticz si temperature positive payload2 = {'type': 'command', 'param': 'udevice', 'idx': '1', 'svalue': temp_ext} # Ecriture Domoticz si temperature negative payload1 = {'type': 'command', 'param': 'udevice', 'idx': '1', 'svalue': temp_extn} if temp_ext > 3200: p1 = requests.put("http://127.0.0.1:8080/json.htm", params=payload1) print p1 if temp_ext < 3200: p2 = requests.put("http://127.0.0.1:8080/json.htm", params=payload2) print p2 En fait, je lis la valeur du registre et j'y soustrais 3276,8 (7FFF en hexa) lorsque la valeur lue est supérieure à 3200. Script testé la nuit dernière, la valeur écrite sur Domoticz correspond bien à la valeur indiquée sur la chaudière, donc çà fonctionne.
Fredmas Posté(e) le 11 décembre 2016 Signaler Posté(e) le 11 décembre 2016 (modifié) Sans vouloir faire de hors sujet, je vais suivre votre post car j'ai également une De Dietrich Diematic à condensation de moins de 2 ans. Par contre j'ai 100% de vannes LC13 pour gérer le chauffage de chacune des pièces, avec un circuit de délestage. Alors pas réellement besoin de piloter complètement la chaudière. Mon questionnement et mes doutes concernent davantage le "bon" réglage de la chaudière pour que la modulation se fasse intelligemment et apporte toujours de l'eau à "bonne" température dans le circuit. Modifié le 24 décembre 2016 par Fredmas
vincentteam53 Posté(e) le 23 décembre 2016 Signaler Posté(e) le 23 décembre 2016 Bonsoir à tous, Voici un petit moment que je surveille cette discussion, c'est ce qui m'a beaucoup aidé sur la mise en place d'une ébauche de solution directement intégrée dans un Virtual Device sur HomeCenter2, Je suis reparti de l'architecture proposé par Domip (lien ici), qui consiste à communiquer avec le Diematic via un convertisseur RS485-TCP/IP du commerce (USR-TCP232-24) en l’intégrant dans un VD du HC2. Ce VD est encore en phase de debug et ne permet pour le moment que de monitorer les paramètres du Diematic mais pas de les modifier (les fonctions d'écriture viendrons plus tard car il est nécessaire de bien stabiliser la communication et d'optimiser le code avant d'aller plus loin). Néanmoins il est déjà intéressant pour surveiller le comportement du chauffage lorsqu'on le couple avec un autre VD probablement bien connu sur ce forum et qui permet d’enregistrer toutes les valeurs de T°C et de conso dans une BDD pour pouvoir ensuite les afficher/analyser (DomoCharts). Je partage le code pour ceux que ça intéresse : VD_HC2_DeDietrich_Diematic_1.0.Lua Merci d'avance pour vos commentaires, VG 3
domip Posté(e) le 24 décembre 2016 Signaler Posté(e) le 24 décembre 2016 Bonjour, c'est effectivement une bonne idée de créer un "plugin" pour hc2. Le boulot a l'air conséquent, rien que pour recréer les opérateurs logiques. De mon coté j'ai testé le système avec un autre convertisseur tcp/rs485 : http://www.usriot.com/p/rs232-rs485-serial-device-servers/ Il présente l'intérêt d'être livré dans un boîtier et avec une alim pour un prix un peu plus conséquent. Ça fonctionne également sans problème. Benoît
Fanou Posté(e) le 24 décembre 2016 Signaler Posté(e) le 24 décembre 2016 @domip le lien ne semble pas fonctionner.. Envoyé de mon SM-G928F en utilisant Tapatalk
nico68 Posté(e) le 14 janvier 2017 Signaler Posté(e) le 14 janvier 2017 Bonjour, Quel mot utiliser pour forcer le ballon ECS (je cherche en fait l'équivalent de la touche "robinet") ?
nico68 Posté(e) le 15 janvier 2017 Signaler Posté(e) le 15 janvier 2017 Le 14/01/2017 à 14:43, nico68 a dit : Bonjour, Quel mot utiliser pour forcer le ballon ECS (je cherche en fait l'équivalent de la touche "robinet") ? Bonjour, J'ai finalement trouvé comme un grand. Pour activer la dérogation ECS (équivalent à l'appui sur la touche robinet), il suffit d'écrire la valeur hexa 88 sur l'adresse 26. Pour repasser en automatique (annuler la dérogation ECS), il suffit d'écrire la valeur hexa 8 sur l'adresse 26.
domip Posté(e) le 15 janvier 2017 Signaler Posté(e) le 15 janvier 2017 Bravo ! Je voulais t'indiquer de chercher le mot clef ecs dans les fichiers que j'ai fourni pour trouver les valeurs. Il faut utiliser les bits 4 (derog permanente) ou 6 (derog temporaire) du mot de sélection de fonctionnent du mode de chauffage ( adresse 17 pour le circuit de chauffage A, 26 pour le circuit chauffage B ). Benoit
nico68 Posté(e) le 16 janvier 2017 Signaler Posté(e) le 16 janvier 2017 Le 15/01/2017 à 21:47, domip a dit : Bravo ! Je voulais t'indiquer de chercher le mot clef ecs dans les fichiers que j'ai fourni pour trouver les valeurs. Il faut utiliser les bits 4 (derog permanente) ou 6 (derog temporaire) du mot de sélection de fonctionnent du mode de chauffage ( adresse 17 pour le circuit de chauffage A, 26 pour le circuit chauffage B ). Benoit Merci En fait, j'ai raisonné à l'inverse. J'ai lu l'adresse 26 en fonctionnement normal (c'est-à-dire sans la demande ECS). La chaudière me renvoie la valeur 8. Puis j'ai appuyé sur la touche "Robinet" de la commande à distance (même comportement si j'appui sur celui de la chaudière), là je lis la valeur 88 sur l'adresse 26. J'ai ensuite comparé ces valeurs avec le tableau que le support DDth m'avait envoyé l'an passé. La différence entre l'adresse 8 et 88 est uniquement le changement de la valeur du bit15 qui est insignifiant d'après la doc. Bref çà fonctionne comme çà, je ne cherche donc pas plus loin. Je reposte la dernière version du fichier d'adresses modbus diematic Isystem (v0[1].5). _ModBus_Parameter_Addresses_v0[1].5_Isystem.xls 1
Platypus Posté(e) le 12 février 2017 Signaler Posté(e) le 12 février 2017 Le 07/04/2016 à 15:47, Platypus a dit : Filou59, Bon, en fait, je me suis mélangé entre les photos de cartes électroniques que j'avais récupérés et la mienne en cherchant àles comparer. Je n'ai finalement pas de connecteur DIN :-( Je poste quand même la photo. Bonjour à tous, étant très occupé personnellement et professionnellement, je n'ai pas eu le temps d'avancer plus sur mon sujet évoqué précédemment (cf mes messages précédent). Pour moi, les sujets devraient être proches excepté l’interfaçage. En effet, votre problématique est d’interagir avec la chaudière à l'aide du modbus (que je n'ai pas) mais je note que certain d'entre vous ont aussi un régulateur à distance nommé Easymatic. Si ça vous intéresse, j'ai ouvert un sujet spécifique sur cette possibilité de communication avec la chaudière via le bus de l'Easymatic. Le but de ce message est donc de faire un lien avec le nouveau sujet créé : Communication Easymatic
briseis Posté(e) le 4 mars 2017 Signaler Posté(e) le 4 mars 2017 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
briseis Posté(e) le 4 mars 2017 Signaler Posté(e) le 4 mars 2017 (modifié) 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 Modifié le 4 mars 2017 par briseis
briseis Posté(e) le 4 mars 2017 Signaler Posté(e) le 4 mars 2017 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
briseis Posté(e) le 4 mars 2017 Signaler Posté(e) le 4 mars 2017 (modifié) 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.cdiematic_delta_parameters.h Modifié le 22 avril 2017 par briseis fichiers en attachés
briseis Posté(e) le 4 mars 2017 Signaler Posté(e) le 4 mars 2017 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
domip Posté(e) le 1 avril 2017 Signaler Posté(e) le 1 avril 2017 Bravo, c'est un sacré boulot. De mon coté, j'ai mis le code php (Interface Web pour Diematic 3) sur github https://github.com/Benoit3/Diematic Benoit
lionelpo91 Posté(e) le 5 avril 2017 Signaler Posté(e) le 5 avril 2017 (modifié) Salut Laurent (briseis), Tout d'abord bravo pour ce travail et ce partage ! Par contre dans ton post où tu parles du fichier "diematic_scan.c", je ne vois pas de nom relatif à ce fichier qui soit en pièce attachée ? Pour info je dispose d'une chaudière De Dietrich DTG Eliade 126 FF (2000) qui dispose du protocole Diematic Delta également. Je veux bien mettre en place ce que tu proposes chez moi et partager avec toi le résultat. Je m'intéresse aussi à mettre au point un VD Fibaro qui permettrait de dialoguer correctement avec la chaudière. De tout ce que je vois il y a de fortes chances de pouvoir le faire :-). Je t'ai aussi envoyer un MP afin de récupérer les fichiers manquants de ton post, si tu n'as pas eu le temps de poster cela dans Github. Merci pour ton support ! Lionel (lionelpo91) Modifié le 6 avril 2017 par lionelpo91
domip Posté(e) le 22 avril 2017 Signaler Posté(e) le 22 avril 2017 Bonjour, j'ai régulièrement des question sur l'interface ethernet/rs485 à utiliser. La liste des produits IOT semble évoluer souvent. En gros il faut choisir une interface ethernet/rs485 dans la liste dispo ici : http://www.usriot.com/products/serial-ethernet-converter/ Et ensuite le commander sur le site de votre choix. Benoit
briseis Posté(e) le 22 avril 2017 Signaler Posté(e) le 22 avril 2017 Le 05/04/2017 à 16:29, lionelpo91 a dit : Salut Laurent (briseis), Tout d'abord bravo pour ce travail et ce partage ! Par contre dans ton post où tu parles du fichier "diematic_scan.c", je ne vois pas de nom relatif à ce fichier qui soit en pièce attachée ? Pour info je dispose d'une chaudière De Dietrich DTG Eliade 126 FF (2000) qui dispose du protocole Diematic Delta également. Je veux bien mettre en place ce que tu proposes chez moi et partager avec toi le résultat. Je m'intéresse aussi à mettre au point un VD Fibaro qui permettrait de dialoguer correctement avec la chaudière. De tout ce que je vois il y a de fortes chances de pouvoir le faire :-). Je t'ai aussi envoyer un MP afin de récupérer les fichiers manquants de ton post, si tu n'as pas eu le temps de poster cela dans Github. Merci pour ton support ! Lionel (lionelpo91) diematic_scan.c
poupoune1974 Posté(e) le 6 mai 2017 Signaler Posté(e) le 6 mai 2017 Bonjour, Sans vouloir polluer le sujet, j'aimerais toutefois exposer mon souci. Ma chaudière De Dietrich GT120 est équipée d'un Diematic 3, mais sans commande à distance. J'ai toutefois acheté un convertisseur Ethernet/RS485 pour une vingtaine d'euros. Mon Diematic est équipé de deux prises mini Din sur le côté : je branche le A du convertisseur sur l'orifice en bas à gauche (au dessus du détrompeur) du Diematic, lorsque je le vois en face de moi. Et le B sur celle au-dessus. J'ai aussi sur le convertisseur une entrée G que je n'ai pas utilisée. Je mesure 3,4V à peu près sur les deux orifices de la prise mini Din fixe pendant quelques secondes, puis variables quelques secondes, ce qui laisserait supposer une communication possible. Mais rien ne s'affiche dans l'interface Web du convertisseur : Capture 2 Mes réglages en Capture 1. Une âme charitable aurait elle une idée ? D'avance merci pour l'intérêt porté à mon souci.
Messages recommandés