`ramses_cc.set_zone_mode` - broken? #163

iMiMx · 2024-02-09T07:38:38Z

hallway_heating_boost_1hour:
  sequence:
    - service: ramses_cc.set_zone_mode
      data:
        entity_id: climate.hallway
        setpoint: '{{ states.input_number.hallway_heating_boost_temperature.state | float }}'
        duration: {minutes: 60}

The above worked on 21.40, in 31.7 it throws an error:

Logger: homeassistant.components.script.hallway_heating_boost_1hour
Source: helpers/script.py:1805
Integration: Scripts (documentation, issues)
First occurred: 07:30:57 (1 occurrences)
Last logged: 07:30:57

hallway_heating_boost_1hour: Error executing script. Invalid data for call_service at pos 1: extra keys not allowed @ data['setpoint']

Checking with Developer Tools -> Services it seems that the below, 'mode' is apparently no longer optional?

service: ramses_cc.set_zone_mode
data:
  entity_id: climate.hallway
  setpoint: 21
  duration: {minutes: 60}

"This service requires field mode, which must be provided under data:"

mode
The permanency of the override. Optional, one of: follow_schedule, advanced_override (until next scheduled setpoint), temporary_override (see: duration and until), or permanent_override (indefinitely).

With 'mode' set it then throws another error:

service: ramses_cc.set_zone_mode
data:
  entity_id: climate.hallway
  setpoint: 21
  mode: temporary_override
  duration: {minutes: 60}

This service requires field until, which must be provided under data:

But this should be 'mutually exlusive' with duration?

until
The end of the temporary_override. Mutually exclusive with duration.

The text was updated successfully, but these errors were encountered:

bluediamond1984 · 2024-02-10T20:17:31Z

It seems a bug in services.yaml. Not every zone_mode accepts all fields, like follow_schedule isn't allowed to have any of them. But duration and until are declared as required.
To fix the issue change the required state to false on line 290 en 299.

raldred · 2024-02-11T23:35:22Z

I get a totally different error

Failed to call service ramses_cc/set_zone_mode. value must be one of ['follow_schedule'] for dictionary value @ data['mode']

zxdavb · 2024-02-18T14:38:18Z

related to #169

zxdavb · 2024-02-29T17:49:15Z

This is teh current test suite, that is passing:

TESTS_SET_ZONE_MODE: dict[str, dict[str, Any]] = {
    "00": {"mode": "follow_schedule"},
    "01": {"mode": "permanent_override", "setpoint": 18.5},
    "02": {"mode": "advanced_override", "setpoint": 19.5},
    "03": {"mode": "temporary_override", "setpoint": 20.5, "duration": {"minutes": 90}},
    "04": {"mode": "temporary_override", "setpoint": 21.5, "duration": {"hours": 3}},
}  # need to add until...

... if there remains an issue, it is in ramses_rf.

zxdavb · 2024-02-29T17:50:35Z

Please re-open this issue if the bug persists after release 0.41.8 (there are two tracks: 0.31.7 and 0.41.7 - 0.31.x will no longer be maintained).

* Initial config flow PoC * Import from yaml is one-off * Update device info as it becomes available and fix entry reload * Majority of config flow now implenented * Lint * Restore support for reading remote commands from known list traits * Working multi-stage serial port config Plus various other tidy-up. * known list fixes * Add missing config translations * Fix adding new entry and provide title for better messaging * Better default serial port handling * Guide user through all config on initial setup * Primary entities use device name * Set entity names via descriptions * Friendly name for controller device * Clearer label for send_packet advanced feature * Lint * remove debug code * Fix discarding legacy restore_cache config on import if not present * Remove example from schema config UI This take up too much room and make maintenance harder. * Ensure unique evohome controller device names * Extend "Controler 01:123456" device naming to all system types * Fix generated sensor entity ID This got corrected behind the scenes before but was incorrect. * Consistent approach to entity ID generation across all domains * Lint * Neaten entity descriptions Explicitly set ramses_rf_attr so we no longer need to default these. * Fix bad merge of message events regex match/search fix * bump to 0.40.x * fix #85 send_pkt fails with 18:730 as dest * Final instead of Final[str] * mypy work * bump to 0.41.7 * Add description to cache clear config options step This helps explain the new immediately clear behaviour as well as why you might want to be doing it in the first place. * initial commit * names should be restored if the schema is not restored * fix #162 * evo_control test * improve evo_control test * tweak evo_control test * add log file for tests * tweak test * tweak test * tweak test log * expose battery ESA more cleanly * use WATER_HEATER_DESCRIPTIONS (for tests) * evocontrol test - add temperature attr to namespace * tidy up * tidy up * tweak test * tidy up tests * mypy * minor tweak of test * doctweak * doctweak * move tests folder * lint * correct .gitignore * add test_setup * doctweak * working test * pre-commit * add virtual RF * tweak test * change required to make tests work * refactor test * tweak meta file * tweak tests * move test data * tweak virtual RF * tweak test data * tweak test * tweak tests * tweak test_data * tweak tests * add services tests * extend tests * bugfix async_unload_entry, and changes for tests * extend ests, mypy tests * requirements fro HA 2024.02.x * tweak manifest.json - add paho-mqtt * possible bugfix #169 * assert fro bug #163 * doctweak * use fixture * add tests * refactor, extend tests * harden service schemas * bugfix DHW_PARAMS schema * add last tests * doctweaks * requirements * isort config * meta data * lint * requirements * update requirements * add logging for config_flow * lint * bump library ver (CP) * tweak tests * mypy fix (can CP) * tweak requirements for HA 2024.3.0 --------- Co-authored-by: Trevor North <trevor@bugsnag.com>

iMiMx · 2024-03-15T07:25:29Z

Upgraded to latest stable (0.31.7.) seems 'mode' which is apparently optional, is not optional.

service: ramses_cc.set_zone_mode
data:
  entity_id: climate.living_room
  setpoint: 22
  duration: {minutes: 60}

This service requires field mode, which must be provided under data:

service: ramses_cc.set_zone_mode
data:
  entity_id: climate.living_room
  setpoint: 22
  duration: {minutes: 60}     
  mode: temporary_override

This service requires field until, which must be provided under data:

No change from the reported issue, with 0.31.7. Downgrading again to 0.21.4, last 'stable' for me.

zxdavb · 2024-03-15T08:22:38Z

Upgraded to latest stable (0.31.7) seems 'mode' which is apparently optional, is not optional.

Version 0.31.11 has been released and it should address this issue. Please let us know if it does not.

No change from the reported issue, with 0.31.7. Downgrading again to 0.21.4, last 'stable' for me.

This is a known bug in 0.31.7.

To be clear - 0.21.4, 0.31.7 and 0.31.11 are all on the 'stable' track, regardless of of being bug-free, or not.

iMiMx · 2024-03-15T09:21:47Z

0.31.11 - still same issue. Downgrading to 0.21.4, where the below works:

service: ramses_cc.set_zone_mode
data:
  entity_id: climate.living_room
  setpoint: 22
  duration:
    minutes: 60

Mode should be optional (it's currently not) and until should be mutually exclusive with duration (it's currently not)

zxdavb · 2024-03-16T11:27:40Z

This is the call I'm using in test/dev:

service: ramses_cc.set_zone_mode
data:
  entity_id: climate.01_123456_02
  setpoint: 21
  duration: {minutes: 60}

... it throws an error: This service requires field mode, which must be provided under data:

But to me, this is obvious that it is mode: temporary_override.

If we add mode:, we get:

service: ramses_cc.set_zone_mode
data:
  entity_id: climate.01_123456_02
  setpoint: 21
  mode: temporary_override 
  duration: {minutes: 60}

... but, it throws an error: This service requires field until, which must be provided under data:

If we use until:, we get:

service: ramses_cc.set_zone_mode
data:
  entity_id: climate.01_123456_02
  setpoint: 21
  mode: temporary_override 
  until: "2024-03-16 14:00:00"

... but, it throws an error: This service requires field duration, which must be provided under data:

If we use duration: and until:, we get:

service: ramses_cc.set_zone_mode
data:
  entity_id: climate.01_123456_02
  setpoint: 21
  mode: temporary_override 
  duration: {minutes: 60}  
  until: "2024-03-16 14:00:00"

... but, it throws an error: Failed to call service ramses_cc.set_zone_mode. extra keys not allowed @ data['duration']. Got None extra keys not allowed @ data['setpoint']. Got None extra keys not allowed @ data['until']. Got None value must be one of [<ZoneMode.SCHEDULE: 'follow_schedule'>] for dictionary value @ data['mode']. Got None

This message should use a str rather than a strEnum.

iMiMx · 2024-03-16T11:31:20Z

Documentation states 'optional'

mode
The permanency of the override. Optional, one of: follow_schedule, advanced_override (until next scheduled setpoint), temporary_override (see: duration and until), or permanent_override (indefinitely).

