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 761
en effet au bout de 5 min cela s'actualise
Code:
[2019-02-26 22:29:02][INFO] : Essai de connexion à '192.168.1.15' sur le port '10002'...
[2019-02-26 22:29:02][DEBUG] : Wrote: '73697a65' (4)
[2019-02-26 22:29:02][DEBUG] : Read: '5468657265206172652030206d6573736167657320696e207468652071756575650a' (34)
[2019-02-26 22:29:02][INFO] : Remote daemon alive: 'There are 0 messages in the queue '
[2019-02-26 22:30:04][INFO] : Checking if remote daemon is alive...
[2019-02-26 22:30:04][INFO] : Essai de connexion à '192.168.1.15' sur le port '10002'...
[2019-02-26 22:30:04][DEBUG] : Wrote: '73697a65' (4)
[2019-02-26 22:30:04][DEBUG] : Read: '5468657265206172652030206d6573736167657320696e207468652071756575650a' (34)
[2019-02-26 22:30:04][INFO] : Remote daemon alive: 'There are 0 messages in the queue '
[2019-02-26 22:30:04][INFO] : Reading FanStatus...
[2019-02-26 22:30:04][INFO] : Essai de connexion à 192.168.1.15 sur le port 10000...
[2019-02-26 22:30:04][DEBUG] : Wrote: '07f0000b00b8070f' (8)
[2019-02-26 22:30:11][DEBUG] : Read: '07f0000c0632320474048221070f' (14)
[2019-02-26 22:30:11][DEBUG] : response frame ok
[2019-02-26 22:30:11][DEBUG] : Wrote: '07f000cd007a070f' (8)
[2019-02-26 22:30:12][DEBUG] : Read: '07f000ce0e0f23320f2332323203014646000045070f' (22)
[2019-02-26 22:30:12][DEBUG] : response frame ok
[2019-02-26 22:30:12][INFO] : Reading AllTemperatures...
[2019-02-26 22:30:12][DEBUG] : Wrote: '07f000d1007e070f' (8)
[2019-02-26 22:30:12][DEBUG] : Read: '07f000d209523b4d533e0f5a5a5a10070f' (17)
[2019-02-26 22:30:12][DEBUG] : response frame ok
[2019-02-26 22:30:12][INFO] : Updating temperatures info...
[2019-02-26 22:30:12][INFO] : Reading BypassStatus...
[2019-02-26 22:30:12][DEBUG] : Wrote: '07f000df008c070f' (8)
[2019-02-26 22:30:12][DEBUG] : Read: '07f000e0070000000000000094070f' (15)
[2019-02-26 22:30:12][DEBUG] : response frame ok
[2019-02-26 22:30:12][DEBUG] : Closing socket
[2019-02-26 22:31:02][INFO] : Checking if remote daemon is alive...
[2019-02-26 22:31:02][INFO] : Essai de connexion à '192.168.1.15' sur le port '10002'...
[2019-02-26 22:31:02][DEBUG] : Wrote: '73697a65' (4)
[2019-02-26 22:31:02][DEBUG] : Read: '5468657265206172652030206d6573736167657320696e207468652071756575650a' (34)
[2019-02-26 22:31:02][INFO] : Remote daemon alive: 'There are 0 messages in the queue '
[2019-02-26 22:32:02][INFO] : Checking if remote daemon is alive...
[2019-02-26 22:32:02][INFO] : Essai de connexion à '192.168.1.15' sur le port '10002'...
[2019-02-26 22:32:02][DEBUG] : Wrote: '73697a65' (4)
[2019-02-26 22:32:02][DEBUG] : Read: '5468657265206172652030206d6573736167657320696e207468652071756575650a' (34)
[2019-02-26 22:32:02][INFO] : Remote daemon alive: 'There are 0 messages in the queue '
[2019-02-26 22:33:03][INFO] : Checking if remote daemon is alive...
[2019-02-26 22:33:03][INFO] : Essai de connexion à '192.168.1.15' sur le port '10002'...
[2019-02-26 22:33:03][DEBUG] : Wrote: '73697a65' (4)
[2019-02-26 22:33:03][DEBUG] : Read: '5468657265206172652030206d6573736167657320696e207468652071756575650a' (34)
[2019-02-26 22:33:03][INFO] : Remote daemon alive: 'There are 0 messages in the queue '
[2019-02-26 22:34:03][INFO] : Checking if remote daemon is alive...
[2019-02-26 22:34:03][INFO] : Essai de connexion à '192.168.1.15' sur le port '10002'...
[2019-02-26 22:34:03][DEBUG] : Wrote: '73697a65' (4)
[2019-02-26 22:34:03][DEBUG] : Read: '5468657265206172652030206d6573736167657320696e207468652071756575650a' (34)
[2019-02-26 22:34:03][INFO] : Remote daemon alive: 'There are 0 messages in the queue '
[2019-02-26 22:35:03][INFO] : Checking if remote daemon is alive...
[2019-02-26 22:35:03][INFO] : Essai de connexion à '192.168.1.15' sur le port '10002'...
[2019-02-26 22:35:03][DEBUG] : Wrote: '73697a65' (4)
[2019-02-26 22:35:03][DEBUG] : Read: '5468657265206172652030206d6573736167657320696e207468652071756575650a' (34)
[2019-02-26 22:35:03][INFO] : Remote daemon alive: 'There are 0 messages in the queue '
[2019-02-26 22:35:03][INFO] : Reading FanStatus...
[2019-02-26 22:35:03][INFO] : Essai de connexion à 192.168.1.15 sur le port 10000...
[2019-02-26 22:35:03][DEBUG] : Wrote: '07f0000b00b8070f' (8)
[2019-02-26 22:35:04][DEBUG] : Read: '07f0000c064646036003560707070f' (15)
[2019-02-26 22:35:04][DEBUG] : data size of '07f0000c064646036003560707070f' invalid, expected:6 counted:7
[2019-02-26 22:35:04][DEBUG] : Wrote: '07f000cd007a070f' (8)
[2019-02-26 22:35:04][DEBUG] : Read: '07f000ce0e0f23320f233246460401464600006e070f' (22)
[2019-02-26 22:35:04][DEBUG] : response frame ok
[2019-02-26 22:35:04][INFO] : Reading AllTemperatures...
[2019-02-26 22:35:04][DEBUG] : Wrote: '07f000d1007e070f' (8)
[2019-02-26 22:35:04][DEBUG] : Read: '07f000d209523b4d533e0f5a5a5a10070f' (17)
[2019-02-26 22:35:04][DEBUG] : response frame ok
[2019-02-26 22:35:04][INFO] : Updating temperatures info...
[2019-02-26 22:35:04][INFO] : Reading BypassStatus...
[2019-02-26 22:35:04][DEBUG] : Wrote: '07f000df008c070f' (8)
[2019-02-26 22:35:05][DEBUG] : Read: '07f000e0070000000000000094070f' (15)
[2019-02-26 22:35:05][DEBUG] : response frame ok
[2019-02-26 22:35:05][DEBUG] : Closing socket
[2019-02-26 22:36:03][INFO] : Checking if remote daemon is alive...
[2019-02-26 22:36:03][INFO] : Essai de connexion à '192.168.1.15' sur le port '10002'...
[2019-02-26 22:36:03][DEBUG] : Wrote: '73697a65' (4)
[2019-02-26 22:39:02][INFO] : Checking if remote daemon is alive...
[2019-02-26 22:39:02][INFO] : Essai de connexion à '192.168.1.15' sur le port '10002'...
[2019-02-26 22:39:02][DEBUG] : Wrote: '73697a65' (4)
[2019-02-26 22:40:03][INFO] : Reading FanStatus...
[2019-02-26 22:40:03][INFO] : Essai de connexion à 192.168.1.15 sur le port 10000...
[2019-02-26 22:40:03][DEBUG] : Wrote: '07f0000b00b8070f' (8)
[2019-02-26 22:42:03][INFO] : Checking if remote daemon is alive...
[2019-02-26 22:42:03][INFO] : Essai de connexion à '192.168.1.15' sur le port '10002'...
[2019-02-26 22:42:03][DEBUG] : Wrote: '73697a65' (4)
 
  • #1 762
@jcoenen j'ai soumis un pr sur le projet sur github pour régler le fait que le server.py consomme autant de CPU qu'il peut (100% d'un CPU si rien d'autre).
 
  • #1 763
Oui effectivement, a l’epoque j’avais essayé de résoudre ça par une temporisation avec un sleep, sauf qu’alors pendant les périodes de sommeil il n’y plus aucune gestion des messages entrant et on est à la merci des buffers d’I/O, qui au bout d’un moment perdent des messages et comme on ne peut pas savoir quand va arriver le prochain message ... Faudrait un operating system temps reel (RTOS, RSX-11 MPX-32) mais ca compliquerait legerement l’installation.

Avec un comfosense le sleep ne fonctionne pas du tout (trop de messages)
 
  • #1 764
Ah ok même avec 1 milliseconde?
bon à savoir merci.
de fait, j’attends encore une pièce qui devrait arriver fin de semaine prochaine pour pouvoir connecter mon ccease donc je n'ai pas su tester avec encore.
 
  • #1 765
Ayant fait les essais il y a disons un certain temps, je me rapelle plus trop (à l'époque j'était sur un raspberry pi version 1, c'est tout dire). Le système est articulé autour d'un IO Select, qui attend des donnée sur les ligne IO connectées. C'est a dire, les clients (via TCP/IP) qui incluent les logiciels de domotique, les client bash, les clients WEB ...
Le client CCEASE (sur un port séparé) et la VMC.

En installant un sleep (et en me basant sur des buffer d'IO plus grand), le load diminue certes mais certains messages se perdent, par contre, même si le load est a 100% (en fait le IO select attend bêtement les entrées sorties, et ne fait pas grand chose), les autres process n'en souffrent pas grtâce au round robin de Unix qui donne la main aux autres process en temps utile, j'ai donc décidé de ne pas mettre de sleep et de ne pas passer mes soirées la dessus.

Mais rien n'empêche d'expérimenter la chose, si le sleep est très petit de fait on diminue le risque de perdre des données mais du coup on augmente la charge ...
 
  • #1 766
Je reviens un peu ici car j'ai a chaque fois le même soucis lorsque je dois redémarrer le PI, impossible d'avoir la connexion avec le Comfosense facilement

Je dois rebooter le pi plusieurs fois, créer mon deuxième socat pour le comfosense, je redémarre fhem, apache, bref j'essaye plein de combinaison sans jamais trouver celle qui marchera a chaque fois

Mon comfosense se met en "com error"

Et au bout d'un moment sans comprendre pq, ça refonctionne

J'ai juste une impression c'est que tant que je n'arrive pas à avoir la page web de FHEM, ça ne fonctionne pas
Mon browser tourne en boucle mais rien ne s'affiche

Apache fonctionne, j'ai bien la page d'accueil

Je ne vois rien de spécial dans les logs

Désolé mais je ne vois pas trop ce que je peux faire
 
  • #1 767
Donc pour les logs:

J'ai bien mes service appache2, fhem et VMCserver qui sont démarrés

Code:
root@raspberrypi:/home/pi# systemctl status VMCserver
● VMCserver.service - VMC python server
   Loaded: loaded (/etc/systemd/system/VMCserver.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-09-05 00:09:40 CEST; 32min ago
 Main PID: 349 (server.py)
   CGroup: /system.slice/VMCserver.service
           ├─349 /usr/bin/python /home/pi/raspVMC-master/server.py
           └─435 socat PTY,mode=666,link=/tmp/ttyVMC TCP-CONNECT:127.0.0.1:10000

Sep 05 00:09:40 raspberrypi systemd[1]: Started VMC python server.
Sep 05 00:09:43 raspberrypi server.py[349]: Starting NEW VMC server on device/dev/ttyAMA0, Debug to:/var/log/VMClog.log, running on IP address:('', 10000)
Sep 05 00:09:43 raspberrypi server.py[349]: Starting VMC server for ConfoSense on IP address:('', 10001) port 10001
Sep 05 00:09:43 raspberrypi server.py[349]: Starting VMC server for Control on IP address:('', 10002) port 10002
Sep 05 00:09:43 raspberrypi server.py[349]: socat started on /tmp/ttyVMC, PID:435

J'ai fais ma commande pour lancer le second socat
Code:
root@raspberrypi:/home/pi# socat /dev/ttyUSB0,raw,echo=0,b9600 tcp4-connect:127.0.0.1:10001 &

Par contre impossible d'avoir la page FHEM, ça tourne en rond et même pas de timeout, ca tourne sans cesse
 
  • #1 768
et le log VMC voit bien le comfosense
Code:
05/09/19 00:09:43 : socat
05/09/19 00:09:43 : PTY,mode=666,link=/tmp/ttyVMC
05/09/19 00:09:43 : TCP-CONNECT:127.0.0.1:10000
05/09/19 00:09:43 : new client connection from ('127.0.0.1', 48036)
05/09/19 00:25:51 : New connection for CCEASE/COMFOSENSE from  ('127.0.0.1', 60944)
 
  • #1 769
je continue mon analyse

FHEM vient enfin d'afficher la page web
J'ai fait un kill du process socat sur le 10001 et j'ai relancé le socat

maintenant c'est OK

Donc on dirait qu'il y a un long délai avant de pouvoir lancer le socat à cause de fhem
 
  • #1 770
Peux tu me donner les commandes socat utilisées pour FHEM et comfosense ?

La configuration des ports séries.

FHEM a l’air de boucler à l’initialisation, la question est sur quel device ? au démarrage aller voir où il en est dans son log (/opt/fhem/log/fhem.date?annee...log)

Y-a-t’il d’autres devices USB connectés au raspberry ?
 
  • #1 771
Salut jcoenen et encore merci d'avance pour ton aide

Peux tu me donner les commandes socat utilisées pour FHEM et comfosense ?
Au démarrage, quand je fais un "ps -ef | grep socat"
Le FHEM se lance apparemment avec
Code:
socat PTY,mode=666,link=/tmp/ttyVMC TCP-CONNECT:127.0.0.1:10000
ENsuite je démarre pour le comfosense,en root
Code:
/home/pi# socat /dev/ttyUSB0,raw,echo=0,b9600 tcp4-connect:127.0.0.1:10001 &

La configuration des ports séries.
Code:
pi@raspberrypi:/etc/VMC $ cat VMC.ini
[VMC]
device = /dev/ttyAMA0

[server]
bind =
port = 10000

[control]
port = 10002

[client]
server = 127.0.0.1

[socat]
pty = /tmp/ttyVMC

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

[mysql]
host =
user =
password =
db =

FHEM a l’air de boucler à l’initialisation, la question est sur quel device ? au démarrage aller voir où il en est dans son log (/opt/fhem/log/fhem.date?annee...log)
Le log FHEM est plein de
Code:
2019.09.05 07:36:41 3: VMC: timeout waiting for reply expecting 00e0 Request was 07f000df008c070f
2019.09.05 07:41:39 3: VMC: timeout waiting for reply expecting 000c Request was 07f0000b00b8070f
2019.09.05 07:46:39 3: VMC: timeout waiting for reply expecting 00ce Request was 07f000cd007a070f
2019.09.05 07:51:39 3: VMC: timeout waiting for reply expecting 000c Request was 07f0000b00b8070f
2019.09.05 07:51:41 3: VMC: timeout waiting for reply expecting 00e0 Request was 07f000df008c070f
2019.09.05 07:56:39 3: VMC: timeout waiting for reply expecting 000c Request was 07f0000b00b8070f
2019.09.05 07:56:41 3: VMC: timeout waiting for reply expecting 00e0 Request was 07f000df008c070f
2019.09.05 08:01:39 3: VMC: timeout waiting for reply expecting 00ce Request was 07f000cd007a070f

Y-a-t’il d’autres devices USB connectés au raspberry ?
Non rien d'autre
 
  • #1 772
Ok, bon tout à l’air correct, les messages dans le log FHEM sont normaux en ce sens que le comfosense sature le bus de la VMC (et qu’il manque peut être un ACK dans le protocole), mais cela ne doit rien bloquer c’est informel.

C’est au démarrage de fhem que ça a l’air de bloquer d’apres ton descriptif (pas de mise a jour de la page web). Il faudrait donc aller voir dans log quand FHEM démarre sur quel device ou sous système il bloque, le démarrage de FHEM doit normalement donner accès a la page web assez rapidement, sauf s'il attend un retour qui ne vient pas (genre initiaize device et le device n'est pas là) alors il doit faire un time out avant de pouvoir continuer.

Quand tu accèdes la page FHEM c'est bien l'url http://xx.xx.xx.xx:8093 et pas la page VMC)
 
Dernière édition:
  • #1 773
dans init.d tu veux dire ?

et non, rien d'autre n'est connecté sur les port USB
 
  • #1 774
Oui je viens de me rendre compte que tu l'avais déjà dit (je me fais vieux).

La séquence d'activation devrait être en toute logique:

VMCserver
Socat FHEM + socat Comfosense (mais à la rigeur ce derner peut être démarré a la fin, pour ne pas saturer le BUS VMC dès le départ, exemple après fhem)
FHEM
 
  • #1 775
le socat comfosense, je le démarre manuellement

mais j'ai donc remarqué que FHEM met énormément de temps avant d'être dispo
 
  • #1 776
et by the way, je n'ai rien dans /etc/init.d pour FHEM donc je présume que c'est uniquement via systemctl
 
  • #1 777
Oui avec les dernière raspbian c'est avec systemctl.

J'irais voir du côté du démarage de FHEM où ça coince, quitte a redémarrer le pi et faire un tail -f /opt/fhem/log/fhem....log si tu vois qu'une action du démarrage prend des plombes alors ...
 
  • #1 778
je viens de voir dans le log fhem

2019.09.05 00:31:05 1: Including fhem.cfg
2019.09.05 00:31:12 3: WEB: port 8083 opened
2019.09.05 00:31:13 2: eventTypes: loaded 37 events from ./log/eventTypes.txt
2019.09.05 00:31:14 3: Opening VMC device /tmp/ttyVMC
2019.09.05 00:31:15 3: VMC device opened
2019.09.05 00:31:19 1: Including ./log/fhem.save
2019.09.05 00:31:19 1: usb create starting
2019.09.05 00:31:23 3: Probing ZWDongle device /dev/serial0
2019.09.05 00:31:24 3: Probing CUL device /dev/ttyAMA0
2019.09.05 00:31:24 3: Probing TCM_ESP3 device /dev/ttyAMA0
2019.09.05 00:31:25 3: Probing ZWDongle device /dev/ttyAMA0
2019.09.05 00:31:25 3: Probing FRM device /dev/ttyAMA0
2019.09.05 00:31:30 3: Probing TCM_ESP3 device /dev/ttyUSB0
2019.09.05 00:31:30 3: Probing TCM_ESP2 device /dev/ttyUSB0
2019.09.05 00:31:31 3: Probing FHZ device /dev/ttyUSB0
2019.09.05 00:31:31 3: Probing TRX device /dev/ttyUSB0
2019.09.05 00:31:32 3: Probing ZWDongle device /dev/ttyUSB0
2019.09.05 00:31:32 3: Probing FRM device /dev/ttyUSB0
2019.09.05 00:46:36 1: usb create end

2019.09.05 00:46:36 0: Featurelevel: 5.9
2019.09.05 00:46:36 0: Server started with 14 defined entities (fhem.pl:18111/2019-01-01 perl:5.024001 os:linux user:fhem pid:552)
2019.09.05 00:46:36 3: VMC: read did not get expected reply (00d2) but 00e0
2019.09.05 00:46:39 3: VMC: timeout waiting for reply expecting 000c Request was 07f0000b00b8070f
2019.09.05 00:47:27 3: VMC: Timeout2 in ReadAnswer for Stufe
2019.09.05 00:47:27 3: VMC: timeout waiting for reply Request was 07f00099010148070f
2019.09.05 00:47:35 3: VMC: Timeout2 in ReadAnswer for Stufe
2019.09.05 00:47:35 3: VMC: timeout waiting for reply Request was 07f0009901044b070f
2019.09.05 00:47:40 3: VMC: Timeout2 in ReadAnswer for Stufe
2019.09.05 00:47:40 3: VMC: timeout waiting for reply Request was 07f00099010148070f

15 minutes entre ces deux étapes, ça doit être là que se situe le soucis non ?
 
  • #1 779
Alors là effectivement, il essaye de voir si le USB0 est connecté avec un dongle FRM (Arduino ???) je vais voir s'il n'y a pas moyen de déshabiliter l'autosense des dongles.
 
  • #1 780
Bon je ne vois rien de particulier dans la doc pour le USB create.

Dans le fichier de configuration de FHEM (fhem.cfg)

Cherches autocreate

j'ai de mon côté

define autocreate autocreate
attr autocreate disable 1
attr autocreate filelog ./log/%NAME-%Y.log

Je pense que cela doit être la solution (enfin j'espère car la doc n'est pas claire sur le sujet)
 

Sujet semblables

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

Nos articles

On a aimé dans le forum

Retour
Haut