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

hip hip hip !!!!

Hourra!!! Plus qu'à trouver le temps de comprendre le soft et de jouer avec, mais c'est vraiment un soulagement car je faisais du sur place depuis un bout de temps.

SpigoloN;1064439 a dit:

Hourra!!! Plus qu'à trouver le temps de comprendre le soft et de jouer avec, mais c'est vraiment un soulagement car je faisais du sur place depuis un bout de temps.

Cliquez pour agrandir...

Oui je comprend bien (pour être passé par là aussi) que cela peut être très frustrant, heureusement que tout est bien qui finit mieux.

Pour le Soft, un jour peut être j'écrirai la doc ...

Mais tu peux regarder les clients tu auras une idée des appels a réaliser pour sortir des valeurs.

Hi again,

I'm back home and I connected both serial cables:
- from StorkAir to raspi
- and from raspi to CCEase

Unfortunately, as soon as CCEase is disconnected from StorkAit unit, serial port is deactivated (no voltage).
I can get some readings only when raspi is connected in parallel with CCEase but it's for sure not the right way to do. Below is what I get in logfiles:

FileLog_VMC:
2015-12-18_12:11:43 VMC Stufe: niedrig
2015-12-18_12:11:43 VMC Zuluft_aktiv: 1
2015-12-18_12:11:43 VMC Proz_Abluft_hoch: 70
2015-12-18_12:11:43 VMC Proz_Zuluft_hoch: 70
2015-12-18_12:11:45 VMC Temp_Enthalpie: -20
2015-12-18_12:11:45 VMC Feucht_Enthalpie: 0
2015-12-18_12:11:45 VMC Analog1_Proz: 0
2015-12-18_12:11:45 VMC Analog2_Proz: 0
2015-12-18_12:11:45 VMC Koeff_Enthalpie: 0
2015-12-18_12:11:45 VMC Timer_Enthalpie: 0
2015-12-18_12:11:45 VMC Analog1_Zu_Wunsch: 0
2015-12-18_12:11:45 VMC Analog1_Ab_Wunsch: 0
2015-12-18_12:11:45 VMC Analog2_Zu_Wunsch: 0
2015-12-18_12:11:45 VMC Analog2_Ab_Wunsch: 0
2015-12-18_12:11:45 VMC Analog3_Proz: 0
2015-12-18_12:11:45 VMC Analog4_Proz: 0
2015-12-18_12:11:45 VMC Analog3_Zu_Wunsch: 0
2015-12-18_12:11:45 VMC Analog3_Ab_Wunsch: 0
2015-12-18_12:11:45 VMC Analog4_Zu_Wunsch: 0
2015-12-18_12:11:45 VMC Analog4_Ab_Wunsch: 0
2015-12-18_12:11:47 VMC Bypass_Faktor: 0
2015-12-18_12:11:47 VMC Bypass_Stufe: 0
2015-12-18_12:11:47 VMC Bypass_Korrektur: 0
2015-12-18_12:11:47 VMC Bypass_Sommermodus: nein
2015-12-18_12:16:47 VMC Proz_Abluft_abwesend: 15
2015-12-18_12:16:47 VMC Proz_Abluft_niedrig: 35
2015-12-18_12:16:47 VMC Proz_Abluft_mittel: 50
2015-12-18_12:16:47 VMC Proz_Zuluft_abwesend: 15
2015-12-18_12:16:47 VMC Proz_Zuluft_niedrig: 35
2015-12-18_12:16:47 VMC Proz_Zuluft_mittel: 50
2015-12-18_12:16:47 VMC Proz_Abluft_aktuell: 35
2015-12-18_12:16:47 VMC Proz_Zuluft_aktuell: 35
2015-12-18_12:16:47 VMC Stufe: niedrig
2015-12-18_12:16:47 VMC Zuluft_aktiv: 1
2015-12-18_12:16:47 VMC Proz_Abluft_hoch: 70
2015-12-18_12:16:47 VMC Proz_Zuluft_hoch: 70
2015-12-18_12:21:43 VMC Bypass_Faktor: 0
2015-12-18_12:21:43 VMC Bypass_Stufe: 0
2015-12-18_12:21:43 VMC Bypass_Korrektur: 0
2015-12-18_12:21:43 VMC Bypass_Sommermodus: nein

Logfile:
2015.12.18 12:21:43 3: VMC: timeout waiting for reply expecting 00ce Request was 07f000cd007a070f
2015.12.18 12:21:43 3: VMC: read did not get expected reply (000c) but 003c
2015.12.18 12:21:45 3: VMC: timeout waiting for reply expecting 000c Request was 07f0000b00b8070f
2015.12.18 12:21:45 3: VMC: read did not get expected reply (00d2) but 003c
2015.12.18 12:21:47 3: VMC: timeout waiting for reply expecting 00d2 Request was 07f000d1007e070f
2015.12.18 12:26:41 3: VMC: read did not get expected reply (00ce) but 003c
2015.12.18 12:26:43 3: VMC: timeout waiting for reply expecting 00ce Request was 07f000cd007a070f
2015.12.18 12:26:43 3: VMC: read did not get expected reply (00e0) but 00e2
2015.12.18 12:26:45 3: VMC: timeout waiting for reply expecting 00e0 Request was 07f000df008c070f
2015.12.18 12:26:45 3: VMC: read did not get expected reply (000c) but 00e0
2015.12.18 12:26:47 3: VMC: timeout waiting for reply expecting 000c Request was 07f0000b00b8070f
2015.12.18 12:26:47 3: VMC: read did not get expected reply (00d2) but 00e0
2015.12.18 12:26:49 3: VMC: timeout waiting for reply expecting 00d2 Request was 07f000d1007e070f

In general, it seems there's only kind of one way communication. I did try to change RS232-Modus to PC-Master but it always remains on "nur-CC-Ease"

How did you manage to set the proper connection? TX and RX are correct, and to be sure I'd changed them to opposite but it didn't help...

I played a bit with enabling and disabling I2C and SPI functionality in raspi-config. To my big surprise it does nothing. Regardless above settings I get:

sudo ./client3.py
connecting to 127.0.0.1 port 10003
requesting data 0

{
"config": {
"actif": {
"P10": "actif",
"P11": "actif",
"P12": "actif",
"P13": "actif",
"P14": "actif",
"P15": "actif",
"P16": "actif",
"P17": "actif",
"P18": "actif",
"P19": "actif",
"P90": "actif",
"P91": "actif",
"P92": "actif",
"P93": "actif",
"P94": "actif",
"P95": "actif",
"P96": "actif"
},
"bypass": "present",
"confofond": "absent",
"enthalpie": "non reglemente",
"prechauffage": "present",
"taille": "undef",
"type": "undef",
"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": 12.5,
"Tconfort": 24.0,
"Textrait": 13.5,
"Trepris": 19.5,
"Tsoufflage": 18.0,
"capteur": {
"TEnthalpie": "absent",
"Tairneuf": "present",
"Tappoint": 0.0,
"Tapppoint": "absent",
"Tenthaplie": 0.0,
"Textrait": "present",
"Thotte": 0.0,
"Trepris": "present",
"Tsoufflage": "present"
}
},
"usage": {
"absent": 1503,
"antigel": 0,
"bypass": 9576,
"filtres": 3,
"prechauffe": 12,
"vitesse1": 18116,
"vitesse2": 9963,
"vitesse3": 0
},
"valvesetat": {
"bypass": 0,
"courantmoteurbypass": 0,
"courantmoteurprechauf": 0,
"prechauff": 0
},
"ventilateurs": {
"extraitpourcent": 35,
"extraitrpm": 1170,
"soufflagepourcent": 35,
"soufflagerpm": 1211
}
},
"device": {
"firmware": "3.20",
"name": "WHR 950 "
}
}
closing socket

Looks like there's some communication ongoing. I discovered I can change RS232-Modus settings only once after raspi reboot (?). But it doesn't help. CCEase displays only "NC", i guess it means - no communication.
And, on the other hand, raspi gets something with no voltage on serial port in VMC (?).
Now, I'm confused...

