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

rjcab · 28 Juillet 2017

Je n'arrive pas à comprendre pourquoi j'ai une erreur dans ce cas alors que avec la liaison sur le convertisseur pas de pb hormis les trames qui ne sont pas bonnes.

jcoenen · 28 Juillet 2017

Je viens de pensez à un truc, sur whezzy je pense me souvenir qu'il faut aussi changer /etc/inittab je jette un œil sur la doc que j'ai écrit sur le sujet et reviens vers toi

jcoenen · 28 Juillet 2017

Bon sur sourceforge RaspiVMC il y a la doc sur l'installation du ttyAMA0 (dans files: RASPIVMC.pdf)

Copié collé:

sudo nano /boot/cmdline.txt
la première doit être
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

les références a l’utilisation du device AMA0 doivent être enlevées: soit enlever
“console=ttyAMA0,115200 kgdboc=ttyAMA0,115200”

Modifier le fichier /etc/inittab

sudo nano /etc/inittab Modifier la ligne

T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100 en

#T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

Un reboot s’impose pour redémarrer le systèmes sans les process attachés au device AMA0

Je pense que ton problème se situe au niveau de inittab qui lance un process qui intercepte le traffic sur le port série du GPIO (deux programmes sur le même port série, pas bon ça), et c'est pareil avec le convertisseur connecté même si les symptômes ne sont pas identiques.

Modifies inittab comme indiqué et réessayes avec le convertisseur, cela devrait fonctionner mieux.
pin 2 et 3 connectées, et vérifies que les trames sortante reviennent bien, ceci valide le convertisseur.
Ensuite connectes la VMC et vérifie que la communication est établie avec un client.

rjcab · 28 Juillet 2017

mhmhm

C'est déja le cas pour :

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

les références a l’utilisation du device AMA0 doivent être enlevées: soit enlever
“console=ttyAMA0,115200 kgdboc=ttyAMA0,115200”

C'est déja le cas aussi pour :

Modifier le fichier /etc/inittab

sudo nano /etc/inittab Modifier la ligne

T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100 en

#T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

jcoenen · 28 Juillet 2017

ps -ef | grep ttyAMA0 histoire de voir si un autre process utilise le GPIO (mais cela m'étonnerais)

rjcab · 29 Juillet 2017

De ce coté cela a l'air propre:

Code:

Last login: Fri Jul 28 17:13:13 2017 from macmini.local
pi@raspberrypi ~ $ ps -ef | grep ttyAMA0
pi        5067  5052  0 06:51 pts/0    00:00:00 grep --color=auto ttyAMA0
pi@raspberrypi ~ $ ps -ef | grep server
root      2405     1 99 Jul26 ?        2-12:54:06 /usr/bin/python /home/pi/raspVMC-master/server.py
pi        5069  5052  0 06:51 pts/0    00:00:00 grep --color=auto server
pi@raspberrypi ~ $

jcoenen · 29 Juillet 2017

Bon, a priori seul le server.py semble attaché (Wheezy en défaut connecte un tty sur le port mais ce n'est plus le cas (inittab modifié)).

Je ne vois qu'un problème au niveau hardware ou du raccordement qui pourrait être la cause du mal-fonctionnement.

Pour éliminer toute influence et investiguer le HW et la connexion, arrêter le serveur, pour cela, mettre en commentaire la ligne du serveur dans inittab et sudo init q
Vérifier que server est inactif (pf -ef | grep ...)
Quand cela arrive j'utilise un logiciel de terminal (minicom, screen, putty, kermit ...) pour tester le HW en branchant le TX et le RX (attention que sur le GPIO TX = 4 et RX = 5). Et ensuite rajouter les éléments un par un.

Malheureusement je ne peux pas faire plus sans être en contact physique avec l'appareillage.

rjcab · 30 Juillet 2017

Hello,

J'ai désactivé ceci

Code:

#vm:2345:respawn:/home/pi/raspVMC-master/server.py >>/var/log/VMCerr.log 2>&1

Code:

pi@raspberrypi ~ $ ps -ef | grep server
pi        6491  6471  0 18:44 pts/0    00:00:00 grep --color=auto server
pi@raspberrypi ~ $

PLus de server.py a tourner.
Bon je vais essayer avec un autre raspberry

rjcab · 30 Juillet 2017

alors avec un autre raspberry directement tx et rx relié sur le gpio

Code:

pi@raspberrypi ~/raspVMC-master $ tail /var/log/VMClog.log
error: <class 'ConfigParser.NoSectionError'>
30/07/17 19:11:53 : new client connection from ('127.0.0.1', 56078)
30/07/17 19:11:53 : received 07f0000b00b8070f ('127.0.0.1', 56078)  from client ('127.0.0.1', 56078)  retained is  07f0000b00b8070f
30/07/17 19:11:53 : Processing msg from queue  ('127.0.0.1', 56078)
30/07/17 19:11:53 : Sending frame  07f0000b00b8070f  to VMC from Client  ('127.0.0.1', 56078)
30/07/17 19:11:53 : Command code:  0b  reply is  True
30/07/17 19:11:53 : expecting a reply
30/07/17 19:11:54 : received from VMC  556e636f6d7072657373696e67204c690700f0000b00b8070f
30/07/17 19:11:54 : No frame detected in  556e636f6d7072657373696e67204c690700f0000b00b8070f
30/07/17 19:12:07 : closing ('127.0.0.1', 56078) after reading no data
pi@raspberrypi ~/raspVMC-master $

better ..

jcoenen · 31 Juillet 2017

Pas vraiment, la trame de envoyée sur le TX
07f0000b00b8070f

et ce qui revient par le RX

556e636f6d7072657373696e67204c690700f0000b00b8070f

Il semblerait que des données parasites arrivent sur la ligne on voit bien le 00 supplémentaire dans la trame ce qui n'est pas du tout normal si rien n'est connecté au niveau logiciel.

En regardant les code ascii correspodant à "556e636f6d7072657373696e67204c69", one trouve la chaîne de caractère "Uncompressing Li" ce qui est un des message envoyé par le kernel sur la console. Donc la console est toujours branchée sur ttyAMA0 et donc les messages de la console et de la VMC se mélangent.

Sur wheezy la chose est règlée par inttab sur jessie c'est via systemd. Il y a cependant moyen d'utiliser raspi-config pour enlver la redirection de la console (voir içi)

Wheezy raspi-config -> option avancée -> serial -> no

Jessie sudo raspi-config -> interfacing option -> P6 Serial

rjcab · 3 Août 2017

Bonjour JC,

J'ai fait ceci mais tjs la meme chose.

Wheezy raspi-config -> option avancée -> serial -> no

Si tu peux je peux te donner les accès en MP si tu veux regarder de plus près

Merci

jcoenen · 3 Août 2017

Ah bon, c'est très curieux, OK donnes moi un accès ssh que je puisse jeter un oeil en direct.

jcoenen · 3 Août 2017

Bon, je viens de faire une petite recherche sur la toile, le problème, Linu boot sur un noyau comprimé et doit donc le décomprimer, le bootstrap envoit donc le message sur la console "Ucompressing Linux" avant que celle ci ne soit déshabilitée (Voir içi), la solution serait de démarrer avec un noyau décompressé ...

D'un autre côté seule la première demande au serveur sera impactée car une fois la trame supious lue, il n'y en aura plus d'autre pour mettre le beans.

De ce côté là le ttyAMA0 est vérifié, il fonctionne correctement.

Peux tu maintenant brancher le convertisseur tty/RS232 avec les pin 2 et 3 connectées (sans la VMC donc), vérifions ce dernier.

rjcab · 3 Août 2017

Merci JC. Je fais ceci dès que je rentre

rjcab · 3 Août 2017

Alors VMC rebranchée:

Code:

03/08/17 10:38:51 : Processing msg from queue  ('127.0.0.1', 44758)
03/08/17 10:38:51 : Sending frame  07f0000b00b8070f  to VMC from Client  ('127.0.0.1', 44758)
03/08/17 10:38:51 : Command code:  0b  reply is  True
03/08/17 10:38:51 : expecting a reply
03/08/17 10:38:52 : received from VMC  00fffe0f00
03/08/17 10:38:52 : No frame detected in  00fffe0f00
03/08/17 10:39:03 : closing ('127.0.0.1', 44758) after reading no data
03/08/17 10:39:26 : new client connection from ('127.0.0.1', 44759)
03/08/17 10:39:26 : received 07f0000b00b8070f ('127.0.0.1', 44759)  from client ('127.0.0.1', 44759)  retained is  07f0000b00b8070f
03/08/17 10:39:26 : Processing msg from queue  ('127.0.0.1', 44759)
03/08/17 10:39:26 : Sending frame  07f0000b00b8070f  to VMC from Client  ('127.0.0.1', 44759)
03/08/17 10:39:26 : Command code:  0b  reply is  True
03/08/17 10:39:26 : expecting a reply
03/08/17 10:39:26 : received from VMC 
03/08/17 10:39:26 : No frame detected in 
03/08/17 10:39:36 : closing ('127.0.0.1', 44759) after reading no data
03/08/17 10:39:51 : new client connection from ('127.0.0.1', 44760)
03/08/17 10:39:51 : received 07f0000b00b8070f ('127.0.0.1', 44760)  from client ('127.0.0.1', 44760)  retained is  07f0000b00b8070f

Ce que je ne comprends pas c'est que je lance Client1 la VMC rend des données.
Je fais CTRL + C puis je relance Client1 mais la rien

jcoenen · 3 Août 2017

D'après le log je pense que 2 et 3 sont connectés

la trame
03/08/17 10:38:52 : No frame detected in 00fffe0f00

Ne correspond pas a une réponse correcte, celle ci doit impérativement être

du genre 07f0xxxxxxxx070f,
quant a dire d'où cette trame vient ???

par contre après la trame envoyée par le client est bien revenue.

03/08/17 10:38:51 : Sending frame 07f0000b00b8070f to VMC from Client ('127.0.0.1', 44758)
03/08/17 10:39:26 : received 07f0000b00b8070f

Celle ci est renvoyée au client qui crash car ce n'est pas une trame de réponse mais une trame de commande (c'est donc normal car cela ne peux pas arriver en condition normale).

On sait donc que le GPIO fontionne bien (la première trame liée au "Uncompression Linux" n'empèche pas le système de fonctionner), maintenant au tour du convertisseur de niveau qui semble avoir quelques problèmes au vu des trames qui reviennent.

Je viens de me logger, il n'y a pas de retour TX/RX les pins sont déconnectées ?

rjcab · 3 Août 2017

Ils ont sur la VMC mais cela n'a pas l'air de fonctionner
Je vais les relier en ensemble au niveau du convertisseur sur le port serie

jcoenen · 3 Août 2017

OK, je suis connecté jusque 19:00 ensuite je reprend la route vers la Belgique (suis aux Pays-Bas pour l'instant).

rjcab · 3 Août 2017

Les pattes sont reliées.
Bonne route

jcoenen · 3 Août 2017

OK c'est tout bon, les trames reviennent correctment (enfin les 4 que j'ai envoyées.

Pourrais tu rebrancher les pin 2 et 3 sur la VMC (et la masse aussi !) comme cela ne fonctionnait pas avant inverse 2 et 3.

03/08/17 16:52:40 : Sending frame 07f000690016070f to VMC from Client ('127.0.0.1', 37835)
03/08/17 16:52:40 : Command code: 69 reply is True
03/08/17 16:52:40 : expecting a reply
03/08/17 16:52:40 : received from VMC 07f307f000690016070f
03/08/17 16:52:40 : 8 frames received from VMC only one is expected from theread
03/08/17 16:52:40 : frame received from VMC stored in client queue 07f000690016070f
03/08/17 16:52:40 : sending 07f000690016070f to ('127.0.0.1', 37835)
03/08/17 16:52:40 : closing ('127.0.0.1', 37835) after reading no data
03/08/17 16:53:15 : new client connection from ('127.0.0.1', 37836)
03/08/17 16:53:15 : received 07f0000b00b8070f ('127.0.0.1', 37836) from client ('127.0.0.1', 37836) retained is 07f0000b00b8070f
03/08/17 16:53:15 : Processing msg from queue ('127.0.0.1', 37836)
03/08/17 16:53:15 : Sending frame 07f0000b00b8070f to VMC from Client ('127.0.0.1', 37836)
03/08/17 16:53:15 : Command code: 0b reply is True
03/08/17 16:53:15 : expecting a reply
03/08/17 16:53:15 : received from VMC 07f307f0000b00b8070f
03/08/17 16:53:15 : 8 frames received from VMC only one is expected from theread
03/08/17 16:53:15 : frame received from VMC stored in client queue 07f0000b00b8070f
03/08/17 16:53:15 : sending 07f0000b00b8070f to ('127.0.0.1', 37836)
03/08/17 16:53:15 : closing ('127.0.0.1', 37836) after reading no data

Rechercher

Rechercher

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

rjcab

jcoenen

jcoenen

rjcab

jcoenen

rjcab

jcoenen

rjcab

rjcab

jcoenen

rjcab

jcoenen

jcoenen

rjcab

rjcab

jcoenen

rjcab

jcoenen

rjcab

jcoenen

Sujet semblables

Nos articles

On a aimé dans le forum