Contrôler sa VMC StorkAir / ComfoAir / zehnder via sa domotique

jcoenen

• 1 Avril 2017

• #1 461

OK en ce cas la librairie VMC.py qui se trouve dans le directory de librairie python2.7 n'est pas trouvée par apache, ce qui est possible si le path n'est pas bien définit, or tu as du créer le directory si je me souviens bien.

Pour couper court une solution est de placer la libraire VMC.py dans le /usr/lib/cgi-bin/ le path de recherche des librairies inclus le directory ou se trouve le script.

Copies la librairie dans /usr/lib/cgi-bin

Ensuite vérifies le cgi en l'appelant via un navigateur

http://raspberryIPadresse/cgi-bin/VMCbinjson.cgi

Le résultat doit apparaître dans le navigateur si le cgi est bien exécuté par apache.

Si cela fonctionne, la page HTML devrait fonctionner

Par curiosité peux tu me dire quels sont les directories définis dans
/usr/lib/pymodules/

 

M

Marbaf

• 3 Avril 2017

• #1 462

C'est bon !
Effectivement, j'avais déposé le fichier VMC.pyc dans /usr/lib/modules/python2.7. Étape de l'installation qui ne fonctionnait pas car le dossier python2.7 n'existait pas.
J'ai d'abord copié la librairie dans le dossier /usr/lib/cgi-bin/ : OK
Je l'ai ensuite déplacée dans /usr/lib/python2.7 : OK

La page VMC1.html est maintenant fonctionnelle. Cependant, très vite les boutons deviennent inopérants car les données semblent en recharge constante avec le message "loading actual values" toujours présent.
Quel est le rythme de rafraichissement ? 5 secondes ?
Mais c'est un moindre mal maintenant que le json est disponible via http.

Je vais tenter une réinstallation complète pour pouvoir résumer le tout.

 

jcoenen

• 3 Avril 2017

• #1 463

Super !

Dans chaque fichier html il y a une routine javascript init avec un Timeout (d'après ce que je vois j'ai mis 5 secondes, soit 5000 ms), ci dessous en rouge.