And one more thing, for the last 2 weeks I was almost completely offline and now I've noticed that somebody wants to ask me for something...? About dashboard or Yahoo weather panel? Is it still valid question?

That's how my unit's connection board looks alike:


So, I have connected raspi through RJ45 to (through HAT converter - ttyAMA0) Ext.conn. socket and CCEase is connected to USB-RS232 converter - ttyUSB0. Ground is shared between CCEase and USB converter . CCEase RX is connected to TX of USB converter an CCEase TX to RX of USB converter.
What am I doing wrong, maybe I should have used RS232 port, visible on the drawing??

listhor;1065155 a dit:

That's how my unit's connection board looks alike:

So, I have connected raspi through RJ45 to (through HAT converter - ttyAMA0) Ext.conn. socket and CCEase is connected to USB-RS232 converter - ttyUSB0. Ground is shared between CCEase and USB converter . CCEase RX is connected to TX of USB converter an CCEase TX to RX of USB converter.
What am I doing wrong, maybe I should have used RS232 port, visible on the drawing??

Cliquez pour agrandir...

I don't have the luxe version, but I hear that the RS232 port works well.

Make sure that (use raspi-config) the ttyAMA0 is not used or the console.

By the look of the log posted, you might have to swap RX &TX, but I'm not sure about this as you connected both the rasp and the ccease to the unit, the CCEASE sends messages whose answer are unexpectedly received by FHEM, hence the messages.

I2C and SPI are not used by the ttyAMA0, they control other pins of the GPIO.

So verify that ttyAMA0 is not console connected (raspi-config, advanced option, A8 Serial Disable shell and kernel messages on the serial connection )

The first step would be to remove the CCEASE and connect one of the serial (ttyAMA0 or ttyUSB0) to the serial connector of the VMC unit, the VMC.ini should match the tty used.

Start the server and run a client (client3.py), see that the data is returned.

You can set the debug option to 8 (restart server) and look into the /var/log/VMClog.log after running the client to see what's exchanged between the raspi and the VMC unit.

Once you get that running you can check FHEM and proceed with the CCEASE.

listhor;1065136 a dit:

And one more thing, for the last 2 weeks I was almost completely offline and now I've noticed that somebody wants to ask me for something...? About dashboard or Yahoo weather panel? Is it still valid question?

Cliquez pour agrandir...

Cheers, we solved it, it was a cut/paste issue.

Hi jcoenen,

In the meantime, I managed to get, more or less running connection between raspi and VMC unit. I don't know why but ttyAMA0 was again console connected (I remember I disabled it at the beginning).
Anyway, plots are working but I'm not sure it's fully opertional. That's what I get in log

/var/log/VMClog.log

