[comfoair] New ComfoAir Binding

@holger_hees thanks for your response. I’m aware that a real parallel control from two devices that are active at the same time is not possible. However, as mentioned by @Rado1, with changing the RS232 mode (switch binding control from OH to CCEase) from the binding should work. (And if I understand your assumption correctly, this should even be possible on the same connector)

@smhaller I can understand your frustration here, but again the communication has not changed. The “problem” here is that the v1 binding did not update the item if the response was not valid (or null). The new binding handles this and updates the item to UNDEF if no valid response is delivered after 5 retries.
According to your logs your ComfoAir constantly sends data not requested by OH and in batches, which can not be handled, neither by the old nor the new binding (this is what I tried to improve with the version posted above). I have really no ideas where the additional requests are coming from, definitely not from the binding.

This is now confusing me. Do you have CCEase or CCSense connected? Or even both?

Nothing has changed here. The CCEase is deactivated when the thing is initialized (before it goes ONLINE) and activated on thing disposal (and of course switched by the bindingControl#activate channel).

Since your devices are working independently, I would assume it is.

I am on OH 2.5.10 still. Answering your questions:

  • Yes, my CCEase work correctly without OH/RS232 connected.
  • Yes, CCEase panel is turned off when I go to control my Comfoair by OH
  • Yes, CCEase working correctly when control switch is set to OFF in OH binding

Your binding working very smoothly :+1:

Holger is right. You can connect OH to RS232 and leave CCEase working - it is possible. But they will not work together because they listen and comunicate to the same bus of Comfoair. If CCEase and OH send a request at different times it looks that everything is OK, but if they send a request at the same time all: Comfoair, CCEase and OH get rubish bytes and Comfoair bus stops working. So it really looks like CCEase and RS232 socket are wires together in Comfoair bus.
That’s why you need to switch CCEase off when you control Comfoair by RS232 socket.

@boehan
Hi Hans

Meanwhile I’ve run a test with your patched version. There is in relation to the behaving no change. I haven’t turned on trace mode in this case. Just run a grep against events.log
comfo_events.txt (35.8 KB)

Everything before 15:00 is normal run without CC Sense connected

at 15:06:05 you can see that I switched control to CC Sense - All items went to UNDEF which is expected.
at 15:06:23 I set OH in control - values coming in but also got set to UNDEF after a while.

FWIW I have experience with both comfoair 350 (cc sense) and 550 (cc ease).
With the 350+cc-sense (OH1/2 + OH1-binding) I could leave the cc-sense wired, and I could switch it on off via the binding (switching who got control OH/ccsense); the display would go off if OH had control.

Wit the 550+ccease I had to disconnect the ccease wiring, else the binding would not work. This was on OH2 with the OH1 binding.
On OH2/3 with the new binding I did not bother fiddling with this again.

After a complete new installation of OH on my raspberry to get rid of any “old” textual configuration issues there is still the topic that the binding works only as long as the CC Sense is DISconnected.

Setup : ComfoAir 550, CC Sense connected. Raspberry connected via D-SUB RS232 to USB adapter (Profilic chipset). RS485 Baud rate 19.200

Here two log files (thanks to SMHaller for helping me on that topic) which show the logs

  1. Until 17.25 : CC Sense is physically disconnected. Showing COMM ERROR
  2. CS Sense connected, OH switch not touched, is shown as activated. CCSense is still showing the display.
  3. CC Sense still connected. OH Switch deactivated. CC Sense showns no difference on the display
  4. CC Sense still connected. OH Switch activated.CC Sense still showing the display. There is also NO Comm error on the display.

With the detached ComfoSense the binding seems to work quite good. But of course it would be nice if we could switch over from Openhab to CC Sense control :wink:
comfoair - 17.25 CCSense connected 17.29 SteuerungAUS 17.30 Steuerung AN.log (534.3 KB)
events - 17.24-30.log (13.0 KB)

Hi Matthias,
the binding correctly sets the RS232 mode on thing initialization/dispose and by using the activation switch. This is handled the same way as in the OH1 binding. What differs from the OH1 binding is that in the old version the itam state was not updated if no correct answer was retrieved, while in the new binding the state is set to UNDEF if the response is not matching the request. IMO this behaviour is desired, since otherwise you never know if the current state is matching the actual value in the device (besides being the only indication of a working connection).
Now it seems to be the case that the deactivation of the CC Sense doesn’t work for all devices or is reactivated by the ComfoAir/CC Sense (SMHaller brought up the idea that it could be dependent on the firmware). So openHAB and CC Sense are sending and receiving data in parallel, and openHAB is not getting the requested response or is receiving a bunch of (unrequested) responses at once and not able to filter out the requested one. The latter case, which seems to be most common in your logs, I tried to improve (LINK). However, this doesn’t solve the root issue of two communication paths on one serial bus and if the deactivation doesn’t work due to hardware restrictions there is not much I can do about.

You can always add a relay to phisicaly connect and disconnect wires from CCEase, and you can controled it by openhab too: if you switch to binding control → open relay, else if switch to CCEase → close relay

Hi Miasko
thats the failback solution for me :slight_smile: And an manual switch for my wife…

This will most probably also be my future setup (Another Qubino more) :slight_smile:

I migrated to OH3 now and the binding works perfect. Even the “is_enthalpy” channel works now, as in the V1 Binding. Thanks for the implementation of the setup values!

short update:

The next version (3.1) of the binding wil bring some minor improvements:

  • channels will not update if bindingControl is OFF. This omits items changing to UNDEF if control is handed over to CCEase/CCSense
  • logic tries to filter requested values from responses that also contain unrequested data. This should improve the behaviour for cases where a deactivation of CCEase/CCSense (due to potential hardware restrictions as discussed above) does not work (BTW, thanks to @Matze_R and @smhaller for their testing efforts). However, a physical deactivation of external controls (e.g. by relais) is still recommended.
  • some other minor fixes (see full PR #9401)

If someone is eager to have this now, JAR-file is available here: https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/addons/bundles/org.openhab.binding.comfoair/3.1.0-SNAPSHOT/org.openhab.binding.comfoair-3.1.0-SNAPSHOT.jar

Hi guys,
I have the ComfoConnect LAN interface installed. Is there any possiblity to get the link to openhab? I understand that this binding here is only working with a serial port?

Hi Jan,
you are right, the current ComfoAir binding only supports serial connections. Additionally, the ComfoConnect LAN interface seems to use a different protocol, so an integration in the current binding probably wouldn’t make much sense technically.
However, there seem to be some efforts on this topic and actual possibilities for integration over MQTT (1 & 2).

Hello Everyone,

in my case i have a ComfoD 350 machine. as i see the main control unit is the same as the comfoair 350. this mainboard (yellow) comes also with a rj45 connector (green), the other board is not part of my comfoD.

i know i can’t control the fanlevel over rs232, as there is a 4 way switch direktly connected, but is it possible to read the values which i can see in the small display in the front over this connection.

i tried to connect to openhab as descripted above with an PL-2303 cable an an rj45 to DB9 adapter, but can’t get any values in openhab. the RX and TX is crossed as i think the connector on my board has the same pins as the the board with the 9-pol connector (wich is not in my comfoD).

anyone has get the connection to work with an comfoD?

thanks.

Hi Jens,
I don’t own a ComfoD but I think the pinout should be the same as for the ComfoAir, which is as shown for the RJ45 connector (from the protocol description):
grafik
Just make sure this matches the DB9 pinout (pins 2, 3, 5; +12V is not needed):


maybe swap RX and TX

BR Hans

thanks for the reply, is solved the problem, i had a shortcut in my self crimped lan cable, and afterwards i traced the serial port in openhab from the console so that openhab it self could not connect. now its working

Greetings! First of all: Thank you very much for your and everybodies effort to develop this binding - after several tries (e.g. with esphome, mqtt-python-solutions, …) this binding is the first realisation, which started to function for me.

I have a WERNIG G90-380 luxe. It is connected via RS232 port and following cable: UGREEN USB / RS232 Seriell PL2303 chipset.

Other cables, e.g. DTech FTDI USB / RS232 Adapter FT232RL Chip did not work.

Running OH 4.0.1 on Raspi 4b.

After installation of the Binding and creation of items all sensors seem to wirk fine!!

But: Only the control of the fan level does not work. It seems that the control item (which uses a kind of rollershutter input from 0 - 100) is not correctly definined (? see the logs - i tried to set it to high, but update was tried to “0”) - but actualy I have no idea what to change, since everything else is working smoothly.

Wernig has 3 different levels - 0 (absent), 1 (low), 2 (medium), 3 (high).

2023-12-22 18:44:03.881 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'ComfoAir_Wohnraumluftung_Steuerung_aktivieren' updated to ON
2023-12-22 18:44:04.086 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'ComfoAir_Wohnraumluftung_Luftungsstufe' updated to 1
2023-12-22 18:44:04.292 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'ComfoAir_Wohnraumluftung_Aussenlufttemperatur' updated to 6 °C
2023-12-22 18:44:04.495 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'ComfoAir_Wohnraumluftung_Zieltemperatur' updated to 23 °C
2023-12-22 18:44:04.694 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'ComfoAir_Wohnraumluftung_Abluftventilator_' updated to 15
2023-12-22 18:44:04.896 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'ComfoAir_Wohnraumluftung_Zuluftventilator_' updated to 15
2023-12-22 18:44:05.102 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'ComfoAir_Wohnraumluftung_Filter_Laufzeit' updated to 1648800 s
2023-12-22 18:44:05.304 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'ComfoAir_Wohnraumluftung_Ablufttemperatur' updated to 19 °C
2023-12-22 18:44:06.710 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'ComfoAir_Wohnraumluftung_Zulufttemperatur' updated to 19.5 °C
2023-12-22 18:44:06.913 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'ComfoAir_Wohnraumluftung_Fortlufttemperatur' updated to 8 °C
2023-12-22 18:44:07.113 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'ComfoAir_Wohnraumluftung_Fehler_Aktuell' updated to No Errors
2023-12-22 18:44:07.315 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'ComfoAir_Wohnraumluftung_Filterfehler' updated to OFF
2023-12-22 18:44:08.911 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Systeminfo_Cpu_Load' updated to 3.9
2023-12-22 18:44:08.914 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Systeminfo_Cpu_Load' changed from 1.4 to 3.9
2023-12-22 18:44:08.917 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Systeminfo_Memory_AvailablePercent' updated to 80.4
2023-12-22 18:44:08.961 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Systeminfo_Storage_AvailablePercent' updated to 71.7
2023-12-22 18:44:17.518 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ComfoAir_Wohnraumluftung_Luftungsstufe' received command 0
2023-12-22 18:44:17.520 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ComfoAir_Wohnraumluftung_Luftungsstufe' predicted to become 0
2023-12-22 18:44:17.524 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'ComfoAir_Wohnraumluftung_Luftungsstufe' updated to 0
2023-12-22 18:44:17.526 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ComfoAir_Wohnraumluftung_Luftungsstufe' changed from 1 to 0

Can anybody help me please?

Newbee fault. I created an input item (knob) with min 0 and max 3 - that works fine. maybe this helps other newbees :wink: Items to enter data - Development / Add-ons - openHAB Community