27/08/2014, 15:50:00 (Modification du message : 08/01/2015, 13:27:24 par vf62.)
Bonjour à tous !
J'ai mis en place chez moi une VMC communicante en modbus : la unelvent DOMEO 210.
Le but ultime est donc de pouvoir la contrôler via KNX.
Je vois donc ça en 2 etapes :
la controler en modbus
faire la passerelle vers knx
J'ai vu qu'il existe des passerelles toute faite modbus/knx mais c'est hors de prix (en tout cas, hors de mon budget)
Dans l'idée, je me voyais bien partir sur un raspberry et faire le pont avec la partie KNX via le trio.
fma38, vu ton poste sur ta VMC, je pense que tu as des billes sur le sujet. De mon côté, j'ai eu de la doc par unelvent qui décrit les paramètres modbus mis en place. je ne sais juste pas comment les attaquer ...
et premier point, est ce qu'il y a du matériel particulier à acheter ou on peut tout faire directement sur le raspberry ?
merci d'avance pour toutes les infos intéressantes !!
(le second me semble plus sérieux ; il utilise un chip FTDI, ultra connu et qui fonctionne bien. En plus, le premier n'a visiblement pas la masse, donc prudence, la VMC peut ne pas aimer).
Après, c'est juste du code. Si tu es sous RPi, tu pourras tester avec python, et par la suite utiliser pKNyX pour faire office de passerelle KNX.
Je t'enverrai un bout de code quand tu auras la passerelle physique RS485, mais il manque quand même des infos pour communiquer : il faudrait savoir de quels types de registres il s'agit, pour chaque groupe. Modbus connaît 4 types :
(Tu noteras que c'est à la base fait pour les automates. Mais on en fait bien ce qu'on veux)
D'après ta doc, j'aurais tendance à dire que le premier groupe correspond aux Discrete Input Contacts, le second aux Discrete Output Coils, et le dernier aux Analog Input Registers. Mais bon, c'est à vue de nez ! Il va falloir leur demander plus de précisions. Et être sûr que le numéro de la première colonne correspond bien à l'adresse de registre Modbus...
J'espère que c'est clair, jusque là
Ah, et j'oubliais : il faut aussi connaître l'ID de la VMC (numéro d'esclave)...
18/09/2014, 21:55:51 (Modification du message : 18/09/2014, 21:56:19 par vf62.)
Bonsoir,
Ca y est, tout est en place : le raspberry, la passerelle (celle que tu m'as recommandé) et c'est branché sur la vmc.
Le support m'a envoyé quelques infos supplémentaires :
« Pouvez-vous également me confirmer que le numéro de la première colonne correspond bien à l'adresse de registre Modbus ? : oui »
« Et dernière chose, je souhaiterai également connaître l'ID de la VMC (son numéro d'esclave) ? ou savoir comment le retrouver ? : Par défaut Nº1 mais peut être modifié dans le groupe "Holding registers" nº0 (Nœud ligne Modbus). »
Ainsi que la piece jointe avec les dernieres infos ...
Aurais tu le bout de code proposé ? car là, j'avoue sécher completement sans meme savoir si je reçois la moindre info
# lecture paramètres VERSION (descrete input)
result = client.read_coils(address=1, count=1)
print result.bits[0]
# lecture puis modification paramètre BATTERIE PRE-CHAUFFAGE (coils)
result = client.read_coils(address=1, count=1)
print result.bits[0]
client.write_coil(adresse=1, value=1)
# lecture VERSION LOGICIEL UNITE CENTRALE (input registers)
result = client.read_input_registers(address=1, count=1)
print result.registers[0]
# lecture puis modification SELECTION DEPHASAGE DEBIT (holding registers)
result = client.read_holding_registers(address=1, count=1)
print result.registers[0]
client.write_register(address=1, value=5)
client.close()
Il y a une ou deux autres méthodes à la classe ModbusTcpClient, pour lire/écrire plusieurs registres à la fois. Pour les connaître, dans ipython, tu fais (une fois la variable client créée) :
Code :
In [5]: client.<TAB> <<<<<<<<<< ici, ça veut dire cliquer sur la touche TAB ; ipython te montrera toutes les méthodes dispos
client.close client.port client.readwrite_registers client.write_register
client.connect client.read_coils client.socket client.write_registers
client.execute client.read_discrete_inputs client.transaction
client.framer client.read_holding_registers client.write_coil
client.host client.read_input_registers client.write_coils
In [5]: client.write_coils?
Type: instancemethod
String form: <bound method ModbusTcpClient.write_coils of <pymodbus.client.sync.ModbusTcpClient object at 0x7f11326d0c10>>
File: /usr/lib/python2.7/dist-packages/pymodbus/client/common.py
Definition: client.write_coils(self, address, values, **kwargs)
Docstring:
:param address: The starting address to write to
:param values: The values to write to the specified address
:param unit: The slave unit this request is targeting
:returns: A deferred response handle
In [6]:
Pour savoir un peu ce que les fonctions retournent, tu fais de même avec la variable result. Tu peux aussi le faire sur les fonctions d'écriture, pour voir ce que ça retourne (je n'ai pas de machine sur laquelle envoyer des commandes sous la main).
Voili. Après, tout dépendra de ce que tu veux faire. Commence par faire mumuse, et on verra ensuite si tu veux intégrer ça dans pKNyX pour mapper certains paramètres sur le bus
19/09/2014, 08:09:47 (Modification du message : 19/09/2014, 08:22:52 par fma38.)
Ah, c'est con que ça désactive la commande manu... Faudrait éventuellement prévoir un petit switch, qui te permettrait de reprendre la main localement si besoin (et prévoir dans le code la perte de connexion).
Au passage, je suis me suis gaufré : le client utilisé (ModbusTcpClient) est pour une connexion Tcp ; je regarde pour le client série... Mais je pense que ça ne change rien pour le reste.
Alors voici ce qu'il faut utiliser :
Code :
from pymodbus.client.sync import ModbusSerialClient
client = ModbusSerialClient(method='ascii', port='/dev/ttyS0', baudrate=19200)
client.connect() <<<<<< je ne sais pas trop si c'est nécessaire
Mettre le bon port (ça va être un ttyUSBxxx, je pense), et voir si c'est bien 'ascii' (sinon, essayer 'binary' ou 'rtu').
Je suis dans le même projet que VF62, avec la même VMC...
Malheureusement, je n'ai pas encore eu le temps de m'y mettre. C'est loonnnng les travaux de rénovation !!!
Enfin bref, je relisais ce post, je me posais une question; le modbus desactive la télécommande ... ok.
Mais comment tu fais pour régler le debit de la VMC? Je ne vois aucune commande dans le PDF pour lui indiquer une valeur de fonctionnement...
Il y a bien des commandes pour agir sur le débit qui sont ouvert en écriture, "consigne de débit" par exemple.
Jj'arrive maintenant à lire les informations en utilisant ces paramètres :
ID de la VMC : 1
Baud rate : 19200
Parité : Par (even)
Mode : RTU
8 bits de datas
1 bit de stop
Par contre, j'avoue que niveau écriture et donc modification de la consigne, je n'ai pas encore réussi à le faire ... vous êtes deux personnes à avoir relancer ce sujet cette semaine, ça m'encourage à m'y remettre !
il ne doit pas manquer grand chose.
J'avais pas vu que tu avais mis un deuxième PDF avec d'autre commande R/W...
Perso, je ne communique pas encore avec la VMC, je fais encore bien trop de poussière pour la mettre en prod'...
Ça fonctionne pour la partie "read" mais le "write" ne modifie rien. La vmc ne modifie pas son débit (à l'oreille), et la lecture après l'écriture confirme que la consigne n'a pas été modifiée;
Je n'écris peut être pas au bon endroit. Il faudrait que je recontacte le support pour avoir leur avis.
L'objet retourné par read_holding_registers() est de type ReadHoldingRegistersResponse, qui a comme attributs registers, et non bits (ça, c'est le cas de l'objet retourné par read_coils(), de type ReadCoilsResponse).
autant pour la lecture, les fonctions sont bien différenciées selon ce que l'on veut lire, on a donc bien : read_coils, read_discrete_inputs, read_holding_registers et read_input_registers. Ce que j'arrive bien à comprendre car ça correspond aux différentes sections de la doc pdf de la VMC.
Par contre, pour écrire, on ne retrouve que write_register(s) ou write_coil(s). sniff ...
Pourquoi faire simple quand on peut faire compliqué :/
Je vais chercher des exemples avec mon ami google ...
Ben, que veux-tu de plus ? Seuls les coils et les holdings registers sont accessibles en écriture, dans le protocole Modbus... C'est donc normal que tu aies 4 fonctions pour les lires 4 banques, mais que 2 pour écrire dans les 2 seules banques en RW...
Ben, dans tout ce qui précède, on fait bien dans les 2 directions : on lit/écrit les registres de la vmc via l'interface modbus.
Après, il faut lire/écrire sur le bus KNX. Là, soit tu utilises linknx, soit mon framework python, pKNyX. Si tu pars sur cette dernière solition, tu n'as en fait qu'à écrire un device, et utiliser la librairie modbus pour lire/écrire les registres de la VMC.
Et vu que c'est ce que je compte faire depuis un moment avec ma Helios, si tu patientes un peu, je peux commencer à écrire ça, pour que tu vois comment ça s'articule. La première phase sera de renvoyer les 4 températures de la VMC sur le bus KNX, et de piloter le mode auto/manu plus la vitesse en manu ; tu auras donc les 2 directions.
J'ai trouvé, j'utilisai minimalmodbus qui n'a pas la possibilité d'être modbus RTU slave.
Apparement pymodbus a la fonction server, qui si j'ai bien compris, permet d'utilser le RPI comme esclave sur le protocole modbus.
Sur le modbus RTU il n'y a qu'un maitre, pour vous c'est le RPI, pour moi c'est mon automate.
La communication est toujours initiée par le maitre et l'esclave répond. L'esclave ne fait que répondre au maitre. La communication n'est pas réellement dans les 2 sens.
Pour imager ca, imagine un général et un soldat, c'est toujours le général qui fait des demandes et le soldat répond. Pas l'inverse.
Je vais patienter que tu fasses un bout de programme avec pKNyX. Je l'ai déjà installé sur mon RPI
Ok, je n'avais pas compris que ton "rpi esclave" c'était vis-à-vis de modbus...
Par contre, je n'ai jamais joué avec modbus en esclave... Est-ce que tu pourrais déjà faire quelques tests de ton côté, et me montrer un bout de code de ce que tu veux faire comme dialogue avec ton automate ? Car moi, je suis maître vis-à-vis du modbus, dans ce que je veux faire... Le mode esclave semble un peu plus tricky, et je n'ai pas trop de temps pour m'y plonger...
En fait, je suis plus sûr que ce soit faisable avec pymodbus. J'ai regardé en travers leur site sans trouver d'exemple.
En tout cas, si je dois controler un slave, j'utiliserai minimalmodbus. C'est bien moins compliqué.