18/12/15 23:14:26 : received 07f000cd007a070f ('172.16.0.15', 38311) from client ('172.16.0.15', 38311) retained is 07f000cd007a070f
18/12/15 23:14:26 : Processing msg from queue ('172.16.0.15', 38311)
18/12/15 23:14:26 : Sending frame 07f000cd007a070f to VMC from Client ('172.16.0.15', 38311)
18/12/15 23:14:26 : Command code: cd reply is True
18/12/15 23:14:26 : expecting a reply
18/12/15 23:14:27 : received from VMC 07f307f000ce0e0f23320f2332232302014646000026070f
18/12/15 23:14:27 : 22 frames received from VMC only one is expected from theread
18/12/15 23:14:27 : frame received from VMC stored in client queue 07f000ce0e0f23320f2332232302014646000026070f
18/12/15 23:14:27 : sending 07f000ce0e0f23320f2332232302014646000026070f to ('172.16.0.15', 38311)
18/12/15 23:14:27 : received 07f000d1007e070f ('172.16.0.15', 38311) from client ('172.16.0.15', 38311) retained is 07f000d1007e070f
18/12/15 23:14:27 : Processing msg from queue ('172.16.0.15', 38311)
18/12/15 23:14:27 : Sending frame 07f000d1007e070f to VMC from Client ('172.16.0.15', 38311)
18/12/15 23:14:27 : Command code: d1 reply is True
18/12/15 23:14:27 : expecting a reply
18/12/15 23:14:27 : received from VMC 07f307f000d209583e4b4f3f0f2828287e070f
18/12/15 23:14:27 : 17 frames received from VMC only one is expected from theread
18/12/15 23:14:27 : frame received from VMC stored in client queue 07f000d209583e4b4f3f0f2828287e070f
18/12/15 23:14:27 : sending 07f000d209583e4b4f3f0f2828287e070f to ('172.16.0.15', 38311)
18/12/15 23:14:27 : received 07f000df008c070f ('172.16.0.15', 38311) from client ('172.16.0.15', 38311) retained is 07f000df008c070f
18/12/15 23:14:27 : Processing msg from queue ('172.16.0.15', 38311)
18/12/15 23:14:27 : Sending frame 07f000df008c070f to VMC from Client ('172.16.0.15', 38311)
18/12/15 23:14:27 : Command code: df reply is True
18/12/15 23:14:27 : expecting a reply
18/12/15 23:14:27 : received from VMC 07f307f000e0070000000000000094070f
18/12/15 23:14:27 : 15 frames received from VMC only one is expected from theread
18/12/15 23:14:27 : frame received from VMC stored in client queue 07f000e0070000000000000094070f
18/12/15 23:14:27 : sending 07f000e0070000000000000094070f to ('172.16.0.15', 38311)
18/12/15 23:14:27 : received 07f0000b00b8070f ('172.16.0.15', 38311) from client ('172.16.0.15', 38311) retained is 07f0000b00b8070f
18/12/15 23:14:27 : Processing msg from queue ('172.16.0.15', 38311)
18/12/15 23:14:27 : Sending frame 07f0000b00b8070f to VMC from Client ('172.16.0.15', 38311)
18/12/15 23:14:27 : Command code: 0b reply is True
18/12/15 23:14:27 : expecting a reply
18/12/15 23:14:27 : received from VMC 07f307f0000c062323061c066895070f
18/12/15 23:14:27 : 14 frames received from VMC only one is expected from theread
18/12/15 23:14:27 : frame received from VMC stored in client queue 07f0000c062323061c066895070f
18/12/15 23:14:27 : sending 07f0000c062323061c066895070f to ('172.16.0.15', 38311)

And when running client3:

pi@garaz ~/raspVMC-master $ sudo ./client3.py
connecting to 172.16.0.15 port 10003
requesting data 0

{
"config": {
"actif": {
"P10": "actif",
"P11": "actif",
"P12": "actif",
"P13": "actif",
"P14": "actif",
"P15": "actif",
"P16": "actif",
"P17": "actif",
"P18": "actif",
"P19": "actif",
"P90": "actif",
"P91": "actif",
"P92": "actif",
"P93": "actif",
"P94": "actif",
"P95": "actif",
"P96": "actif"
},
"bypass": "present",
"confofond": "absent",
"enthalpie": "non reglemente",
"prechauffage": "present",
"taille": "undef",
"type": "undef",
"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": 10.5,
"Tconfort": 24.0,
"Textrait": 11.5,
"Trepris": 19.5,
"Tsoufflage": 17.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": 1503,
"antigel": 0,
"bypass": 9576,
"filtres": 11,
"prechauffe": 12,
"vitesse1": 18123,
"vitesse2": 9963,
"vitesse3": 0
},
"valvesetat": {
"bypass": 0,
"courantmoteurbypass": 0,
"courantmoteurprechauf": 0,
"prechauff": 0
},
"ventilateurs": {
"extraitpourcent": 35,
"extraitrpm": 1137,
"soufflagepourcent": 35,
"soufflagerpm": 1208
}
},
"device": {
"firmware": "3.20",
"name": "WHR 950 "
}
}
closing socket

So, how does it look, is it ok?

But still I can't get CCEase to work together. If it's connected to raspi (through USB-RS232 converter - ttyUSB0) shows only "NC".

And a question to sebcbien, when I set Fibaro VD to connect raspi on server port (in my case 10003), VD doesn't receive any data. Which port to be used, control one (VMC.ini)?

VMC.ini:
[VMC]
device = /dev/ttyAMA0

[ConfoSense]
ctty = /dev/ttyUSB0

[server]
bind =
port = 10003

[control]
port = 10002

[client]
server = 172.16.0.15

[socat]
pty = /tmp/ttyVMC

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

One thought, maybe in order to get CCEase working together, raspi must be connected to RS232PC port on VMC (on the drawing), and CCEase would stay as it is now - to USB-RS232 converter?

VMC website: I moved json* and VMC*.html to:
~ $ ls /var/www/html/
index.html jsoneditor json-tree VMC1.html VMC2.html VMC3.html
But still there's nothing displayed except those buttons on page bottom...

Looks like the raspi connection is operational.

You are missing the CCEASE section in the config file, it should be on yet another port, this new port should then be connecting a socat process to the tty were the CCEASE is connected.

That socat process is not automatically launched by the way, it has to be launched manually.

for the web interface you need to copy the cgi in the cgi dirctory of your apache configuration.

- Change documentroot in /etc/apache2/sites-available/000-default.conf (changement vers /var/www)
- sudo a2enmod cgi
- sudo service apache2 restart

And the cgi should normally be in /usr/lib/cgi-bin

Haven't got much time now, be back later.

You are great!
I had have already everything (json* and VMC*) copied in /var/www/html and cgi were they should be so, I've been missing only to run command: sudo a2enmod cgi and it works! BTW, what does Rndmnt/neuf mean?

I don't know why [CCEASE] section was missing. I haven't edited manually this file.
I added that section (copied from installation file) and now file look like this:

[VMC]
device = /dev/ttyAMA0

[CCEASE]
tty = /dev/ttyUSB0
port = 10001
[control]
port = 10002

[server]
bind =
port = 10003

[client]
server = 172.16.0.15

[socat]
pty = /tmp/ttyVMC

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


What is command to launch additional socat process, isn't included already in server.py?

UPDATE:
VMC.ini looks like that:

[VMC]
device = /dev/ttyAMA0

[CCEASE]
tty = /dev/ttyUSB0
port = 10001
[CONTROL]
port = 10002

[server]
bind = ""
port = 10003

[client]
server = "127.0.0.1"

[socat]
pty = /tmp/ttyVMC

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


"" were missing as well. That's why connections from Fibaro were rejected. It seems now it works, except that CCEase connection, can't figure out socat command...

I'm not sure but I think I've found a small typo in server.py:

# Create a TCP/IP socket
# get server information from configuration
try:
config.get('ConfoSense','port')
CCPort = int(string.replace(config.get('ConfoSense','port'),'"',''))
except:
CCPort = 10001

try:
config.get('control','port')
CTRLPORT = int(string.replace(config.get('Control','port'),'"',''))
except:
CTRLPORT = 10002

Cliquez pour agrandir...

It seems like control section was typed differently and in my case didn't match an entry in VMC.ini and it resulted in "defaulting" to port 10002.
And there's no in server.py section named CCEase but ConfoSense.
Therefore, to match everything, my VMC.ini is as follows:

[VMC]
device = /dev/ttyAMA0

[ConfoSense]
tty = /dev/ttyUSB0
port = 10001

[control]
port = 10002

[server]
bind = ""
port = 10003

[client]
server = "127.0.0.1"

[socat]
pty = /tmp/ttyVMC

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

Cliquez pour agrandir...

Please correct me if I'm wrong...

Well, the upper case might be indeed a bug, as I use the default values, it will not show up during testing, the same goes indeed for the ConfoSense.

So I'll make sure the character of the section match the code in the next releases.

the scout string to use is something like this

socat /dev/ttyAMA0,raw,echo=0,b9600 tcp4-connect:192.168.0.15:10001

replace the string in red with the values of the serial interface connecting the CCEASE and the IP address and port of the server connecting the VMC unit.

To see the traffic on the CCEASE use option -x in socat

listhor;1065489 a dit:

You are great!
I had have already everything (json* and VMC*) copied in /var/www/html and cgi were they should be so, I've been missing only to run command: sudo a2enmod cgi and it works! BTW, what does Rndmnt/neuf mean?

Cliquez pour agrandir...

Rndmnt is efficiency of the heat exchanger, there are two way to compute it one is referred to the air incoming and the other is over air extracted, the result are better in the later and thus used by the manufacturer, I can dig out the formulae for these, I have already posted them some time ago.

The control section was for me to use (debug) and I did not expect user to put the CCEASE to work so soon. Actually, the CCEASE/COMFOSENSE is rendered a bit useless when FHEM or another box kicks in. It is always wise to have only one device in control.

Bonjour,
avez vous une idée des causes d'un rendement plutôt faible ?
Il fait 18°c dans la pièce ou ce trouve la machine.

J'ai le même style de valeurs.
Je pense que c'est OK. Il y a toute une doc sur les rendements plus haut sur ce fil.

Hi everybody,

So, after running:
socat /dev/ttyUSB0,raw,echo=0,b9600 tcp4-connect:172.16.0.15:10001
Connection to CCEase has been restored, but...

In the meantime CGI script lost connection to VMC - seems like no queuing.

LOGS:

Log message before running command (RS232-Modus set to nur-PC)

19/12/15 15:32:12 : expecting a reply
19/12/15 15:32:12 : received from VMC 07f307f0000e0400000000bf070f
19/12/15 15:32:12 : 12 frames received from VMC only one is expected from theread
19/12/15 15:32:12 : frame received from VMC stored in client queue 07f0000e0400000000bf070f
19/12/15 15:32:12 : sending 07f0000e0400000000bf070f to ('127.0.0.1', 43134)
19/12/15 15:32:12 : closing ('127.0.0.1', 43134) after reading no data
19/12/15 15:32:18 : new client connection from ('127.0.0.1', 43137)
19/12/15 15:32:18 : received 07f0000b00b8070f ('127.0.0.1', 43137) from client ('127.0.0.1', 43137) retained is 07f0000b00b8070f
19/12/15 15:32:18 : Processing msg from queue ('127.0.0.1', 43137)
19/12/15 15:32:18 : Sending frame 07f0000b00b8070f to VMC from Client ('127.0.0.1', 43137)
19/12/15 15:32:18 : Command code: 0b reply is True

Cliquez pour agrandir...

Command executed:

20/12/15 08:55:45 : expecting a reply
20/12/15 08:55:46 : received from VMC 07f307f0000c062323061a065a85070f
20/12/15 08:55:46 : 14 frames received from VMC only one is expected from theread
20/12/15 08:55:46 : frame received from VMC stored in client queue 07f0000c062323061a065a85070f
20/12/15 08:55:46 : sending 07f0000c062323061a065a85070f to ('127.0.0.1', 47779)
20/12/15 09:00:33 : New connection for CCEASE/COMFOSENSE from ('172.16.0.15', 39193)
20/12/15 09:00:33 : ConfoSense Request for 07f000370700000000000002ed070f from ('172.16.0.15', 39193)
20/12/15 09:00:33 : Processing msg from queue ('172.16.0.15', 39193)
20/12/15 09:00:33 : Sending frame 07f000370700000000000002ed070f to VMC from Client ('172.16.0.15', 39193)
20/12/15 09:00:33 : Command code: 37 reply is True
20/12/15 09:00:33 : expecting a reply
20/12/15 09:00:34 : received from VMC 07f307f0003c0a8210864f4f06000000e08f070f
20/12/15 09:00:34 : 18 frames received from VMC only one is expected from theread
20/12/15 09:00:34 : frame received from VMC stored in client queue 07f0003c0a8210864f4f06000000e08f070f
20/12/15 09:00:34 : sending 07f0003c0a8210864f4f06000000e08f070f to ('172.16.0.15', 39193)
20/12/15 09:00:34 : ConfoSense Request for 07f000370700000000000003ee070f from ('172.16.0.15', 39193)
20/12/15 09:00:34 : Processing msg from queue ('172.16.0.15', 39193)
20/12/15 09:00:34 : Sending frame 07f000370700000000000003ee070f to VMC from Client ('172.16.0.15', 39193)
20/12/15 09:00:34 : Command code: 37 reply is True
20/12/15 09:00:34 : expecting a reply
20/12/15 09:00:34 : received from VMC 07f307f0003c0a8210864f4f06000000e08f070f
20/12/15 09:00:34 : 18 frames received from VMC only one is expected from theread
20/12/15 09:00:34 : frame received from VMC stored in client queue 07f0003c0a8210864f4f06000000e08f070f
20/12/15 09:00:34 : sending 07f0003c0a8210864f4f06000000e08f070f to ('172.16.0.15', 39193)
20/12/15 09:00:34 : ConfoSense Request for 07f000370700000000000002ed070f from ('172.16.0.15', 39193)
20/12/15 09:00:34 : Processing msg from queue ('172.16.0.15', 39193)
20/12/15 09:00:34 : Sending frame 07f000370700000000000002ed070f to VMC from Client ('172.16.0.15', 39193)
20/12/15 09:00:34 : Command code: 37 reply is True