You add 'mode' it then throws an error about 'until' even with duration set:

duration
The duration of the temporary_override. Mutually exclusive with until.	 {"minutes": 135} 

until
The end of the temporary_override. Mutually exclusive with duration.

zxdavb · 2024-03-16T12:11:42Z

Ok, this is the test suite that I'll attempt to get working:

TESTS_SET_ZONE_MODE_GOOD: dict[str, dict[str, Any]] = {
    "11": {"mode": "follow_schedule"},
    "21": {"mode": "permanent_override", "setpoint": 12.1},
    "31": {"mode": "advanced_override", "setpoint": 13.1},
    "41": {"mode": "temporary_override", "setpoint": 14.1},  # default duration 1 hour
    "52": {"mode": "temporary_override", "setpoint": 15.1, "duration": {"hours": 5}},
    "62": {"mode": "temporary_override", "setpoint": 16.1, "until": _UNTIL},
}
TESTS_SET_ZONE_MODE_FAIL: dict[str, dict[str, Any]] = {
    "00": {},  # #                                                     missing mode
    "12": {"mode": "follow_schedule", "setpoint": 11.2},  # #          *extra* setpoint
    "20": {"mode": "permanent_override"},  # #                         missing setpoint
    "22": {"mode": "permanent_override", "setpoint": 12.2, "duration": {"hours": 5}},
    "23": {"mode": "permanent_override", "setpoint": 12.3, "until": _UNTIL},
    "29": {"setpoint": 12.9},  # #                                     missing mode
    "30": {"mode": "advanced_override"},  # #                          missing setpoint
    "32": {"mode": "advanced_override", "setpoint": 13.2, "duration": {"hours": 5}},
    "33": {"mode": "advanced_override", "setpoint": 13.3, "until": _UNTIL},
    "40": {"mode": "temporary_override"},  # #                         missing setpoint
    "50": {"mode": "temporary_override", "duration": {"hours": 5}},  # missing setpoint
    "59": {"setpoint": 15.9, "duration": {"hours": 5}},  # #           missing mode
    "60": {"mode": "temporary_override", "until": _UNTIL},  # #        missing setpoint
    "69": {"setpoint": 16.9, "until": _UNTIL},  # #                    missing mode
    "79": {
        "mode": "temporary_override",
        "setpoint": 16.9,
        "duration": {"hours": 5},
        "until": _UNTIL
    },
}

zxdavb · 2024-03-16T12:40:57Z

ok, drama is that this is enforced in two places:

services.yaml, and
schemas.py (the voluptuous schemas)

The above code is only testing the latter

zxdavb · 2024-03-16T12:54:01Z

This service requires field mode, which must be provided under data:

I'm going to make mode non-optional. Thus, the above error message is acceptable.

My rationale is as follows. First, it is clear that the mode is:

follow_schedule if: no setpoint
temporary_override if: has duration or until

But what if it has a setpoint, and no duration/until? You could argue it would be until:

next scheduled setpoint -> advanced_override
indefinitely -> permanent_override
for an hour (like a DHW 'boost') -> temporary_override

Easiest way to resolve the argument, to remove all ambiguity, is to make mode required.

Similarly, setpoint is now a required value, if the mode is not follow_schedule.

I will be doing the same for the set_dhw_mode service call.

zxdavb · 2024-03-16T14:32:04Z

And for DHW, we have:

TESTS_SET_DHW_MODE_GOOD = {
    "11": {"mode": "follow_schedule"},
    "21": {"mode": "permanent_override", "active": True},
    "31": {"mode": "advanced_override", "active": True},
    "41": {"mode": "temporary_override", "active": True},  # default duration 1 hour
    "52": {"mode": "temporary_override", "active": True, "duration": {"hours": 5}},
    "62": {"mode": "temporary_override", "active": True, "until": _UNTIL},
}
TESTS_SET_DHW_MODE_FAIL: dict[str, dict[str, Any]] = {
    "00": {},  # #                                                     missing mode
    "12": {"mode": "follow_schedule", "active": True},  # #            *extra* active
    "20": {"mode": "permanent_override"},  # #                         missing active
    "22": {"mode": "permanent_override", "active": True, "duration": {"hours": 5}},
    "23": {"mode": "permanent_override", "active": True, "until": _UNTIL},
    "29": {"active": True},  # #                                       missing mode
    "30": {"mode": "advanced_override"},  # #                          missing active
    "32": {"mode": "advanced_override", "active": True, "duration": {"hours": 5}},
    "33": {"mode": "advanced_override", "active": True, "until": _UNTIL},
    "40": {"mode": "temporary_override"},  # #                         missing active
    "42": {"mode": "temporary_override", "active": False}, # #         missing duration
    "50": {"mode": "temporary_override", "duration": {"hours": 5}},  # missing active
    "59": {"active": True, "duration": {"hours": 5}},  # #             missing mode
    "60": {"mode": "temporary_override", "until": _UNTIL},  # #        missing active
    "69": {"active": True, "until": _UNTIL},  # #                      missing mode
    "79": {
        "mode": "temporary_override",
        "active": True,
        "duration": {"hours": 5},
        "until": _UNTIL
    },
}

