telemetry
Quoi de neuf

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

  • Forum Electricité - Domotique
  • Auteur du sujet Auteur du sujet sebcbien
  • Date de début Date de début
  • #1 402
Hello et Happy New Year EveryOne :)

Je persévère mais je galère toujours :
J'ai acheté un nouveau module TTL RS232 que j'ai branché direct sur le GPIO de mon PI et courcicuité les pattes 2 et 3 de la prise RS232:

Log:
04/01/17 21:06:27 : new client connection from ('127.0.0.1', 44319)
04/01/17 21:06:27 : received 07f0000b00b8070f ('127.0.0.1', 44319) from client ('127.0.0.1', 44319) retained is 07f0000b00b8070f
04/01/17 21:06:28 : Processing msg from queue ('127.0.0.1', 44319)
04/01/17 21:06:28 : Sending frame 07f0000b00b8070f to VMC from Client ('127.0.0.1', 44319)
04/01/17 21:06:28 : Command code: 0b reply is True
04/01/17 21:06:28 : expecting a reply
04/01/17 21:06:28 : received from VMC 300a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a4e6967687441657261206c6f67696e3a20526173706269616e20474e552f4c696e75782037204e696768744165726120747479414d41300a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a4e6967687441657261206c6f67696e3a20526173706269616e20474e552f4c696e75782037204e696768744165726120747479414d41300a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a
04/01/17 21:06:28 : No frame detected in 300a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a4e6967687441657261206c6f67696e3a20526173706269616e20474e552f4c696e75782037204e696768744165726120747479414d41300a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a4e6967687441657261206c6f67696e3a20526173706269616e20474e552f4c696e75782037204e696768744165726120747479414d41300a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a
04/01/17 21:06:38 : closing ('127.0.0.1', 44319) after reading no data

Donc je pense que c'est mieux. Pour être sur de mon install sous linux, je suis pas très bon je souhaite tester différentes commandes mais je ne sais pas comment faire:

Coté URL j'obtiens rien lorsque je tappe l'ip de mon IP meme avec le port 10000 derriere. Je tente le VMC.pl mais je ne sais pas ou est ce fichier ?
En bref comment tester mon install un peu plus profondéement que avec le fichier de log.

Merci
 
  • #1 403
Bonsoir et bonne année,

Donc tu as ponté 2 et 3 au RS232, les messages envoyés doivent revenir au serveur.

Le client se connecte
04/01/17 21:06:27 : new client connection from ('127.0.0.1', 44319)
Le client envoie une frame 07f0000b00b8070f au serveur
04/01/17 21:06:27 : received 07f0000b00b8070f ('127.0.0.1', 44319) from client ('127.0.0.1', 44319) retained is 07f0000b00b8070f
04/01/17 21:06:28 : Processing msg from queue ('127.0.0.1', 44319)
Le serveur envoie la frame du client à la VMC
04/01/17 21:06:28 : Sending frame 07f0000b00b8070f to VMC from Client ('127.0.0.1', 44319)
04/01/17 21:06:28 : Command code: 0b reply is True
Le serveur attend la réponse de la VMC
04/01/17 21:06:28 : expecting a reply
Réponse de la VMC pas très correcte
04/01/17 21:06:28 : received from VMC 300a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a


D'après ce que je vois beaucoup de line feed (0a), as tu enlevé la console du GPIO ?


Dans le fichier /boot/cmdline.txt

il faut absolument enlever console=serial0,115200
et faire un reboot

Ces commandes redirigent les message de la console sur le port série, et donc interfèrent avec le traffic VMC.

Côté URL ne pas aller sur le port 10000 c'est le port utilisé par les clients pour causer au serveur en hexadécimal ...

Dans le directory ou se trouve l'installation (raspVMC-master), les clients sont client1.py client2.py client3.py

VMC.pl était le tout premier essai de communication ... plus vraiment d'actualité (ni distribué ... RIP )

Dans le log je ne vois pas le message reçu du client revenir, mais comme le canal est pollué par ce bruit que je soupçonne venir de la console ... d'abord occupons nous de ce bruit, une chose à la fois.
 
  • #1 404
BINGO,

En convertissant les code ascii que tu reçoit

4e6967687441657261206c6f67696e3a20526173706269616e 20474e552f4c696e75782037204e6967687441657261207474 79414d41

j'obtiens

NightAera login: Raspbian GNU/Linux 7 NightAera ttyAMA0

Ce qui semble bien être du texte pour la console.
 
  • #1 405
Bonjour jcoenen,

Merci pour ta réactivité.
Si je comprends bien voici ce que je dois faire:

- enlever console=serial0,115200
- faire un reboot
- Lancer un des clients client1.py client2.py client3.py (après avoir lancer le serveur)

mais une fois que j'ai lancé le client que faire pour voir si cela fonctionne ?