Cliquez pour agrandir...

CCEase is back alive and I can use it to control VMC.

And Fhem logfile:

2015.12.20 09:00:48 3: VMC: timeout waiting for reply expecting 000c Request was 07f0000b00b8070f
2015.12.20 09:01:32 3: VMC: Timeout2 in ReadAnswer for Stufe
2015.12.20 09:01:32 3: VMC: timeout waiting for reply Request was 07f0009901034a070f
2015.12.20 09:02:54 3: VMC: Timeout2 in ReadAnswer for Stufe
2015.12.20 09:02:54 3: VMC: timeout waiting for reply Request was 07f00099010249070f

Cliquez pour agrandir...

In this case, Fhem works but is less reliable - gets timeouts.

And if I run:
socat /dev/ttyUSB0,raw,echo=0,b9600 tcp4-connect:127.0.0.1:10001
Fhem loose communication completely. I'm confused when I look at logs, is same port used for both, CCEase and VMC??

expecting a reply
20/12/15 09:46:14 : received from VMC 07f307f0003c0a8210ef663f5b000000e054070f
20/12/15 09:46:14 : 18 frames received from VMC only one is expected from theread
20/12/15 09:46:14 : frame received from VMC stored in client queue 07f0003c0a8210ef663f5b000000e054070f
20/12/15 09:46:14 : sending 07f0003c0a8210ef663f5b000000e054070f to ('127.0.0.1', 37105)
20/12/15 09:46:14 : ConfoSense Request for 07f000370700000000000003ee070f from ('127.0.0.1', 37105)
20/12/15 09:46:14 : Processing msg from queue ('127.0.0.1', 37105)
20/12/15 09:46:14 : Sending frame 07f000370700000000000003ee070f to VMC from Client ('127.0.0.1', 37105)
20/12/15 09:46:14 : Command code: 37 reply is True
20/12/15 09:46:14 : expecting a reply
20/12/15 09:46:15 : received from VMC 07f307f0003c0a8210ef663f5b000000e054070f
20/12/15 09:46:16 : 18 frames received from VMC only one is expected from theread
20/12/15 09:46:16 : frame received from VMC stored in client queue 07f0003c0a8210ef663f5b000000e054070f
20/12/15 09:46:16 : sending 07f0003c0a8210ef663f5b000000e054070f to ('127.0.0.1', 37105)
20/12/15 09:46:16 : ConfoSense Request for 07f0003300e0070f from ('127.0.0.1', 37105)
20/12/15 09:46:16 : Processing msg from queue ('127.0.0.1', 37105)
20/12/15 09:46:16 : Sending frame 07f0003300e0070f to VMC from Client ('127.0.0.1', 37105)
20/12/15 09:46:16 : Command code: 33 reply is True

Cliquez pour agrandir...

In general, it seems like queuing doesn't work properly with CCease coms enabled.
BTW, which RS232-Modus setting to be used: nur-PC, PC-Master or any of other?