Zehnder ComfoAir CA350 integration via serial connection (RS232) and MQTT

Share your Projects!
184

Since I was finally able to start getting MQTT data from the unit - I am now trying to create the lovelace cards…
Funny enough out of the following two cards:

  1. https://github.com/TimWeyand/lovelace-comfoair
  2. https://github.com/mweimerskirch/lovelace-hacomfoairmqtt

I am only able to configure the 2nd one.

For the 1st card - I’m getting an empty card (like it was already shared in this thread):

image
image984×937 120 KB

NOTE: I have already corrected the background_image path in the JS…

I feel I’m close to finally getting it :)!

185

I’m only using this one

186

Looking at the values published by MQTT, I’m wondering if my understanding of each temperature value is correct:

image
image319×941 15.9 KB

The temperatures seems to be mixed-up, the “Outside Temperature” is definitelly not 17.5C now (my other sensors tell me it’s actually 3C now). So how should I understand the values for “Outside”, “Supply” or “Exhaust”?

Silly question, I know but when viewing it in the card it looks strange:
image

ALSO: How can I read the fan_mode? That is, when I check for state of climate.ca350_climate I only get “Fan only” - but how do I obtain which fan_mode is currently selected?

187

In case anyone finds it useful, here’s a simple Picture Element card with a template:
image

type: picture-elements
image: local/images/reku_template.png
elements:
  - type: state-label
    entity: sensor.ca350_supply_fan_speed
    style:
      top: 59%
      left: 73%
      color: gray
  - type: state-label
    entity: sensor.ca350_exhaust_fan_speed
    style:
      top: 59%
      left: 27%
      color: gray
  - type: state-label
    entity: sensor.ca350_outside_temperature
    style:
      top: 20%
      left: 90%
      color: darkred
  - type: state-label
    entity: sensor.ca350_supply_temperature
    style:
      top: 76%
      left: 90%
      color: darkred
  - type: state-label
    entity: sensor.ca350_return_temperature
    style:
      top: 20%
      left: 12.5%
      color: '#4171b1'
  - type: state-label
    entity: sensor.ca350_exhaust_temperature
    style:
      top: 76%
      left: 13%
      color: '#4171b1'
  - type: state-label
    entity: sensor.ca350_bypass_valve
    prefix: 'Bypass: '
    style:
      top: 26%
      left: 50%
      color: gray
  - type: state-label
    entity: number.ca350_filter_weeks
    prefix: 'Change filter in '
    style:
      top: 92%
      left: 50%
      color: gray
  - type: state-label
    entity: sensor.ca350_summer_mode
    style:
      top: 10%
      left: 13%
      color: grey
and the picture: null
1 Like
188

And a link to the picture template is here:

1 Like
189

HI, it looks really nice.
how you defined the number.ca350_filter_weeks, as it isn’t part of the default MQTT data?

190

It is after my recent extensions :slight_smile: You must have missed it. It allows to configure number of weeks after which filter status will change.

191

Just one comment, this is a configuration item, to show the time remaining you would need to deduct the actual time from the number of weeks. You can do it in a template sensor in HA or we could add a calculated one to the ca350 script and publish on mqtt.

192

OMG, I missed it :frowning: (
but now I see it !!! :slight_smile:

image

Please, tell me a little bit more about the logic here.
if I press “PRESS” I reset the filter message on the ComfoAir?
the weeks number is based on the latest press event?

as usual GREAT JOB!!!

193

Filter weeks is a configuration of number of weeks after which the filter needs to be cleaned/replaced
When that time passes the Filter status will change from Ok to Problem. At that point you can use the Reset Filter button so it resets the status of the filter (the Filter hours sensor should reset to 0 - zero). Filter hours shows time passed since filter reset.

194

Got it
I read also your comment in GitHub regarding the documentation, which means that the filter alter is triggered by a “fixed value” of 26 weeks
I also seen the filter hours topic
image

195

As far as I know it should alter after the set “Filter weeks” number of weeks. According to the Zehnder manual it accepts values from 10 to 26 weeks with default being 16 weeks.

196

In recent HA I noticed some warning messages showing up:


2022-03-04 08:19:03 WARNING (MainThread) [homeassistant.components.mqtt.climate] The 'send_if_off' option is deprecated, please remove it from your configuration

2022-03-04 08:19:03 WARNING (MainThread) [homeassistant.components.mqtt.climate] The 'hold_modes' option is deprecated, please remove it from your configuration

Anyone else seeing something similar?

197

Are you using the latest code with HA autodiscovery? Everything works ok for me and no such warnings. Are you using some other climate devices over MQTT? Below is the full config for CA350 climate and the options that are mentioned in your warning messages are not there:

name: CA350 Climate
availability_topic: comfoair/status
payload_available: online
payload_not_available: offline
unique_id: ca350-ca350_climate
device:
  identifiers:
    - ca350
  name: CA350
  manufacturer: Zehnder
  model: ComfoAir 350
temperature_command_topic: comfoair/comforttemp/set
temperature_state_topic: comfoair/comforttemp
current_temperature_topic: comfoair/supplytemp
min_temp: '15'
max_temp: '27'
temp_step: '1'
modes:
  - 'off'
  - fan_only
mode_state_topic: comfoair/ha_climate_mode
mode_command_topic: comfoair/ha_climate_mode/set
fan_modes:
  - 'off'
  - low
  - medium
  - high
fan_mode_state_topic: comfoair/ha_climate_mode/fan
fan_mode_command_topic: comfoair/ha_climate_mode/fan/set
temperature_unit: C
platform: mqtt
198

How have you configured it in HA? Are you relying on the HA auto discovery or you have your code in configuration.yaml? If the latter you have to check it and adapt to the MQTT Climate integration standards but I would highly recommend to get the latest code from github and rely on the auto discovery which works very well.

199

can be related to this?
MQTT climate make publishing state independent by jbouwh · Pull Request #63814 · home-assistant/core (github.com)

200

Probably yes, but this solution does not use this config parameter. Neither it uses the away mode which has been deprecated as well. Unless it is done somehow implicitly that I’m not aware off. Anyway the up to date code which is using the HA auto discovery does not generate those warning messages.

201

Update: I’ve realized that I’ve had log level set to error. Switched that to warning and I can see those errors as well now. I’ll investigate it but I have a feeling that they’ve put this warning for anyone using MQTT Climate devices regardless if the use those options or not.

202

I’ve asked this question here:

203

Update: those warning messages are result of a bug in MQTT integration and will be fixed with this PR: https://github.com/home-assistant/core/pull/67661