Skip to content

Add support for Zehnder Comfoconnect LAN C bridge.#7246

Closed
michaelarnauts wants to merge 8 commits into
home-assistant:devfrom
michaelarnauts:comfoconnect
Closed

Add support for Zehnder Comfoconnect LAN C bridge.#7246
michaelarnauts wants to merge 8 commits into
home-assistant:devfrom
michaelarnauts:comfoconnect

Conversation

@michaelarnauts
Copy link
Copy Markdown
Contributor

@michaelarnauts michaelarnauts commented Apr 23, 2017

Description:

This PR adds support for the Zehnder ComfoAir Q350/450/600 ventilation systems. You'll need a ComfoConnect LAN C bridge to interface with it.

The bridge can report sensor data, and you can adjust the ventilation mode (away, low, medium and high).

Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.io#2483

Example entry for configuration.yaml (if applicable):

climate:
  name: ventilation
  platform: comfoconnect
  host: 192.168.1.213

Checklist:

If user exposed functionality or configuration variables are added/changed:

If the code communicates with devices, web services, or third-party tools:

  • Local tests with tox run successfully. Your PR cannot be merged unless tests pass
  • New dependencies have been added to the REQUIREMENTS variable (example).
  • New dependencies are only imported inside functions that use them (example).
  • New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
  • New files were added to .coveragerc.

@mention-bot
Copy link
Copy Markdown

@michaelarnauts, thanks for your PR! By analyzing the history of the files in this pull request, we identified @turbokongen, @balloob and @pvizeli to be potential reviewers.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

line too long (83 > 79 characters)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

line too long (83 > 79 characters)

@michaelarnauts
Copy link
Copy Markdown
Contributor Author

Note I had to remove the ATTR_TEMPERATURE from climate's default state_attributes and add it only if it is present.

This caused the interface to always render the target_temperature picker, also when the platform didn't support setting it.

@michaelarnauts
Copy link
Copy Markdown
Contributor Author

Also note that I had to write a python library for this (https://github.com/michaelarnauts/comfoconnect), and this is my first one. There are so many ways I could have done something wrong there, but it seems to work fine.

Is it safe for example to use threading.Thread in a library? I need it to keep on listening for callback messages.

Copy link
Copy Markdown
Member

@pvizeli pvizeli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leave a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sure that the callback only start after EVENT_HOMEASSISTANT_START event is receive with a event listener (You can also Register the callback inside async_added_to_hass and hass.async_add_job. Make also sure that the callback thread is closing with a EVENT_HOMEASSISTANT_STOP event listener.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The callback thread of comfoconnect is only started when the update is executed (when self._comfoconnect.connect is executed). It is stopped in self._comfoconnect.disconnect in the finally clause. It only stays awake for maximum 5 seconds (during wait_for_sensor_values).

I initially used the EVENT_HOMEASSISTANT_[START|STOP] event, and kept the callback thread open, but the bridge only allows one open connection at the same time, so I decided to stay with polling and open the connection during update.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not needed, remove that and use self.hass they will set on core

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I don't need hass. I will remove it out of the __init__.

@michaelarnauts
Copy link
Copy Markdown
Contributor Author

I've rebased with dev, and the travis errors are gone now.

@michaelarnauts
Copy link
Copy Markdown
Contributor Author

@pvizeli and @turbokongen
is this okay?

}

target_temperature = self.target_temperature
if target_temperature is not None:
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I already mentioned this in the chat, this is not allowed. Please revert this change.

The idea of the climate component is for devices that can control the temperature. If your device can't control the temperature, it is a fan. And so please implement a platform for the fan component.

You can have an extra sensor platform to expose the current temperature.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I didn't know the rule that only temperature controllable things could be climate platforms. This contradicts the climate documentation:

The climate component is built for the controlling and monitoring of HVAC (heating, ventilating, and air conditioning) and thermostat devices.

I will try to find some time to move over to the fan component, although it's unfortunate that that component doesn't support the temperature view.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you implement the temperature as a separate sensor, you get graphs too.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, I've setup my hass to use template sensors and fetch them from the attributes. Works fine!

@michaelarnauts
Copy link
Copy Markdown
Contributor Author

I've moved the platform to the fan component. There still seems to be a frontend since it is also displaying a "Oscillate" toggle, what isn't returned in the supported_features call, I also don't set a direction in my attributes.

data = {}

for key, value in self._data.items():
if key == SENSOR_FAN_SPEED_MODE:
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You won't have to add this to the state attributes, the fan already exposes this.

data[ATTR_OUTSIDE_HUMIDITY] = value

elif key == SENSOR_TEMPERATURE_EXTRACT:
data[ATTR_CURRENT_TEMPERATURE] = value / 10.0
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it make more sense to have these be added as a sensor platform? That way we get graphs and easy to automate against it.

  • Move auth to components/comfoconnect.py and have it store the ComfoConnect object in hass.data
  • add sensor/comfoconnect.py to expose sensors
  • update the fan platform to use the ComfoConnect object in hass.data

_LOGGER.debug('Subscribed to sensors.')

# Wait maximum of 5 seconds for all the sensor values.
self.wait_for_sensor_values(5)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this doing a sleep?

_LOGGER.error('Timeout while waiting for sensor data.')
return

time.sleep(1)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Home Assistant only has 10 threads to do work for synchronous components/platforms. Blocking a thread with a sleep is not allowed. Instead, use track_point_in_time to schedule a function to be called again

@michaelarnauts
Copy link
Copy Markdown
Contributor Author

Alright, I will close this PR for now, since I have to rework some stuff to handle the threads better.

@michaelarnauts michaelarnauts mentioned this pull request Jun 17, 2017
6 tasks
@home-assistant home-assistant locked and limited conversation to collaborators Aug 12, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants