Opentherm Gateway not showing up in google assistant

[jodur]

Home Assistant release with the issue:

Home Assistant0.82.1

Last working Home Assistant release (if known):

Operating environment (Hass.io/Docker/Windows/etc.):

Raspberry Pi 3, manual installation

Component/platform:

Description of problem:

Climate control doesn't show up in google assistant/home with the opentherm gateway. I have exposed the domain climate!

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

Traceback (if applicable):

Additional information:

[mvn23]

Configuration and debug log would be helpful.

[jodur]

Part configuration.yaml

opentherm_gw:
  device: socket://192.168.39.144:23
  climate: 
    name: Thermostaat    
  monitored_variables:
    - room_setpoint
    - room_temp
    - room_setpoint_ovrd
    - slave_dhw_active
    - slave_flame_on  

google_assistant: !include google.yaml 

google.yaml

project_id: !secret google_project
  exposed_domains:
    - climate
  expose_by_default: false
  entity_config:
    climate.thermostaat:
       name: Thermostaat
       room: Woonkamer
       expose: true 

No error in log so this would not give extra information

[jodur]

By the way, you did great work regarding the OTGW integration in home assistant. I forgot to mention it in my previous post.

[mvn23]

I get the following in the debug log:

2018-11-16 21:56:48 DEBUG (MainThread) [homeassistant.components.google_assistant.smart_home] No mapping for <state climate.thermostat=idle; supported_features=1, current_temperature=15.5, temperature=15.0, max_temp=30.0, target_temp_step=0.5, friendly_name=Thermostat, min_temp=1.0 @ 2018-11-16T21:55:14.495355+01:00> domain

Not sure if that means it's a google_assistant issue or an opentherm_gw issue. Anyone more familiar with google_assistant care to chime in?

EDIT: This seems to be caused by the fact that opentherm_gw does not publish SUPPORT_OPERATION_MODE as it only has 1 operation mode. If I mock support in supported_features the thermostat is shown in Google Home, albeit non-functional since the actual support is not there. It only shows the current room temperature but no way to change/view the setpoint.

The above brings me to the conclusion that this issue will be present with all climate platforms that lack operation mode support. I could fix this in opentherm_gw by adding a single operation mode, but I am reluctant to do so because of UI issues and the fact that keeping the current situation as-is would make SUPPORT_OPERATION_MODE mandatory for all climate devices to have google_assistant support. In my opinion it would be better to mock a single mode of operation within google_assistant and keep the climate platform requirements as they are (see also the comments on home-assistant/home-assistant-polymer#1881).

[jodur]

Ok thnx for the reply. So this should be fixed on the Google assistant component side?

[mvn23]

So this should be fixed on the Google assistant component side?

In my opinion, yes. Climate platforms can exist without operation modes by design. If that changes I will update opentherm_gw accordingly. I may have a go at trying to fix google assistant if nobody else beats me to it, but I'm not very familiar with the component so it could take a while.

[reharmsen]

I am seeing similar problems with the ATAG One Component (see https://github.com/herikw/home-assistant-custom-components/issues/5) Would be nice if this can be fixed in the Google Assistant component

[jodur]

@mvn23 , can't we apply the same fix @reharmsen has used for the Atag component?

[mvn23]

That would work, but it's a workaround at best and does not address the underlying problem. See my previous posts for my reasons not to work around the issue this way for now. Please feel free to modify the source and create your own custom component to suit your needs.

[reharmsen]

@jodur and @mvn23 I created the workaround in the custom Atag component in order to get my own setup working. Next would be to get things fixed in the places it should be fixed.

In me looking into the code (for as far as I understand Python and the buildup of Home-Assistant), I noticed the 'TemperatureSettingTrait' class in trait.py from the google_assistant component.

The class only translates 4 states:

We do not support "on" as we are unable to know how to restore

# the last mode.
hass_to_google = {
    climate.STATE_HEAT: 'heat',
    climate.STATE_COOL: 'cool',
    climate.STATE_OFF: 'off',
    climate.STATE_AUTO: 'heatcool',
}

I am not sure whether other states are returned to google (i guess It does, as before my fix the Atag component did not work), but it might be necessary to limit what can be returned to only the states google will understand.

Also the hass state STATE_AUTO should be mapped to 'auto' and not to 'heatcool' as what is done currently. Next to this, eco and dry should be added into the translation.

[pvries86]

I am running the Hassio image with the opentherm gateway connected via the OTmonitor relay server. If there is anything I can test to find a solution for this, let me know.

[cgarwood]

Closing in favor of #18645

[rubenverhoef]

Is this fixed?? because my OpenTherm Climate Thermostat is not exposed to google assistant.. running 84.3

[pvries86]

I'm running 0.84.6 and it's not working in this version either.

[mvn23]

@cgarwood this should be reopened. #19084 (which closed #18645) did not address the underlying issue: The google assistant integration does not deal with climate entities without operation mode support.

[mvn23]

Try using this file as custom_components/climate/opentherm_gw.py in your config dir to work around this issue for now. Note that this workaround was only subjected to a quick functionality test in Home Assistant without Google Assistant, so no guarantees and use at your own risk.

[rubenverhoef]

Try using this file as custom_components/climate/opentherm_gw.py in your config dir to work around this issue for now. Note that this workaround was only subjected to a quick functionality test in Home Assistant without Google Assistant, so no guarantees and use at your own risk.

No difference for me, not showing up in the Google Home app after an google_assistant.request_sync

[marchingphoenix]

2 things come to mind when comparing the custom component to other climate devices.

1. Only one state is being sent, there is no ability to change the state to off or to heat/cool.
2. For state auto, only one temperature setting is being exposed. Auto is mapped to heat-cool mode in GA which requires a temp high and temp low. (SUPPORT_TARGET_TEMPERATURE_HIGH, SUPPORT_TARGET_TEMPERATURE_LOW, ATTR_TARGET_TEMP_LOW, ATTR_TARGET_TEMP_HIGH)

Recommend either, sending only heat/cool/off as operation modes, or handling auto correctly and sending all of them. Of note, it doesn't look like there is anything wrong in the trait code, GA is just dropping this on the floor due to some validation failing on their side.

[mvn23]

2\. For state auto, only one temperature setting is being exposed. Auto is mapped to heat-cool mode in GA which requires a temp high and temp low.

That hit the nail right on the head. Changing STATE_AUTO to STATE_HEAT fixed it. Gist was updated accordingly.

[rubenverhoef]

2\. For state auto, only one temperature setting is being exposed. Auto is mapped to heat-cool mode in GA which requires a temp high and temp low.

That hit the nail right on the head. Changing STATE_AUTO to STATE_HEAT fixed it. Gist was updated accordingly.

Is it exposed now in your Google home app? Mine is not also with your last gist

[mvn23]

I set up a test environment this afternoon and I was able to control the thermostat through Google Home.

[rubenverhoef]

2\. For state auto, only one temperature setting is being exposed. Auto is mapped to heat-cool mode in GA which requires a temp high and temp low.

That hit the nail right on the head. Changing STATE_AUTO to STATE_HEAT fixed it. Gist was updated accordingly.

Is it exposed now in your Google home app? Mine is not also with your last gist

I did no create the custom_components dir in the correct folder, now it works! It is now showing up in google home app and i can control it, but only when the state is heating, when it is idle i cannot change or see the setpoint. I only can see the current temperature.

[mvn23]

Should work now, but it will always show as state heat.

[rubenverhoef]

Is the state in home-assistant also always heat? Or can it be also inactive? Because I like the inactive/heating state in home-assistant so I can quickly see if it is heating right now.

[mvn23]

I actually found an issue with the opentherm_gw climate platform related to this. Turns out it's using the current_operation to set the state, when the state could be set directly (current_operation == idle does not make sense). Working on a fix now, will update the gist after I file the PR. Unfortunately it still won't fix the Google Assistant integration.

EDIT: updated gist

[rubenverhoef]

I have now just modified it to be always heat state, it works well for now. The only thing is that the state idle/off is more elegant for homeassistant so you can easy see the state. Maybe you/we need to implement the state switching for the google assistant, so it can enable the thermostat when it is idle/off. now the button does nothing or shows the supported states but does not allow to change it because it is not implemented in the opentherm climate right now.

[marchingphoenix]

The true answer lies in home-assistant/architecture#22 Once that is resolved and we can standardize the climate components, this problem will be fixed. Short term, the component should be modified to match what the major climate components are doing to support this properly.

[mvn23]

Thanks for linking the architecture discussion, looks like that will be the way forward in the long term.

Short term, the component should be modified to match what the major climate components are doing to support this properly.

There's no operation mode concept within the OpenTherm Gateway, only the current state of the system. As a result there's no way to make it work two-way. On top of that there's the issue that Google Assistant doesn't support STATE_IDLE. For a short-term solution, there's the custom_component I linked in my earlier posts. It mocks these non-existing operation modes to make it work with Google Assistant, but that seems a bit too hacky to me to release it in the main repo.

[rubenverhoef]

Thanks for linking the architecture discussion, looks like that will be the way forward in the long term.

Short term, the component should be modified to match what the major climate components are doing to support this properly.

There's no operation mode concept within the OpenTherm Gateway, only the current state of the system. As a result there's no way to make it work two-way. On top of that there's the issue that Google Assistant doesn't support STATE_IDLE. For a short-term solution, there's the custom_component I linked in my earlier posts. It mocks these non-existing operation modes to make it work with Google Assistant, but that seems a bit too hacky to me to release it in the main repo.

I agree, the real problem is that Google Assistant is not supporting the current state of the current operation. For example, it cannot display if it is heating or just idle because it is the right temerature.

So if we want to met the google assistant implementation we need to have the status to always heat. I have edited your gist to include only STATE_HEAT and have test it and it works fine. I cannot cool with my system so i have not included STATE_COOL. We can still read the current state in homeassistant if it is heating or idle. Switching from google assistant is not nessasary because it is not supported by opentherm to set an state i think?

Edit: Tested better and HA gives also always the state heating in stead of only when the flame is on. Need to look into that

[rubenverhoef]

I have created this gist. CanCool needs set to True if the system can also cool. This should be handled with HA config instead. Works good for me, HA is showing heating or inactive and Google Assistant is working fine but ofcourse says always heating (or cooling if supported)

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[Swamp-Ig]

Because of the way that google assistant works, the modes on this device don't really map well to google assistant's model of how climate devices work.

Might I suggest implementing turn_on and turn_off, and then with #21842 at least you can say "ok google, turn on device" and have that work.

Same solution as will work with #17559

[mvn23]

There's no concept of 'on' and 'off' within the OpenTherm Gateway. The system is always 'on' and requires only a target temperature to work in its most basic form. If you can control an input_boolean with Google Assistant (not sure if this is possible, otherwise use a command line switch with noop actions) you could create an automation that changes the target temperature according to this input_boolean/switch and use that to turn the heating on or off.

[Swamp-Ig]

OK in this case, the best solution would be to return heatcool for all the custom states that are unknown in GA, and then at least you can change the temp. I can put in a PR to do this. This will fix #17559 as well.

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.