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

( dans

» Electricité » Domotique

)
Chercher:    

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

- Page 48
Page 48 sur 67 Première page - Résultats 1 à 20 sur 1 340 Page precedente 384647 48 495058 Page suivante Dernière page - Résultats 1 321 à 1 340 sur 1 340


31/12/2015 Vieux  
 
 
merci. on progresse. il y a toujours NC affiché mais si j'appui sur un bouton j'ai

pi@raspberrypi ~/raspVMC-master $ sudo socat -x /dev/ttyUSB0,b9600,raw,echo=0 tcp:127.0.0.1:10001

ff

Déjà est ce qu'il faut connecter le GND du RJ45 avec le ground du CCEASE ?
31/12/2015 Vieux  
 
 
et dans le log

31/12/15 12:40:27 : Command code: 0d reply is True
31/12/15 12:40:27 : expecting a reply
31/12/15 12:40:27 : received from VMC 07f307f0000e0400000000bf070f
31/12/15 12:40:27 : 12 frames received from VMC only one is expected from theread
31/12/15 12:40:27 : frame received from VMC stored in client queue 07f0000e0400000000bf070f
31/12/15 12:40:27 : sending 07f0000e0400000000bf070f to ('127.0.0.1', 34393)
31/12/15 12:40:27 : closing ('127.0.0.1', 34393) after reading no data
error: <class 'ConfigParser.NoSectionError'>
31/12/15 13:48:56 : New connection for CCEASE/COMFOSENSE from ('127.0.0.1', 47874)
31/12/15 13:51:44 : closing ('127.0.0.1', 47874) after reading no data
31/12/2015 Vieux  
 
  56 ans, Liège
 
Citation:
Posté par scyrille Voir le message
merci. on progresse. il y a toujours NC affiché mais si j'appui sur un bouton j'ai

pi@raspberrypi ~/raspVMC-master $ sudo socat -x /dev/ttyUSB0,b9600,raw,echo=0 tcp:127.0.0.1:10001

ff

Déjà est ce qu'il faut connecter le GND du RJ45 avec le ground du CCEASE ?
oui les gnd doivent être raccordées c'est indispensable sinon il n'y a pas de référence et donc la réception est aleatoire
31/12/2015 Vieux  
 
 
Bon j'ai fait ça mais toujours NC d'affiché sur le CCEASE

et j'ai sur socat des ff qui s'affichent de temps en temps

Inversion du TX et RX ?
31/12/2015 Vieux  
 
 
The default filter error time is 16 weeks according to this manual (p10):
http://www.zehnder.co.uk/download/39741/en_uk-11037.pdf

Indeed a bit stupid to determine dirty filters this way. Big ventilation units normally determine pressure drop over the filters.
But i guess for home use they dont think it important enough for the cost.
31/12/2015 Vieux  
 
 
A noter que le lancement de socat déclenche l'allumage (illuminé) de l'écran du CCEASE si il est en veille

Dec 31 14:25:26 raspberrypi server.py: Starting NEW VMC server on device/dev/ttyUSB1, Debug to:/var/log/VMClog.log, running on IP address'', 10000)
Dec 31 14:25:26 raspberrypi server.py: Starting VMC server for ConfoSense on IP address'', 10001) port 10001
Dec 31 14:25:26 raspberrypi server.py: Starting VMC server for Control on IP address'', 10002) port 10002
Dec 31 14:25:26 raspberrypi server.py: VMCserver cannot start socat (maybe not configured)
Dec 31 14:26:29 raspberrypi kernel: [13104.513347] Transfer to device 5 endpoint 0x1 frame 351 failed - FIQ reported NYET. Data may have been lost.

Dernière modification par scyrille 31/12/2015 à 15h29.
31/12/2015 Vieux  
 
  56 ans, Liège
 
Citation:
Posté par Beire Voir le message
The default filter error time is 16 weeks according to this manual (p10):
http://www.zehnder.co.uk/download/39741/en_uk-11037.pdf