D'après ce que je vois beaucoup de line feed (0a), as tu enlevé la console du GPIO ?
Non rien.

Je n'ai pas bien compris:
En convertissant les code ascii que tu reçoit

4e6967687441657261206c6f67696e3a20526173706269616e 20474e552f4c696e75782037204e6967687441657261207474 79414d41

Que faut il en déduire ?

Merci
 
  • #1 406
rjcab;1186271 a dit:
Bonjour jcoenen,

Merci pour ta réactivité.
Si je comprends bien voici ce que je dois faire:

- enlever console=serial0,115200
- faire un reboot
- Lancer un des clients client1.py client2.py client3.py (après avoir lancer le serveur)


rjcab;1186271 a dit:
mais une fois que j'ai lancé le client que faire pour voir si cela fonctionne ?

Tu lance le serveur et ensuite un des clients.

Si 2 et 3 sont connectés, les message envoyé par le client doivent revenir sur le serveur (voir dans le log)

Si le port série est connecté à la VMC correctement, le client affichera les valeurs lues à la VMC (sinon rien).

rjcab;1186271 a dit:
Que faut il en déduire ?

Merci
Que c'est bien la console qui est configurée sur le port série du Pi.
 
  • #1 407
Hello,

De retour a la maison voici ce que j'ai tout en gardant ma boucle sur TX RX:

root@NightAera:~# tail /boot/cmdline.txt
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
root@NightAera:~# cd raspVMC-master/
root@NightAera:~/raspVMC-master# ./server.py &
[1] 2556
root@NightAera:~/raspVMC-master# ./client1.py
connecting to 127.0.0.1 port 11000
requesting data

rien ne se passe après requesting data :(
 
  • #1 408
C'est normal, un port série à deux canaux, un pour émettre l'autre pour recevoir.

Le raspberry envoie la trame de commande sur la pin TX et la VMC la trame de réponse sur la pin RX

Si tu boucle RX et TX et regarde dans le log (avec début 8) les trames envoyées par le client doivent réapparaître comme si elle venaient de la VMC, ce qui permet uniquement de vérifier que le convertisseur TTL/RS232 fonctionne bien.

Comme la réponse de la VMC est une trame de commande (et pas une trame de réponse) le client ne te donnera pas de résultat.

Une fois ceci établi, il ne reste plus qu'a connecter la VMC et relancer le client, si les pin sont bien raccordées alors tu devrais voir les réponses de la VMC.


D'après ton fichier le texte a enlever est

console=ttyAMA0,115200
 
  • #1 409
Merci pour les explications.
J'ai donc enlever la ligne + rebooté + branché la vmc.

Je dois avoir un pb de cablage car j'ai ceci:

root@NightAera:~/raspVMC-master# ./client1.py
connecting to 127.0.0.1 port 11000
requesting data
Traceback (most recent call last):
File "./server.py", line 418, in <module>
next_msg = response(Sport)
File "./server.py", line 76, in response
bread = Sport.read(256);
File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 456, in read
raise SerialException('device reports readiness to read but returned no data (device disconnected?)')
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected?)
Traceback (most recent call last):
File "./client1.py", line 90, in <module>
sample(sock)
File "./client1.py", line 31, in sample
sock.sendall(frame.FullFrame())
File "/usr/lib/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
socket.error: [Errno 32] Broken pipe
[1]+ Exit 1 ./server.py

je vais vérifier.
 
  • #1 410
Peux tu poster le VMC.ini ?

Le port ne semble pas "opérationnel" ce qui est très curieux ce device est toujours disponible.

Regardes ce que donne

ls -l /dev/ttyAMA0

???
 
Dernière édition par un modérateur:
  • #1 411
Hello,

VMC.ini dans le rep raspVMC
root@NightAera:~/raspVMC-master# vi VMC.ini

[VMC]
device = /dev/ttyAMA0

[server]
bind =
port = 11000

[control]
port = 11002

[client]
server = 127.0.0.1

[socat]
pty = /tmp/ttyVMC

[debug]
log = /var/log/VMClog.log
level = 8

root@NightAera:~# ls -l /dev/ttyAMA0
crw-rw---- 1 root tty 204, 64 Jan 5 21:24 /dev/ttyAMA0
 
  • #1 412
Peux tu faire un

ps -ef | grep tty

et me donner ce qui revient, merci.
 
  • #1 413
Hello,

Résultat de la commande :

root@NightAera:~/raspVMC-master# ps -ef | grep tty
root 2380 1 0 21:08 tty1 00:00:00 /sbin/getty --noclear 38400 tty1
root 2381 1 0 21:08 tty2 00:00:00 /sbin/getty 38400 tty2
root 2383 1 0 21:08 tty3 00:00:00 /sbin/getty 38400 tty3
root 2384 1 0 21:08 tty4 00:00:00 /sbin/getty 38400 tty4
root 2385 1 0 21:08 tty5 00:00:00 /sbin/getty 38400 tty5
root 2386 1 0 21:08 tty6 00:00:00 /sbin/getty 38400 tty6
root 2387 1 0 21:08 ttyAMA0 00:00:00 /sbin/getty -L ttyAMA0 115200 vt100
root 2605 2537 0 21:08 pts/0 00:00:00 grep tty
root@NightAera:~/raspVMC-master#
 
  • #1 414
