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

Je suppose créer un programme .py qui sera appelé par CRON toutes les heures. Ce programme va vérifier que le fichier existe sur le port USB sinon le créer, se placer sur la dernière ligne du fichier pour écrire la date, l'heure et les 2 températures séparées par des point-virgule. puis sauvegarder le fichier et le fermer.

A moi, chaque année ou tous les mois de récupérer le fichier sur la clé USB pour faire des graphiques et vider le fichier.
FEHM ne fait pas ça?

nodarii;1073478 a dit:

Je suppose créer un programme .py qui sera appelé par CRON toutes les heures. Ce programme va vérifier que le fichier existe sur le port USB sinon le créer, se placer sur la dernière ligne du fichier pour écrire la date, l'heure et les 2 températures séparées par des point-virgule. puis sauvegarder le fichier et le fermer.

A moi, chaque année ou tous les mois de récupérer le fichier sur la clé USB pour faire des graphiques et vider le fichier.
FEHM ne fait pas ça?

Cliquez pour agrandir...

Si, FHEM met dans un fichier ASCII les réponses de la VMC, l'intervalle d'échantillonage est définit au départ. Ensuite on peut définir des graphiques et les visualiser dynamiquement (dans l'installation raspVMC, la partie FHEM fait cela).

jcoenen;1073248 a dit:

Sorry for the delay, I'm a bit overloaded at the moment.

I can see that it does 3 to 4 requests every minutes now, so it is faster. At first look I see only Confosense request, but if you get a response to the web call of the cgi, the cgi client requests are processed.

Regarding the CGI, you get a response from your web browser, which means that the javascript in the HTML page should also get it, and consequently display the page.

Question, are all javascript libraries installed, I suppose so if you used the install script.

Second, I sometimes notice that some browsers did not like the code (browser are somehow touched regarding javascript and HTML 5), have you tried with different browser ?

Cliquez pour agrandir...

I have tested it on Safari (OSX and iOS) and IE11.
On both versions of Safari it's exactly the same: as on attached above screenshot.
On IE11 is slightly different, one time it did manage to display a complete page but I received immediately dialog box saying that page isn't responsive and needs to be reloaded.
Timeouts...?

Javascript libraries - for browsers or on raspbpi? On raspbpi everything was installed automatically...

The libraries are there to display the json box in page VMC3.html

OK so the VMCbinjson.cgi works and returns the values that are necessary for the display of the box.

On the 5th of January the box was displayed properly on your web browser.

What does not seem to work (correct me if I'm wrong) is everything at the same time.

Thus VMC server.py
FHEM (using socat)
CCEASE (using another socat)
Web page

But when some of these are not activated, the other work as expected.

Is this the picture ?

jcoenen;1073644 a dit:

The libraries are there to display the json box in page VMC3.html

OK so the VMCbinjson.cgi works and returns the values that are necessary for the display of the box.

On the 5th of January the box was displayed properly on your web browser.

What does not seem to work (correct me if I'm wrong) is everything at the same time.

Thus VMC server.py
FHEM (using socat)
CCEASE (using another socat)
Web page

But when some of these are not activated, the other work as expected.

Is this the picture ?

Cliquez pour agrandir...

General picture.
Works all together:
- VMC server.py
- FHEM (socat pty)
- CGI web page.

If I enable communication with CCEase (tty to tcp), than:
- Fhem gets some timeouts

2016.01.10 17:56:29 3: VMC: timeout waiting for reply expecting 00ce Request was 07f000cd007a070f
2016.01.10 17:56:32 3: VMC: timeout waiting for reply expecting 000c Request was 07f0000b00b8070f

Cliquez pour agrandir...

- VMC server.py is in "cease"mode

~ $ top

top - 18:00:11 up 59 min, 2 users, load average: 0,99, 1,02, 1,15
Tasks: 113 total, 1 running, 112 sleeping, 0 stopped, 0 zombie
%Cpu(s): 23,8 us, 2,5 sy, 0,0 ni, 70,1 id, 0,0 wa, 0,1 hi, 3,4 si, 0,0 st
KiB Mem: 753228 total, 665540 used, 87688 free, 37736 buffers
KiB Swap: 102396 total, 0 used, 102396 free. 452368 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
951 root 20 0 119960 48248 14164 S 87,4 6,4 52:08.86 motion
3987 pi 20 0 4456 924 724 S 2,6 0,1 0:08.62 socat
3 root 20 0 0 0 0 S 2,0 0,0 1:04.16 ksoftirqd/0
908 root 20 0 31084 10388 4928 S 2,0 1,4 0:40.71 wicd
3969 root 20 0 14080 8628 5372 S 2,0 1,1 0:23.07 server.py

Cliquez pour agrandir...

- CGI web page; can't get actual values or time outs

It's an overall picture. Same behavior is on Wheezy and on Jessie.
What are correct settings of CCEase serial port; baud rate, parity, flow control??

to my knowlege CCEASE is 8 bits no parity no flow control 9600 bauds

Just executed:

sudo stty -F /dev/ttyUSB0 9600 cs8 -parenb -cstopb

Cliquez pour agrandir...

as per:

Die RS232 Schnittstelle ist eingestellt auf
 9600 Baud  8 Datenbits  Keine Parity  1 Stop-Bit

Cliquez pour agrandir...

got:

~ $ stty -F /dev/ttyUSB0 -a
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

Cliquez pour agrandir...

and

socat /dev/ttyUSB0,b9600,raw,echo=0 tcp:127.0.0.1:10001

Cliquez pour agrandir...

did change nothing, unfortunately, still same behavior...

Here's mine on a Comfosense.

stty -a --file=/dev/ttyAMA0
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl echoke


It runs on another raspberry but the machine on which the server runs has also fhem and the web client comes back nicely after roughly 5 seconds.

Given that your installation does not differ from mine (or some other I've heard were working) that much, I am kind of running out of idea as to why yours does not seem to behave like the others.

I've just copied serial port properties and as usual, didn't help.
I think, the reason could be some different protocol or information sent between my CCEase and VMC (WHR950). To me looks like once CCEase is connected, it does send some frame and because of delay, VMC partially deactivate/delay further communication (server.py in "ceased" mode). I know, it's not technical wording but that's what logic says.
I also run out of ideas...

A change in the way the VMC respond to the server request could be an explanation, but the server normally queues the client's request in the order they are received, and I can't figure out why the CCEASE would block the other clients as it is not design to work this way (all clients have the same priority). That's why I am puzzled.

I've been thinking a bit , what about socat option of "fork"? Could this be of any use?

UPDATE

HTML pages calls for a temperature sensor on an FHEM instance running on the raspberry serving the web page.

This can cause the page to hang. In order to have the page returning, change the cgi script /usr/lib/cgi-bin/meteo.cgi as follows

++++++++++++++++++++++++++
#!/usr/bin/python
print "Content-Type: text/plain"
print

print '-'
++++++++++++++++++++++++++

The outside temperature will be replaced by "- C" at the upper left arrow (air intake)

Ce matin T-ext ~ -9/-10°C
j'étais en vitesse 2 je passe en absence:

on retrouve ce décalage de 5% (que je n'ai pas normalement)
La préchauffe devait être active du coup la température (entrée) semble s’emballer ,la T soufflée ne bouge, par contre, pas d'un demi degré => les rendements s'affolent. Je passe en vitesse haute pour calmer la surchauffe puis revient en absence.

ça va mieux...

jcoenen;1076351 a dit:

UPDATE

HTML pages calls for a temperature sensor on an FHEM instance running on the raspberry serving the web page.

This can cause the page to hang. In order to have the page returning, change the cgi script /usr/lib/cgi-bin/meteo.cgi as follows

++++++++++++++++++++++++++
#!/usr/bin/python
print "Content-Type: text/plain"
print

print '-'
++++++++++++++++++++++++++

The outside temperature will be replaced by "- C" at the upper left arrow (air intake)

Cliquez pour agrandir...

Hi,

I'm a bit confused, as for now, file looks:

GNU nano 2.2.6 Plik: /usr/lib/cgi-bin/meteo.cgi

#!/usr/bin/python
import json
import socket
import httplib

#web =httplib.HTTPConnection('localhost',8083)
#web =httplib.HTTPSConnection('jpco:jpc0@localhost:8083')
#web.request("GET","/fhem?cmd=jsonlist2%20TX3&XHR=1")
#resp=web.getresponse()
#io=StringIO(resp.read())
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_address = ('127.0.0.1', 7072)
sock.connect(server_address)

sock.send('JsonList TX3\n')

io=sock.recv(1024)


TX3=json.loads(io)


print "Content-Type: text/plain"
print

print TX3['ResultSet']['Results']['READINGS']['temperature']['VAL']

Cliquez pour agrandir...

Did you mean to replace the whole content?

Yes, the whole contents as it is, it tries to connect to fhem and request specific information.

So the easiest way out is to force the return of "-".

Arf j'y arrive pas (( Je vais utiliser ce sujet pour y mettre mes infos, partager mes réflexions afin d'obtenir de l'aide et partager mes problèmes (uniquement ceux liés à la VMC promis ;-)

Quand j'appelle http://192.168.1.3/VMC1.html --> je n'ai qu'une page avec cinq boutons colorés... donc je suppose que ça ne marche pas



Pour rappel de la situation:

- J'ai une Comfod Stockair 550 (non luxe)



- J'ai un raspberry B+



- J'ai relié la VMC avec un câble ethernet sur le port RJ45 de la VMC vers le raspberry.
- Au niveau du raspberry, j'ai une carte additionnelle RS232, sur lequel j'ai mis un adapter RS232/RJ45 (le câble de la VMC se branche dessus).



Donc en gros, VMC <-> RJ45 <-> cable ethernet <-> adapter RJ45/RS232 <-> raspberry RS232.

Pour l'adapter, j'ai ceci:




? les points suspects au niveau installation physique ?

- J'ai serti les embouts RJ45 moi-même (c'est le première fois ;-) et je ne pense pas m'être trompé dans l'ordre (pour l'histoire je ne savais pas faire passer un cable tout fait car j'avais un flex avec tire-fil et trop petit pour les embouts RJ45). J'ai suivi l'ordre suivant pour les deux côtés du cable car je suppose qu'il ne faut pas croiser:



Quand je vois ce schéma, il me semble que je n'ai pas fait exactement cela! J'ai plutôt fait:

8 brun
7 brun/blanc
6 vert
5 vert/blanc
4 bleu
3 bleu/blanc
2 orange
1 orange/blanc

J'aurais donc inversé le 5 et le 3. Edit: Voilà j'ai donc corrigé et re-serti les cables dans le bon ordre. Mais cela ne fonctionne toujours pas.

D'après le schéma suivant retrouvé dans la discussion, je comprends que les fils 2, 3 et 8 sont utilisés, par les autres.



Ensuite dans l'autre point qui pourrait me poser problème. C'est l'adapter RJ45/RS232.

Les codes couleur ne sont bien entendu par les mêmes pour faciliter la chose ;-) Donc voici ce que j'ai trouvé sur le net concernant cet adapter:



Donc d'après ce schéma, il faut que je fasse attention aux fils orange (2), noir (3) et blanc (8).

En reprenant le schéma DB9:



En reprenant ce qui a été dit précedemment:

RJ45 ------- dB9 (RS232)

2 .............. 3 (RX Comfoair vers TX convertisseur)
3 .............. 2 (TX Comfoair vers RX Convertisseur)
8 .............. 5 (ground/masse)

J'ai donc connecté:
-> le fil noir (position 3 pour RJ45) sur le 2
-> le fil orange (position 2 pour RJ45) sur le 3
-> le fil blanc (position 8 pour RJ45) sur le 5

Voici une photo:




? les points suspects au niveau installation raspberry ?


- J'ai désactivé la connexion de la console sur ttyAMA0 via le BIOS. Pour cela j'ai suivi un peu la page suivante: http://www.instructables.com/id/Read-and-write-from-serial-port-with-Raspberry-Pi/

En executant la commande "dmesg | grep tty":

[ 0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0x10 bcm2708.serial=0x9d1f80aa smsc95xx.macaddr=B8:27:EB:1F:80:AA bcm2708_fb.fbswap=1 bcm2708.disk_led_gpio=47 bcm2708.disk_led_active_low=0 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
[ 0.001726] console [tty1] enabled
[ 0.140981] 20201000.uart: ttyAMA0 at MMIO 0x20201000 (irq = 83, base_baud = 0) is a PL011 rev2

La ligne suivante a bien disparue:

[ 0.528662] console [ttyAMA0] enabled

Salut Jipsie, effectivement le 3 est utilisé.

Le câble RJ45 doit être broché de la même manière de chaque côté, le codage des couleur pouvant varier, c'est mieux de regarder sur le RJ45 du câble a quoi les couleurs sont raccordées.

Ce qu'il y a lieu de faire, c'est avec un testeur de continuité (ohmmètre, multimètre), vérifier le câble "ethernet", de façon a être certain que la pin 2 de la VMC est connectée a la pin 3 du dB9, pin 3 VMC - pin 2 db9 et pin 8 VMC - pin 5 dB9.

Il faut absolument que cela soit réalisé pour que les messages soient échangés entre le PI et la VMC.

Ton interface raspberry RS232 est sur ttyAMA0, donc il faut aussi enlever la connexion logicielle de la console (branchée par défaut), cela se fait via raspi-config.

jcoenen;1078778 a dit:

Salut Jipsie, effectivement le 3 est utilisé.

Le câble RJ45 doit être broché de la même manière de chaque côté, le codage des couleur pouvant varier, c'est mieux de regarder sur le RJ45 du câble a quoi les couleurs sont raccordées.

Ce qu'il y a lieu de faire, c'est avec un testeur de continuité (ohmmètre, multimètre), vérifier le câble "ethernet", de façon a être certain que la pin 2 de la VMC est connectée a la pin 3 du dB9, pin 3 VMC - pin 2 db9 et pin 8 VMC - pin 5 dB9.

Il faut absolument que cela soit réalisé pour que les messages soient échangés entre le PI et la VMC.

Ton interface raspberry RS232 est sur ttyAMA0, donc il faut aussi enlever la connexion logicielle de la console (branchée par défaut), cela se fait via raspi-config.

Cliquez pour agrandir...

Bonjour jcoenen,

Merci pour ton aide, en plus un dimanche ;-) J'ai complété mon post qui répondra à une bonne partie de tes questions.

Donc cables brochés de la manière des deux côtés en respectant le standard. Et connexion console dans le raspberry enlevé.

Pour le multimétre, mon épouse en a qui lui servait durant ses études. J'avoue ne pas savoir comment m'en servir mais je vais regarder cela. C'est le prochain point que je contrôle. Est-ce qu'il faut être des deux côtés en même temps pour le test multimétre car la VMC est au grenier, et le raspberry est à la buanderie.

jipsie;1078811 a dit:

Bonjour jcoenen,

Merci pour ton aide, en plus un dimanche ;-) J'ai complété mon post qui répondra à une bonne partie de tes questions.

Donc cables brochés de la manière des deux côtés en respectant le standard. Et connexion console dans le raspberry enlevé.

Pour le multimétre, mon épouse en a qui lui servait durant ses études. J'avoue ne pas savoir comment m'en servir mais je vais regarder cela. C'est le prochain point que je contrôle. Est-ce qu'il faut être des deux côtés en même temps pour le test multimétre car la VMC est au grenier, et le raspberry est à la buanderie.

Cliquez pour agrandir...

Ouille, multimètre, le cable + d'un coté et le - de l'autre, le multimètre fait passer un courant dans le câble et mesure le résultat, si pas de courant détecté alors le cable est fautif. Donc dans ton cas ça va pas être pratique. La position a utiliser est ohmmètre et si le cable est ininterrompu la lecture donne quasi 0 ohms.

Il ne te reste qu'a répertorier les couleurs sur les 2 RJ45 et voir si elle correspondent.

L'inconvénient des adaptateur RJ45-DB9 étant que si on inverse un cable il faut resertir un rj45 avec le bon câblage, c'est pour ça que de mon côté je soude un dB9.

Un fois ton problème de câblage résolu, le logiciel doit fonctionner du premier coup.

jcoenen;1078815 a dit:

Ouille, multimètre, le cable + d'un coté et le - de l'autre, le multimètre fait passer un courant dans le câble et mesure le résultat, si pas de courant détecté alors le cable est fautif. Donc dans ton cas ça va pas être pratique. La position a utiliser est ohmmètre et si le cable est ininterrompu la lecture donne quasi 0 ohms.

Il ne te reste qu'a répertorier les couleurs sur les 2 RJ45 et voir si elle correspondent.

L'inconvénient des adaptateur RJ45-DB9 étant que si on inverse un cable il faut resertir un rj45 avec le bon câblage, c'est pour ça que de mon côté je soude un dB9.

Un fois ton problème de câblage résolu, le logiciel doit fonctionner du premier coup.

Cliquez pour agrandir...

Au niveau de mon multimétre, j'ai cela:



J'ai fait 2/3 tests sur différents trucs et je comprends maintenant comment ça fonctionne. Malheureusement vu la disposition chez moi, je ne sais pas l'utiliser comme tu dis.

Répertorier? Les deux côtés sont exactement les mêmes.

Pour voir si j'ai un soucis au niveau cablage, je pense que la meilleure chose à faire c'est d'aller au grenier avec le raspberry pour faire un test, et utiliser un cable ethernet pré-serti.

Est-ce que l'on est sûr que c'est bien 2, 3 et 8 qu'il faut utiliser sur toutes les comfod?