Changes la valeur en un délais qui est raisonnable pour toi (il est clair que si la VMC prend plus que 5 secondes pour répondre alors la page ne rends jamais la main (je ne lis pas la VMC et les events sur la page en même temps).

function init() {
//switching.src=switchimg[swstate];
//clearCanvas();
draw();
var ctx = document.getElementById('canvas').getContext('2d');
var canvas = document.getElementById('canvas');
canvas.addEventListener('mousedown', on_canvas_click, false);
swstate = parseInt(tin[76])-2;
//switching.src=switchimg[swstate];

setTimeout("init()",5000);
//switching.onload = function(){
// ctx.drawImage(switching,0,0);
// }
}

 

Dernière édition: 3 Avril 2017

M

Marbaf

• 4 Avril 2017

• #1 464

Effectivement, 5 secondes c'est beaucoup trop pour mon pi1. Je suis passé à 30, c'est beaucoup mieux.

Par ailleurs j'ai constaté que le process VMCserver.py fait continuellement cartonner le CPU.
Il me semble que quelqu'un avait déjà remonté ce problème mais sans solution pour l'instant, n'est-ce pas ?
Je suppose que c'est du au mode de fonctionnement de cette version 3 qui est continuellement active pour permettre l'intégration à confosense ?

 

jcoenen

• 4 Avril 2017

• #1 465

C'est du au mode de fonctionnement de la boucle de lecture sur les entrées sorties. Le CPU est utilisé a 100 % parcequ'il attend en continu des données sur les entrées (soit la VMC soit les connections des clients).

Cela n'a aucun impact sur les autres process qui prennent le CPU quand ils en ont besoin.

Je devrais peut être écrire une routine de traitement plus sioux pour avoir une meilleure charge de CPU, mais comme ça marche bien et que cela ne ralenti rien ...

 

R

rjcab

• 25 Avril 2017

• #1 466

Bonjour,

Alors je ne sais pas encore ce que j'ai cassé mais je n'ai plus les remontées de la VMC.
je shunt la VMC et relie TX et RX sur mon raspberry et voici les souci

root@VMC:~/raspVMC-master# ./client1.py
connecting to 127.0.0.1 port 12000
requesting data
Traceback (most recent call last):
File "./client1.py", line 90, in <module>
sample(sock)
File "./client1.py", line 47, in sample
rcvd = VMC(hexframe)
File "/root/raspVMC-master/VMC.py", line 50, in __init__
self.Payload() #extract the payload when checksum OK
File "/root/raspVMC-master/VMC.py", line 119, in Payload
self.payload=binascii.a2b_hex(result.group(3))
AttributeError: 'NoneType' object has no attribute 'group'

Les logs semblent pas mal.

25/04/17 22:52:54 : received 07f0000b00b8070f ('127.0.0.1', 44042) from client ('127.0.0.1', 44042) retained is 07f0000b00b8070f
25/04/17 22:52:54 : Processing msg from queue ('127.0.0.1', 44042)
25/04/17 22:52:54 : Sending frame 07f0000b00b8070f to VMC from Client ('127.0.0.1', 44042)
25/04/17 22:52:54 : Command code: 0b reply is True
25/04/17 22:52:54 : expecting a reply
25/04/17 22:52:54 : received from VMC 07f0000b00b8070f
25/04/17 22:52:54 : 8 frames received from VMC only one is expected from theread
25/04/17 22:52:54 : frame received from VMC stored in client queue 07f0000b00b8070f
25/04/17 22:52:54 : sending 07f0000b00b8070f to ('127.0.0.1', 44042)
25/04/17 22:52:54 : closing ('127.0.0.1', 44042) after reading no data
root@VMC:/var/log#

Je ssuis preneur de toutes idées

 

jcoenen

• 26 Avril 2017

• #1 467

Bonjour !
Effectivement le serveur semble bien fonctionner (le cross entre Tx et Rx se voit bien les trame sortantes reviennent sur l'entrée). A noter que de cette manière (bouclage sur Rx et Tx) les clients ne peuvent fonctionner correctement, il est donc normal qu'ils se plantent.

Question: le client se plante lorqsue la VMC est connectée ?

Si oui, quel sont les messages échangés a ce moment là ?

Explication des message du crash

D'après les messages du client (plantage), il semble que le message dans la trame d'entrée ne contient pas le format
attendu.

RFrame = re.compile(b'(.{4})(.{2})(.+)(.{2})') extraction des groupes de bytes du message
result = RFrame.search(binascii.hexlify(self.frame))
self.payload=binascii.a2b_hex(result.group(3)) seul le troisième groupe nous intéresse.

Et si le group 3 n'est pas troucé par le search alors BOUM.

 

R

rjcab

• 27 Avril 2017

• #1 468

Hello,

J'ai remis avec la VMC et la peut etre pb de bruit sur la ligne ?

root@VMC:~/raspVMC-master# ./client3.py
connecting to 127.0.0.1 port 12000
requesting data 0
^CTraceback (most recent call last):
File "./client3.py", line 46, in <module>
rcvd=VMC().getAll(sock)
File "/root/raspVMC-master/VMC.py", line 327, in getAll
self.getdevinfo(socket)
File "/root/raspVMC-master/VMC.py", line 316, in getdevinfo
self.GetResp(b'\x69',socket)
File "/root/raspVMC-master/VMC.py", line 265, in GetResp
data = socket.recv(64)
KeyboardInterrupt
root@VMC:~/raspVMC-master# tail /var/logVMClog.log
tail: cannot open `/var/logVMClog.log' for reading: No such file or directory
root@VMC:~/raspVMC-master# tail /var/log/VMClog.log
25/04/17 22:58:42 : closing ('127.0.0.1', 44045) after reading no data
27/04/17 20:54:57 : new client connection from ('127.0.0.1', 44258)
27/04/17 20:54:57 : received 07f000690016070f ('127.0.0.1', 44258) from client ('127.0.0.1', 44258) retained is 07f000690016070f
27/04/17 20:54:57 : Processing msg from queue ('127.0.0.1', 44258)
27/04/17 20:54:57 : Sending frame 07f000690016070f to VMC from Client ('127.0.0.1', 44258)
27/04/17 20:54:57 : Command code: 69 reply is True
27/04/17 20:54:57 : expecting a reply
27/04/17 20:54:57 : received from VMC 07f3
27/04/17 20:54:57 : No frame detected in 07f3
27/04/17 20:55:11 : closing ('127.0.0.1', 44258) after reading no data
root@VMC:~/raspVMC-master#

 

jcoenen

• 28 Avril 2017

• #1 469

Possible, regardes si la connection de la masse est bonne. Le débug est sur 8 ?

 

D

duboys45

• 11 Mai 2017

• #1 470

Bonjour,
Merci beaucoup pour tout ce forum,j'ai relu les 74 pages et sa y est j'arrive à gérer ma comfoair 200 sur mon pine64.
mais j'ai le message d'erreur ci-dessous :

error rocessing for frame e6not yet impelemented

malgré plusieurs recherche je ne trouve pas d'ou cela vient
une idée ?
merci

 

jcoenen

• 11 Mai 2017

• #1 471

Bonsoir, ce message est du à la réception d'une trame avec un code de contenu qui n'est pas traité par le logiciel, je vais voir dans le protocole à quoi le code correspond ...

 

D

duboys45

• 12 Mai 2017

• #1 472

Merci de te réponse, pour le coup j'avais imaginer cette piste mais j'ai jamais remis la main sur le post avec le protocole car j'ai un autre message de ce genre

Et du coup le résultat est mal parsé, je veux bien faire le taf d'ajouter les trames non connu au code.

 

jcoenen

• 12 Mai 2017

• #1 473

E6
Kommando:

0x00 0xE5

RF Status abrufen

Daten:

-

Antwort:

0x00 0xE6

Daten:

Byte[1] Byte[2] Byte[3] Byte[4] Byte[5] Byte[6] Byte[7]

RF Adresse 4 RF Adresse 3 RF Adresse 2 RF Adresse 1 RF id

C'est la demande de l'état de la commande Radio.

Ce qui est curieux c'est que le logiciel n'est pas sensé envoyer la commande E5 qui génère la trame E6, et que d'après ce que je sais la VMC n'envoie pas de trames non sollicitées, donc quelque part elle reçoit une trame E5 et y répond ...

Il me semblait avoir retiré les trame non traitées de la chaine de réception, mais bon je peux me tromper.

Je vais refaire un petit tour du propriétaire ce WE ...

As tu un autre appareil connecté sur la VMC ?

 

D

duboys45

• 12 Mai 2017

• #1 474

Voici le détail de mon installation :

J'ai une COMFOAIR 200 avec un boitier Comfsense (67) ( c'est plus WAF et je ne savais pas encore que je ferais de la domotique)

c'est raccordé avec le kit d'adapatation COMFOAIR "luxe"

Mon Port RS232 est sur la carte CONFOAIR et mon COMFOSENSE raccorder au bornier.

Pour les photos :
https://Pas-de-liens-raccourcis-svp/photos/MoHaDb4DuYLZcH7N6

 

Dernière édition: 12 Mai 2017

jcoenen

• 12 Mai 2017

• #1 475

OK je comprend mieux, dans ce cas là, le comfosense envoie des messages vers la VMC (et ce en continu !), la VMC répond et les info sont aussi renvoyées vers le serveur du pine64. Le logiciel reçoit alors des trames qu'il n'a pas demandé et KraK boum, messages d'erreurs, car ces trames ne devraient pas être présente sur le bus.

Normalement le comfosense ne peut être raccordé en parallèle avec le serveur (RS232 = Série = point to point !), celui ci doit être raccordé VIA le serveur a travers un autre adaptateur série (soit sur le pine64 soit ailleurs sur le réseau), plusieurs utilisateurs du forum ont déjà réalisé la chose et cela semble bien fonctionner (en tout cas chez moi ça tourne depuis 1 an), en tout cas personne ne semble se plaindre

 

D

duboys45

• 12 Mai 2017

• #1 476

Merci, cela me paraît clair. Un petit bricolage en perspective.

 

jcoenen

• 12 Mai 2017

• #1 477

Oui il faut alimenter le comfosense séparément du rs232 c'est pas compliqué, ensuite définir un process socat qui branchera le comfosense sur le serveur via le convertisseur série

 

A

autix

• 17 Mai 2017

• #1 478

Bonjour et félicitations pour le travail accompli.

Je me suis enfin décidé a mettre en place la gestion de ma VMC Zehnder ComfoD 350. Avant de me lancer dans la partie logicielle j'ai voulu vérifié la partie matérielle.

J'ai commencé par me connecter a la VMC en utilisant Windows 10, un convertisseur USB/RS232 basé sur le chipset CH340 et un cable RJ45 fait maison (environ 2 a 3 m de long). En utilisant le logiciel Termite si je demande le status avec la commande (0x07 0xF0 0x00 0x0F 0x00 0xBC 0x07 0x0F) je récupère bien les températures des sondes et les autres infos.

J'ai ensuite branché le convertisseur sur mon Raspberry Pi 3 sous Raspbian Jessie qui est mon serveur domotique. Et la impossible de parler avec la VMC sur le port série. Apres quelques recherches il semble que le driver linux pour ce chipset soit pas super fiable.

Vu le prix des convertisseurs j'ai décidé d'en acheté un autre utilisant un autre chipset, le PL2303HX. Et la que ce soit sous Windows ou Raspbian je reçois un flot de zéros en continu sans même envoyer de commande et l'envoi de commande ne retourne rien.

Me disant que le convertisseur était peut être foutu j'en ai commandé un autre utilisant encore un autre chipset, le CP2102. Et la c'est le même comportement: je reçois un flot de zéros en continu sans même envoyer de commande et l'envoi de commande ne retourne rien.

J'ai beau cherché je vois d'ou peut venir le problème. Le câblage est bon puisque j'arrive a parler avec la VMC dans une des configurations. Quelqu'un aurait une idée?

Merci

 

jcoenen

• 18 Mai 2017

• #1 479

Au vu des symptômes je pencherai pour un problème de connexion de la masse (pin 5 du connecteur db9), ce qui induit des niveaux incohérents sur le bus (cela m'est arrivé et m'a couté quelques cheveux).

Les PL2303 et 2102 sont bien reconnu par les drivers Debian, et n'ayant jamais eut de problèmes de ce côté là ...

Pour vérifier la compatibilité des convertisseur court circuiter les pin TX et RX (2 et 3 DB9) et voir si les caractères envoyés reviennent bien (via termite).

 

A

autix

• 18 Mai 2017

• #1 480

Merci pour la suggestion. J'ai ponté le câble au niveau de la VMC (au bout des 3m de fil) et j'ai bien l’écho qui revient parfaitement dans Termite.

En continuant mes recherches je me suis rendu compte que mes deux nouveaux convertisseurs sont marqués comme USB vers RS232 TTL. J'avais pas fait attention a ce TTL qui pour moi voulait dire Time to Live. Et puis je suis tombé sur cet article: https://www.sparkfun.com/tutorials/215 et je me suis rendu compte que TTL voulait dire transistor-transistor logic dans ce contexte. Ce dernier étant un autre protocole série utilisant une autre plage de tension pour coder le 0 et le 1 ce qui peut expliquer pourquoi je reçois un flot de 0 comme la tension est interprétée différemment. Voila comment perdre quelques heures avec une description produit erronée puisque ces deux convertisseurs ne sont pas RS232 mais seulement TTL.

En attente d'un quatrième convertisseur basé sur le chipset CP2102 qui je l’espère sera vraiment RS232