NOTE: tests 41/42, and c.f. Zone's 41 - DHW's 41 is what is classically know as a DHW 'boost'

zxdavb · 2024-03-16T14:45:15Z

It is currently unclear to me how I test service.yaml (the developer page in the web UI).

zxdavb mentioned this issue Feb 18, 2024

ramses_cc.set_system_mode eco_boost is being set for 1 hour #169

Closed

zxdavb added a commit that referenced this issue Feb 29, 2024

assert fro bug #163

b45d62f

zxdavb closed this as completed Feb 29, 2024

zxdavb changed the title ~~31.7 - ramses_cc.set_zone_mode - broken?~~ ramses_cc.set_zone_mode - broken? Mar 11, 2024

zxdavb reopened this Mar 15, 2024

zxdavb self-assigned this Mar 16, 2024

zxdavb closed this as completed in 16c1983 Mar 16, 2024

zxdavb added a commit that referenced this issue Mar 16, 2024

fix #163 (CP)

d4d43fe

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

`ramses_cc.set_zone_mode` - broken? #163

`ramses_cc.set_zone_mode` - broken? #163

iMiMx commented Feb 9, 2024 •

edited by zxdavb

Loading

bluediamond1984 commented Feb 10, 2024

raldred commented Feb 11, 2024

zxdavb commented Feb 18, 2024

zxdavb commented Feb 29, 2024

zxdavb commented Feb 29, 2024 •

edited

Loading

iMiMx commented Mar 15, 2024

zxdavb commented Mar 15, 2024 •

edited

Loading

iMiMx commented Mar 15, 2024 •

edited by zxdavb

Loading

zxdavb commented Mar 16, 2024 •

edited

Loading

iMiMx commented Mar 16, 2024 •

edited

Loading

zxdavb commented Mar 16, 2024 •

edited

Loading

zxdavb commented Mar 16, 2024

zxdavb commented Mar 16, 2024 •

edited

Loading

zxdavb commented Mar 16, 2024 •

edited

Loading

zxdavb commented Mar 16, 2024

ramses_cc.set_zone_mode - broken? #163

ramses_cc.set_zone_mode - broken? #163

Comments

iMiMx commented Feb 9, 2024 • edited by zxdavb Loading

bluediamond1984 commented Feb 10, 2024

raldred commented Feb 11, 2024

zxdavb commented Feb 18, 2024

zxdavb commented Feb 29, 2024

zxdavb commented Feb 29, 2024 • edited Loading

iMiMx commented Mar 15, 2024

zxdavb commented Mar 15, 2024 • edited Loading

iMiMx commented Mar 15, 2024 • edited by zxdavb Loading

zxdavb commented Mar 16, 2024 • edited Loading

iMiMx commented Mar 16, 2024 • edited Loading

zxdavb commented Mar 16, 2024 • edited Loading

zxdavb commented Mar 16, 2024

zxdavb commented Mar 16, 2024 • edited Loading

zxdavb commented Mar 16, 2024 • edited Loading

zxdavb commented Mar 16, 2024

`ramses_cc.set_zone_mode` - broken? #163

`ramses_cc.set_zone_mode` - broken? #163

iMiMx commented Feb 9, 2024 •

edited by zxdavb

Loading

zxdavb commented Feb 29, 2024 •

edited

Loading

zxdavb commented Mar 15, 2024 •

edited

Loading

iMiMx commented Mar 15, 2024 •

edited by zxdavb

Loading

zxdavb commented Mar 16, 2024 •

edited

Loading

iMiMx commented Mar 16, 2024 •

edited

Loading

zxdavb commented Mar 16, 2024 •

edited

Loading

zxdavb commented Mar 16, 2024 •

edited

Loading

zxdavb commented Mar 16, 2024 •

edited

Loading