rjcab;1186750 a dit:
Hello,

Résultat de la commande :


J'ai comprendu !

Je suppose que tu utilises Jessie, qui n'utilise pas inittab et donc lance un getty sur AMA0 via systemd.

Pour éliminer le bidule il faut donc effectuer les commandes suivantes

Pour zigouiller getty sur ttyAMA0
sudo systemctl stop serial-getty@ttyAMA0.service

Et pour enlever l'autostart du machin au boot


sudo systemctl disable serial-getty@ttyAMA0.service

Cela devrait enlever le programme getty qui perturbe la comm de la VMC.
 
Dernière édition par un modérateur:
  • #1 415
Bonjour et bonne Année.
Avec le froid revient mon questionnement sans réponse de l'hiver dernier.
Comment marche cette batterie anti gel ?
Bizarrerie 1: Tneuf augmente, Textrait aussi mais rien sur Soufflée.
=> dans ce cas on voit bien le mode impulsion. Quelques minutes de chauffage puis un stop plus long.
Bizarrerie 2: Tneuf bien supérieur à Text, Tsoufflée élevé aussi
=> ok oui mais l'indicateur anti gel reste à 0 et la VMC semble se contrefoutre que la Text soit remonté et qu'il fasse par exemple 3°C dehors.
=> cette bizarrerie semble survenir quand je suis en mode absence.
Merci
 
Dernière édition par un modérateur:
  • #1 416
SpigoloN;1187452 a dit:
Bonjour et bonne Année.
Avec le froid revient mon questionnement sans réponse de l'hiver dernier.
Comment marche cette batterie anti gel ?
Bizarrerie 1: Tneuf augmente, Textrait aussi mais rien sur Soufflée.
=> dans ce cas on voit bien le mode impulsion. Quelques minutes de chauffage puis un stop plus long.
Bizarrerie 2: Tneuf bien supérieur à Text, Tsoufflée élevé aussi
=> ok oui mais l'indicateur anti gel reste à 0 et la VMC semble se contrefoutre que la Text soit remonté et qu'il fasse par exemple 3°C dehors.
=> cette bizarrerie semble survenir quand je suis en mode absence.
Merci

Malheureusement je n'ai pas les algorithmes du fonctionnement de l'anti gel et ne peux éclairer ta lanterne sur ce point.

Par contre je viens d'aller jeter un coup d'oeil dans le code et horreur, les messages concernant le préchauffage ne sont pas traités ... donc donc ...

Va falloir mettre un terme a cette anomalie ...
 
  • #1 417
Hello,

Je ne suis pas très doué coté linux ni coté RaspiVMC il faut dire :-)

root@NightAera:/sbin# sysctl stop getty@ttyAMA0.service
sysctl: cannot stat /proc/sys/stop: No such file or directory
sysctl: cannot stat /proc/sys/getty@ttyAMA0/service: No such file or directory
root@NightAera:/sbin# sysctl stop getty
sysctl: cannot stat /proc/sys/stop: No such file or directory
sysctl: cannot stat /proc/sys/getty: No such file or directory
root@NightAera:/sbin# kill getty
-bash: kill: getty: arguments must be process or job IDs
root@NightAera:/sbin# ps
PID TTY TIME CMD
2523 pts/0 00:00:01 bash
12874 pts/0 00:00:00 ps
root@NightAera:/sbin# sysctl stop getty@ttyAMA0.service
sysctl: cannot stat /proc/sys/stop: No such file or directory
sysctl: cannot stat /proc/sys/getty@ttyAMA0/service: No such file or directory
root@NightAera:/sbin# cd /
root@NightAera:/# find -name *AMA0*
./dev/ttyAMA0
./sys/devices/platform/soc/3f201000.uart/tty/ttyAMA0
./sys/class/tty/ttyAMA0
root@NightAera:/# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 7.9 (wheezy)
Release: 7.9
Codename: wheezy
root@NightAera:/#
 
  • #1 418
Au fait quelle installation linux utilises tu sur ton raspberry ?

Car cela n'a pas l'air d'être une raspbian (Debian, Wheezy ou Jessie)
 
  • #1 420
ok je vais voir comment ils configurent leur tty car cela ne semble pas habituel
 

Sujet semblables

Réponses
10
Affichages
988
Nudji
Réponses
·
Affichages
169
Maka
Réponses
4
Affichages
390
Tchotto
Réponses
6
Affichages
1K
ironglove

Nos articles

On a aimé dans le forum

Retour
Haut