Feature Request: Setpoint differently implemented on T2plus from 2007

[rklueber]

Description of problem:

• using xknx standalone
• using Home-Assistant knx integration

Version information:

• xknx / Home-Assistant release with the issue: 2022.12.5
• last working xknx / Home-Assistant release (if known):

KNX installation:

I am using a Gira TS2plus which implements the setpoint very different from what is implemented in xknx.

In xknx the setpoint is around "zero" ... like [-4,+4]. The Ts2plus has a similar Konzept which is Called "Basis Sollwertverschiebung". Kind of "Base Target Value Setpoint". Actuall this is the target temperature for the comfort mode. For the other modes you define fixed offsets (like away 2°K less and night 7°k less). Say you configured the "Basissollwert" to 22°C the target temperature for comfort mode is set to 22°C, away tp 20°C and night to 15°C.

You can use the GA "Basis Sollwertverschiebung" to move the target temperature for all modes. If you set the GA configured for to a diffferent value it "moves" all the other temperatures. Similar concept like the setpoint, but not in the range [-4,+4], but around the base temperatur [+18,+26].

I see two potential options to implement this ...

1. allow values for setpoint_min and setpoint_shift_min which are above zero to set

  setpoint_shift_min: 18
  setpoint_shift_max: 26

2. add another parameter which is called setpoint_shift_offset
   This value would be added before sending the setpoinmt to the setpoint GA adress and substracted from every value which is received from the bus.

The 1st option seems more consistant to me.

Please allow me to say that I am not capable of implementing this on my own. I was lucky enough to find out/understand what the issue actually is with my TS2plus. I am happy to test if need is.

Let me know your thoughts.

Ralf

[farmio]

Hi 👋!

This sounds very much like #1064 (comment)

For solution 1 to work you'd need

• a GA representing the current target temperature - readable and updated when changing modes
• a GA for the setpoint_shift ("Basis Sollwertverschiebung") readable, writable and updated when changing modes

You can test it by adjusting the schema validation for these values in HA https://github.com/home-assistant/core/blob/3d7a3afca70c0e760ffb2dbf3c72ddec24fa0c0e/homeassistant/components/knx/schema.py#L426

[rklueber]

The last condition is not met. When you change mode, say to away. The device still expects the setpoint range to be the one of the comfort mode.

[rklueber]

I must admit, I dont know enough to even change the schema.py to test if it would work. Sorry. Can someone point me to the obvious?

[core-ssh /]$ find / -name "schema.py"
[core-ssh /]$

  "home_assistant": {
    "installation_type": "Home Assistant OS",
    "version": "2022.12.6",
    "dev": false,
    "hassio": true,
    "virtualenv": false,
    "python_version": "3.10.7",
    "docker": true,
    "arch": "x86_64",
    "timezone": "Europe/Berlin",
    "os_name": "Linux",
    "os_version": "5.15.80",
    "supervisor": "2022.11.2",
    "host_os": "Home Assistant OS 9.4",
    "docker_version": "20.10.19",
    "chassis": "vm",
    "run_as_root": true
  },
...
  "integration_manifest": {
    "domain": "knx",
    "name": "KNX",
    "config_flow": true,
    "documentation": "https://www.home-assistant.io/integrations/knx",
    "requirements": [
      "xknx==2.1.0"
    ],
    "codeowners": [
      "@Julius2342",
      "@farmio",
      "@marvin-w"
    ],
    "quality_scale": "platinum",
    "iot_class": "local_push",
    "loggers": [
      "xknx"
    ],
    "integration_type": "hub",
    "is_built_in": true
  },
  "data": {
    "xknx": {
      "version": "2.1.0",
      "current_address": "1.1.0"
    },
    "config_entry_data": {
      "state_updater": true,
      "rate_limit": 20,
      "individual_address": "1.1.166",
      "multicast_group": "224.0.23.12",
      "multicast_port": 3671,
      "connection_type": "tunneling",
      "local_ip": "10.0.10.8",
      "host": "10.0.10.7",
      "port": 3671,
      "route_back": false
    },

For those with similar coding skills than me ... plus some knowledge on HA and KNX. I did the following workaround. I created an additional setpoin GA in ETS for every climate device which expects [-4 to 4] and put this GA to the climate setpoint adress in knx config.yaml.

I created a KNX sensor for each of this setpoint GA.

I created the following automation.

The effect is that the climate entity form xknx sends teh setpoint to the respective GA on the BUS ... which is received by HA on the respective setpoint sensor. The change of this sensor triggers the following automation.

- id: 3306a453-1475-40c3-afdc-31e91a1f48df
  alias: "setpoint_arbeiten Link"
  trigger:
    - platform: state
      entity_id:
        - sensor.setpoint_kuche
        - input_number.setpoint_kuche
      id: "1/4/20"
      to:
    - platform: state
      entity_id:
        - sensor.setpoint_arbeiten
        - input_number.setpoint_arbeiten
      id: "1/4/21"
      to:

# ...

  condition:
    - condition: template
      value_template: "{{  states(trigger.entity_id) | int(-100) != -100 }}"

  action:
    - service: knx.send
      data:
        address: "{{ trigger.id }}"
        type: temperature
        payload: "{{ 22.0 + states(trigger.entity_id) | float }}"

[farmio]

Easiest way is probably to not mess with your production system, but set up a small test instance on your local PC. See https://developers.home-assistant.io/docs/development_environment
I use the venv method, but others should probably work the same.

@rklueber for your workaround: If you don't need the value on the bus, you can use internal GAs. Just use a string starting with "i-" (eg. i-my_funny_setpoint_shift) instead of 1/2/3. This will work as input for a sensor, in services and everywhere in HA, but nothing is sent to the bus.

Does this work in all modes?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please make sure to update to the latest version of xknx (or Home Assistant) and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.