Indeed a bit stupid to determine dirty filters this way. Big ventilation units normally determine pressure drop over the filters.
But i guess for home use they dont think it important enough for the cost.
There you go, but given that the efficiency can be calculated with the temperatures, it can be used to determine when to change filters ...
31/12/2015 Vieux  
 
  56 ans, Liège
 
Citation:
Posté par scyrille Voir le message
A noter que le lancement de socat déclenche l'allumage (illuminé) de l'écran du CCEASE si il est en veille

Dec 31 14:25:26 raspberrypi server.py: Starting NEW VMC server on device/dev/ttyUSB1, Debug to:/var/log/VMClog.log, running on IP address'', 10000)
Dec 31 14:25:26 raspberrypi server.py: Starting VMC server for ConfoSense on IP address'', 10001) port 10001
Dec 31 14:25:26 raspberrypi server.py: Starting VMC server for Control on IP address'', 10002) port 10002
Dec 31 14:25:26 raspberrypi server.py: VMCserver cannot start socat (maybe not configured)
Dec 31 14:26:29 raspberrypi kernel: [13104.513347] Transfer to device 5 endpoint 0x1 frame 351 failed - FIQ reported NYET. Data may have been lost.
Il est possible que le CCEASE réagisse à une réception de donnée sur le port série, mais si le signal est mauvais (les masses non connectées ensembles, ou mauvais contact) alors le CCEASE ne pourra pas reconnaitre les données reçues et donc ne peut afficher de valeurs.

Dans le log ci dessus, le serveur démarre le module client sur le port 10000
le module confosense sur le port 10001
le module d'accès telnet (pour debug) sur le port 10002
le démarrage de socat pour FHEM ne fonctionne pas (la section n'est peut être pas définie dans VMC.ini, si tu n'utilises pas FHEM, ce n'est pas un problème)
31/12/2015 Vieux  
 
  Autre pays
 
Hi All,

jcoenen, sorry for late reply (festive break ).
Citation:
What you could do, is to run the cgi from the command line and see what happen there.

just do

/usr/lib/cgi-bin/VMCbinjson.cgi

if it returns, then the problem is elsewhere

But in essence you're right, the CCEASE continuously sample the VMC and the other clients must fit in the blanks, which delays their sampling process.
I did above (after having socat /dev/ttyUSB0,raw,echo=0,b9600 tcp:localhost:10001 executed) and the results are:
Citation:
~ $ /usr/lib/cgi-bin/VMCbinjson.cgi
Content-Type: application/json


{
"config": {
"ventilateurs": {
"admission": {
"absent": 15,
"actuel": 35,
"vitesse1": 35,
"vitesse2": 50,
"vitesse3": 70
},
"extraction": {
"absent": 15,
"actuel": 35,
"vitesse1": 35,
"vitesse2": 50,
"vitesse3": 70
},
"extractionetat": 1,
"vitesse": 2
}
},
"data": {
"bypass": {
"correction": 0,
"facteur": 0,
"mode": "hiver",
"periode": 0
},
"etatswitches": {
"L1": "OFF",
"L2": "OFF",
"SDB": "OFF",
"SDBluxe": "OFF",
"hotte": "OFF"
},
"temperature": {
"Tairneuf": 1.0,
"Tconfort": 24.0,
"Textrait": 2.5,
"Trepris": 18.0,
"Tsoufflage": 13.5,
"capteur": {
"TEnthalpie": "absent",
"Tairneuf": "present",
"Tappoint": 0.0,
"Tapppoint": "absent",
"Tenthaplie": 0.0,
"Textrait": "present",
"Thotte": 0.0,
"Trepris": "present",
"Tsoufflage": "present"
}
},
"usage": {
"absent": 1622,
"antigel": 0,
"bypass": 9576,
"filtres": 318,
"prechauffe": 12,
"vitesse1": 18294,
"vitesse2": 9968,
"vitesse3": 0
},
"valvesetat": {
"bypass": 0,
"courantmoteurbypass": 0,
"courantmoteurprechauf": 0,
"prechauff": 0
},
"ventilateurs": {
"extraitpourcent": 35,
"extraitrpm": 1112,
"soufflagepourcent": 35,
"soufflagerpm": 1191
}
},
"device": {
"firmware": "3.20",
"name": "WHR 950 "
}
}
On the other hand, CGI based site (VMC3.html) isn't refreshed - hangs on
Citation:
loading actual values
I've discovered one thing. "top" command reveals that server.py is somehow paused as it occupies only 1-2% (usually it's around 95-99%) of CPU time:
Citation:
~ $ top

