I have been looking into that - you need to create a splitter cable which should allow to listen to rx and tx lines on another port of your computer/rpi - you have to google that out. In case you’ll do that there is one function that is not documented in the protocol documentation: the comfosense allows to select which fan is running: only exhaust, only intake or both - but it is not documented what message has to be sent to the unit.
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:
- https://github.com/TimWeyand/lovelace-comfoair
- 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):
NOTE: I have already corrected the background_image path in the JS…
I feel I’m close to finally getting it :)!
I’m only using this one
Looking at the values published by MQTT, I’m wondering if my understanding of each temperature value is correct:
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:
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?
In case anyone finds it useful, here’s a simple Picture Element card with a template:
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
And a link to the picture template is here:
1 Like
HI, it looks really nice.
how you defined the number.ca350_filter_weeks, as it isn’t part of the default MQTT data?
It is after my recent extensions 
You must have missed it. It allows to configure number of weeks after which filter status will change.
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.
OMG, I missed it 
(
but now I see it !!! 
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!!!
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.
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
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.
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?
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
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.
can be related to this?
MQTT climate make publishing state independent by jbouwh · Pull Request #63814 · home-assistant/core (github.com)
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.
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.
I’ve asked this question here: