home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
70.47k stars 29.4k forks source link

Climate DPT_HVACStatus ignore heat/cool bit #102739

Closed bussnet closed 9 months ago

bussnet commented 9 months ago

The problem

As defined in the KNX Standard Appendix A (defined here as KNX AN 097/07 rev 3) contains the heat/cool status in the b5 bit, but is not interpreted.

I tested the Comfort b0-b3 bit (comfort, standby, night and frost protection), they worked as expected, but the b5 does not change the hvac_modes attribute from heat to cool if the bit is 0 - hvac_modes stay always to heat.

Same behaviour without the operation_mode_address.

Don't know if it works before, don't use it this way before.

Find a log from the moment I changed the heat/cool flag in the KNX device externally.

What version of Home Assistant Core has the issue?

core-2023.10.5

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

knx

Link to integration documentation on our website

https://www.home-assistant.io/integrations/knx

Diagnostics information

No response

Example YAML snippet

- name: "Arbeit T"
  temperature_address: "3/1/15"
  target_temperature_state_address: "3/2/15"
  command_value_state_address: "3/3/149"
  setpoint_shift_address: "3/3/147"
  setpoint_shift_state_address: "3/3/147"
  setpoint_shift_mode: "DPT9002"
  setpoint_shift_max: 5
  setpoint_shift_min: -5
  temperature_step: 0.5
  controller_status_state_address: "3/4/115"
  operation_mode_address: "3/4/15"

Anything in the logs that might be useful for us?

Logger: homeassistant.helpers.event
Source: helpers/event.py:293
First occurred: 23:08:15 (4 occurrences)
Last logged: 23:13:52

Error while dispatching event for climate.schlafen to <Job track state_changed event {'climate.schlafen'} HassJobType.Callback <bound method TrackTemplateResultInfo._refresh of <TrackTemplateResultInfo {Template<template=({{ state_attr('climate.schlafen', 'command_value') }}/2.55) renders=6>: <RenderInfo Template<template=({{ state_attr('climate.schlafen', 'command_value') }}/2.55) renders=6> all_states=False all_states_lifecycle=False domains=frozenset() domains_lifecycle=frozenset() entities=frozenset({'climate.schlafen'}) rate_limit=None has_time=False exception=None is_static=False>}>>>
Error while dispatching event for climate.schlafen to <Job track state_changed event {'climate.schlafen'} HassJobType.Callback <bound method TrackTemplateResultInfo._refresh of <TrackTemplateResultInfo {Template<template=({{ state_attr('climate.schlafen', 'command_value') }}/2.55) renders=10>: <RenderInfo Template<template=({{ state_attr('climate.schlafen', 'command_value') }}/2.55) renders=10> all_states=False all_states_lifecycle=False domains=frozenset() domains_lifecycle=frozenset() entities=frozenset({'climate.schlafen'}) rate_limit=None has_time=False exception=None is_static=False>}>>>
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 593, in state
    numerical_value = float(value)  # type:ignore[arg-type]
                      ^^^^^^^^^^^^
ValueError: could not convert string to float: '20/2.55'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 293, in _async_dispatch_entity_id_event
    hass.async_run_hass_job(job, event)
  File "/usr/src/homeassistant/homeassistant/core.py", line 636, in async_run_hass_job
    hassjob.target(*args)
  File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 1211, in _refresh
    self.hass.async_run_hass_job(self._job, event, updates)
  File "/usr/src/homeassistant/homeassistant/core.py", line 636, in async_run_hass_job
    hassjob.target(*args)
  File "/usr/src/homeassistant/homeassistant/components/template/template_entity.py", line 429, in _handle_results
    self.async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 779, in async_write_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 879, in _async_write_ha_state
    state, attr = self._async_generate_attributes()
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 820, in _async_generate_attributes
    state = self._stringify_state(available)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 785, in _stringify_state
    if (state := self.state) is None:
                 ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 595, in state
    raise ValueError(
ValueError: Sensor sensor.schlafen_ventil has device class 'None', state class 'None' unit '%' and suggested precision 'None' thus indicating it has a numeric value; however, it has the non-numeric value: '20/2.55' (<class 'str'>)

Additional information

No response

home-assistant[bot] commented 9 months ago

Hey there @julius2342, @farmio, @marvin-w, mind taking a look at this issue as it has been labeled with an integration (knx) you are listed as a code owner for? Thanks!

Code owner commands Code owners of `knx` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign knx` Removes the current integration label and assignees on the issue, add the integration domain after the command.

(message by CodeOwnersMention)


knx documentation knx source (message by IssueLinks)

farmio commented 9 months ago

Hi 👋! Right, only the presets modes are interpreted, the rest is ignored for that DPT. See https://github.com/XKNX/xknx/blob/4ecee64b805dec2ac32ba130b7b855aaf15a2337/xknx/dpt/dpt_hvac_mode.py#L112

bussnet commented 9 months ago

Help needed: The values of this type were retrieved by reverse engineering. Any notes on the correct implementation of this type are highly appreciated.

So, I think this helps: (part of the KNX Spec for this Type) 03_07_02 Datapoint Types v01.08.02 AS.pdf

Anything else needed? I can help to test also (I'm an IT guy, but not familiar with python)

farmio commented 9 months ago

Oh, thank you very much. I didn't mean to refer to that note 😬 (this seems to linger there since >6 years), but to the code / class that would have to be changed to add support for this.

If you don't want to do it yourself, you may open a feature request at https://github.com/XKNX/xknx/issues Please be aware that this DPT is quite rarely used so I wouldn't expect it being picked up next.

bussnet commented 9 months ago

Oh, thank you very much. I didn't mean to refer to that note 😬 (this seems to linger there since >6 years), but to the code / class that would have to be changed to add support for this.

😁 Ah, OK.. I was wondering why an official open spec was not used.

If you don't want to do it yourself, you may open a feature request at https://github.com/XKNX/xknx/issues Please be aware that this DPT is quite rarely used so I wouldn't expect it being picked up next.

I tried several hours to get xknx local running, get the tests working and tried to understand the concept there.

I don't think it make sense that I try do change this concept, because the controller status in xknx could only has a single state, but multiple states in KNX, so this needs to change... or the HEAT/COOL bit should affect the controller_mode?

bussnet commented 9 months ago

I add a FeatureRequest in the XKNX project: https://github.com/XKNX/xknx/issues/1348

farmio commented 9 months ago

Great 👍 Im going to close this one in favor of the new issue.