top - 14:54:57 up 4:23, 2 users, load average: 0,29, 0,45, 0,53
Tasks: 110 total, 1 running, 109 sleeping, 0 stopped, 0 zombie
%Cpu(s): 7,8 us, 1,2 sy, 0,0 ni, 90,5 id, 0,0 wa, 0,0 hi, 0,6 si, 0,0 st
KiB Mem: 753228 total, 612676 used, 140552 free, 56676 buffers
KiB Swap: 102396 total, 0 used, 102396 free. 360356 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
981 root 20 0 118036 45600 14004 S 25,7 6,1 71:53.84 motion
493 root 20 0 14080 8724 5468 S 2,0 1,2 216:13.06 server.py
926 root 20 0 31084 10520 5060 S 1,6 1,4 2:34.04 wicd
18089 pi 20 0 4564 2320 2076 S 1,6 0,3 0:04.28 socat
18197 pi 20 0 6812 2528 2116 R 1,0 0,3 0:01.55 top
And it could be cause of FHEM getting timeouts:
Citation:
2015.12.31 14:51:47 3: VMC: timeout waiting for reply expecting 00e0 Request was 07f000df008c070f
2015.12.31 14:51:50 3: VMC: timeout waiting for reply expecting 00d2 Request was 07f000d1007e070f
2015.12.31 14:56:47 3: VMC: timeout waiting for reply expecting 00e0 Request was 07f000df008c070f
2015.12.31 14:56:50 3: VMC: timeout waiting for reply expecting 00d2 Request was 07f000d1007e070f
2015.12.31 15:01:48 3: VMC: timeout waiting for reply expecting 00e0 Request was 07f000df008c070f
2015.12.31 15:01:51 3: VMC: timeout waiting for reply expecting 00d2 Request was 07f000d1007e070f
So, summing up, despite direct replies in command line, server.py can't handle smultaneous requests from CCEase and webpage based FHEM and CGI scripts...
31/12/2015 Vieux  
 
 
Je continue mes recherches. Dans les logs d'erreur j'ai

Traceback (most recent call last):
File "/home/pi/raspVMC-master/server.py", line 291, in <module>
readable, writable, exceptional = select.select(inputs, outputs, inputs)
File "/home/pi/raspVMC-master/server.py", line 48, in signal_handler
syslog.syslog('Closing IP socket on client '+str(instance.getpeername()))
File "/usr/lib/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
socket.error: [Errno 107] Transport endpoint is not connected
31/12/2015 Vieux  
 
  56 ans, Liège
 
Actually it can, we just finalized an installation on a raspberry pi V1 but with a Comfosense, the user tells me it works both on the Web and on the comfosense.

I do not have a CCEASE, but I cannot imagine why it would not work being basically the same unit as a comfosense.

So there must some obscure reason why it does no work for you.

Have you tried to run the socat of the CCEASE with the -x option, it should show the traffic coming out of the unit. If no traffic then there is somehow a problem at the hardware level.

Should the server behave erratically, just kill it, it should gracefully restart. Depending on how you start socat for the CCEASE you may need to restart it.

Best being to have first a working system with the Web and then run socat manually with -x to see that the CCEASE sends the frames to the server (if that is not happening then the CCEASE is not properly connected to the raspberry).

Dernière modification par jcoenen 31/12/2015 à 16h35.
31/12/2015 Vieux  
 
  56 ans, Liège
 
Citation:
Posté par scyrille Voir le message
Je continue mes recherches. Dans les logs d'erreur j'ai

Traceback (most recent call last):
File "/home/pi/raspVMC-master/server.py", line 291, in <module>
readable, writable, exceptional = select.select(inputs, outputs, inputs)
File "/home/pi/raspVMC-master/server.py", line 48, in signal_handler
syslog.syslog('Closing IP socket on client '+str(instance.getpeername()))
File "/usr/lib/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
socket.error: [Errno 107] Transport endpoint is not connected
C'est un client qui est mort (crash) avant que le server n'aie pu fermer la connexion, ce n'est pas grave ça.

Je viens de terminer une install avec un Confosense, qui maintenant fonctionne, les problèmes étaient du a de mauvaises connexions (inversions, pin 3 et 4 au lieu de 2 et 3, masse pas raccordée ...)

Le CCEASE devant être raccordé au pin 2 et 3 du db9 dont voici le pinout.

La pin 5 est reliée a la masse (GND qui est commune)

Le CCEASE est raccordé au 12 Volts et à la masse pour alimentation.



Contrôler sa VMC StorkAir / ComfoAir / zehnder via sa domotique
31/12/2015 Vieux  
 
  56 ans, Liège
 
If you provide me with an IP address and a port I could ssh in your machine to see if I can fix things from remote.

Si vous me donnez une adresse IP et un port, je pourrais faire un ssh dans votre raspberry et voir si je peux résoudre le problème en remote.

Send me a private message with /envoyez moi un message privé avec

IPAddress, SSH Port, raspberry pi user name, password

Don't forget to install the route in your router - n'oubliez pas de mettre la route dans votre routeur.
31/12/2015 Vieux  
 
  Autre pays
 
Citation:
Best being to have first a working system with the Web and then run socat manually with -x to see that the CCEASE sends the frames to the server (if that is not happening then the CCEASE is not properly connected to the raspberry).
CCEase works fine - all data is displayed and I can control VMC unit after executing socat command. Simply all other services (FHEM, webbased CGI) are affected by paused server.py and get timeout. Hardware part is fine.
I've just checked also CCEase socat -x and I got a lot of frames displayed. Maybe there's a difference between CCEase and ConfoSense which causes communication breakdown?
31/12/2015 Vieux  
 
  56 ans, Liège
 
Citation:
Posté par listhor Voir le message
CCEase works fine - all data is displayed and I can control VMC unit after executing socat command. Simply all other services (FHEM, webbased CGI) are affected by paused server.py and get timeout. Hardware part is fine.
I've just checked also CCEase socat -x and I got a lot of frames displayed. Maybe there's a difference between CCEase and ConfoSense which causes communication breakdown?
OK so CCEASE is working then ?

Clients are working (clientx.py and VMCbinjson.cgi return values), but web page does not display, which happens when not all values are returned in the json.

Is this correct ?

An explanation could be that the CCEASE is sending more frames then the ComfoSense which would saturate the server and prevent the other clients to properly run (although, frames are processed as they come in, so this should not happen).
31/12/2015 Vieux  
 
  Autre pays
 
Yes, CCEase works, clients and *json.cgi as well. Only web page services are affected (narrow timeout limits?).
But I wonder why server.py is paused (2% vs 99% when operational)? Common sense would say server.py should work harder not less upon receiving more frames...(?)

Update:
I'm not sure, but it seems like executing command as:
Citation:
~ $ socat /dev/ttyUSB0,raw,echo=0,b9600 tcp:172.16.0.15:10001
I mean using IP address instead of "localhost" makes FHEM more responsive - it gets much less timeouts and when I change VMC speed using CCEase, FHEM receives update reasonably quick.
Unfortunately, CGI based web page (VMC*.html) remains frozen and server.py is in "pause" mode...

Dernière modification par listhor 31/12/2015 à 17h22.
31/12/2015 Vieux  
 
  56 ans, Liège
 
Citation:
Posté par listhor Voir le message
Yes, CCEase works, clients and *json.cgi as well. Only web page services are affected (narrow timeout limits?).
But I wonder why server.py is paused (2% vs 99% when operational)? Common sense would say server.py should work harder not less upon receiving more frames...(?)
Now that you say that I'll check if I have a time out on the javascript of the webpage ...
31/12/2015 Vieux  
 
 
Un grand merci à jcoenen qui m'a dépanné à distance. Tout fonctionne maintenant je vais préparer un petit recapitulatif de toute l'installation pour ceux qui ont besoin d'aide.
31/12/2015 Vieux  
 
  56 ans, Liège
 
Pas de soucis, il fallait terminer l'année sur un feu d'artifice, vu que les officiels sont "annulés"

Listhor, I have just debugged the installation of Scyrille, I can see that on a raspberry V1, it takes 24 seconds for the cgi to come back, which probably causes the web page to drop, I checked my code, but do not see any timeout for the request, I need to simulate this on my PI V2 to see if I can find a workaround.

Sorry about this, but as you know a corollary of murphy's law says that there is always one more bug

I also check the frame queue that stores the pending requests from the clients, it shows that if more clients are connecting, the raspberry is having problems to handle the queue, which can also be a source of problem (not for the CCEASE but for FHEM and Web, this is probably why you have timeout and no reponses, the queue cannot keep up).

That I have never seen with the raspberry pi V2, what can I say, all hardware has its limits.

Dernière modification par jcoenen 31/12/2015 à 17h57.
31/12/2015 Vieux  
 
  Autre pays
 
Thanks jcoenen. Just for the sake of my mind; so "overframing" of server.py makes it to pause itself? Or just queue is broken and server.py receives nothing (that would explain 2% of CPU utilisation)?
My hardware is Raspberry Pi 2 model B 1GB RAM and for example, webmin shows up a total utilisation of CPU, memory and so on, on about 40 to 50% level. I haven't seen it to work fully overloaded.

Anyway, you did a great job and I keep fingers crossed you will overcome such a issue .
Happy a New Year!
Page 48 sur 67 Première page - Résultats 1 à 20 sur 1 340 Page precedente 384647 48 495058 Page suivante Dernière page - Résultats 1 321 à 1 340 sur 1 340


A lire également sur BricoZone...
Zehnder ou Storkair / whr ou confoD ? Par chevy3600 dans Plomberie, +3 13/06/2016
Storkair ConfoD luxe et domotique Par sebcbien dans VMC, PAC, Clim, +12 21/10/2013
VMC storkair Par lombsss dans VMC, PAC, Clim, +1 25/01/2013
VMC storkair comfod 350 Par sam_bech dans VMC, PAC, Clim, +16 22/01/2013
Où acheter VMC DF Zehnder/Storkair ? Par Lapilux dans VMC, PAC, Clim, +4 26/03/2012


Forum Domotique : Voir ce forum, Nouveautés, Actifs, Sans rép
Tout BricoZone : Page de garde, Dernieres 24h

Photos au hasard
Voir toutes nos photos


Pas encore membre de BricoZone ?!
Attention Pour participer, poser une Question ou Répondre : inscrivez vous !
Ceci vous permettra également de recevoir un email lors des réponses.
Mais même si vous ne voulez rien écrire : vous pourrez surveiller les forums et leurs nouveaux messages, et obtenir une vue rapide de tous les nouveaux messages depuis votre dernière visite !
Tout ceci est évidemment gratuit et rapide.

Visitez aussi : BricoZone France, nos Blogs. On aime Astel, JardiZone et InternetVista.
 
Connexion!
Identifiant
Mot de passe

Inscription - Oublié ?

Annuaire Pro

FT Chassis

Spécialiste des châssis PVC, bois et aluminium, portes et volets roulants.


DECOCHALET

Vente et placement d'abris de jardin, carports, garages, pergolas, boxes pour chevaux, ...


Tendance Habitat

Entreprise générale du bâtiment


La Vidange Loiseau S.A.

Débouchage, placement, raccordement et réparation des égouts.

Ajoutez votre société