Skip to content

Releases: zxdavb/ramses_cc

Stable Release

05 Aug 20:49
Compare
Choose a tag to compare

Breaking Changes

This introduces breaking changes to the configuration.yaml file, in addition to those in 0.20.15a. See New Schema, below. It is expected that these are the last changes to the configuration YAML for some while.

The water_heater state is now operating_mode (on/off/auto/boost), and not active (true/false). You can get the active state from:

{{ state_attr("water_heater.stored_hw", "mode").active }}

This is is line with the HA standard schema for water_heater. NB: they are two different things:

  • operating_mode is the means the system uses to deciding to be active, or not, and
  • active is the current 'behaviour' (i.e. the setpoint is below the temperature, and being active is permitted)

Migration

If you are migrating from <0.19.x, you can use the migration method in in release 0.20.15a to skip direct to this release. It is a one-off migration - that is: you don't need to migrate to 0.20.15a before migrating to this release.

You will, however, need to make both sets of changes to configuration.yaml.

Additions / Improvements

Introduction of the Remote entity for HVAC remotes & switches, see the wiki here

In addition:

  • the integration will start with the hand-crafted schema by default, should it not be a subset of the cached schema. That is, if you change your schema, you will not have to restart HA with restore_cache: {restore_schema: false}.
  • improvements to many parsers: 22C9, 22D0, 22F1, 22F3, 2410, 31D9, 31DA, and others
  • less logspam, better friendly names (uses slug correctly)
  • bugfixes, and more coverage/tests

New schema

Please read the wiki here - the main changes are:

  • the schema: node is now removed:
ramses_cc:
  serial_port: /dev/ttyUSB0
  orphans_hvac: [30:111111, 32:333333, 32:555555, 32:666666]
  01:111111:
    system:
      appliance_control: 10:123446
    zones:
      "07": {sensor: 01:111111}

... instead of:

ramses_cc:
  serial_port: /dev/ttyUSB0
  orphans_hvac: [30:111111, 32:333333, 32:555555, 32:666666]
  schema:
    controller: 01:111111
    system:
      appliance_control: 10:123446
    zones:
      "07": {sensor: 01:111111}
  • both the known_list and the block_list are now a dict (no leading -) of dicts (must have a trailing :).
ramses_cc:
  known_list:
    01:123456:
    02:222222:
    13:333333:

... instead of:

ramses_cc:
  known_list:
    - 01:123456
    - 02:222222
    - 13:333333

Bugs Known

22/09/12_1: The binary sensor for the gateway (e.g. 18:140805 status) appears unavailable for some.

22/08/00_1: (maybe fixed by 0.20.22a) I am not sure why this is happening - the code was written to handle this issue:

  File "/config/custom_components/ramses_cc/climate_heat.py", line 138, in hvac_mode
    if self._device.tcs.system_mode[CONF_SYSTEM_MODE] == SystemMode.AWAY:
TypeError: 'NoneType' object is not subscriptable

22/08/00_2: This is under investigation - appears only on startup? The system appears to behave normally otherwise.

  File "/usr/local/lib/python3.10/site-packages/ramses_rf/gateway.py", line 545, in check_filter_lists
    and dev_id != self.pkt_protocol._hgi80[SZ_DEVICE_ID]
AttributeError: 'NoneType' object has no attribute '_hgi80'

Bugs Fixed

Since 0.20.22e:

  • Fixed (ramses_cc): significant reduction in initial convergence of state (fixes 'uses an unknown service')
  • Fixed (ramses_cc): limit device traits to 1st-class citizens (and bugfix)
  • Fixed (ramses_rf): the minimized schema in binary_sensor.18_xxxxxx_status state attrs
  • Fixed (ramses_rf): add resilience, reduce logspam

Since 0.20.22d:

  • Fixed: flame_active was permanently unavailable
  • Fixed: ramses_rf was sending unnecessary RQ|3220 packets

Since 0.20.22c:

  • Improved: much less logspam from client
  • Fixed: climate entities should have precision tenths

Since 0.20.22b:

  • Fixed: fan_info is not a measurement
  • Fixed: most entities should not be assumed_state = True

Since 0.20.22a:

  • Fixed: State max length is 255 characters
  • Library fixes: don't promote dev class to the other domain, correct addr set validation for HVAC

Since 0.20.22:

  • Fan flow rates are now in L/s and not L/min or percentage
  • Configured commands (in configuration.yaml) are no longer overwritten by old cached commands
  • Fan state is now refreshed soon after sending a command
  • Zones min/max temps now hardened against TypeError: 'NoneType' object is not subscriptable
  • Changes to underlying library to (hopefully) stop other: TypeError: 'NoneType' object is not subscriptable
  • Library fixes: _delete_msg: now call_soon(_delete_msg), CODES_OF_HEAT_DOMAIN, add 22E0, 22E5, 22E9, 22F2, 22F4, 313E, 3222 parsers

New Release [BREAKING CHANGES]

04 Jul 22:31
Compare
Choose a tag to compare

Note: You would be better migrating direct to 0.20.22x, rather than go via 0.20.15x.

WARNING: This release is a one-way migration from 0.18.x / 0.19.x. Read everything, and prepare fully: take a backup before installing this release.

There is no supported means to return to an earlier release without subsequently losing some/all of your historical state data.

You must read Breaking Changes, below (it may have changed from the last time you read it).

Overview

This release offers a lot of value, but there are so many changes, that it is unlikely be completely stable. So I need people to install it, and report any bugs, ready for next Winter.

From release 0.20.11, there is added support for ventilation units (e.g. Orcon / Itho).

Unfortunately, I've felt is necessary to rename the integration / change the configuration schema, so people will have to manually migrate their configuration, and take the other steps listed below. The old name/schema will no longer be maintained.

Some of improvements you'll notice are:

  • much (many?) fewer packets transmitted per unit time - especially if you use the restore_cache feature
  • it won't blow the HGI80 rate limit, unless you do multiple back-to-back restarts, without a cache
  • heating zone heat_demand should be more accurate for many edge-cases (UFH is a WIP due to lack of testers)
  • lots of HVAC love, such as all the fan state attributes - this is ongoing/WIP

Unless you enforce_known_list, the block list is enforced by default - please configure a known_list when you can, as a block list is only marginally better than no list at all.

In the short term, after we get this release stable, you'll see:

  • uploading / downloading zone/DHW schedules (yes: and DHW!)
  • controlling HVAC systems via a faked switch

Basic Steps

Migrating from the old name/schema

This process takes about 10-15 minutes. During migration, the entities will have their state history preserved.

Please be familiar with the Breaking Changes, below.

  1. Take a backup of your system.

  2. Disable the Evohome RF integration by commenting-out the evohome_cc: section in your configuration.yaml, and restart HA.

  3. Via HACS, check that Show beta versions is enabled for the Evohome RF integration. If you get an error message, No manifest.json file found, you can ignore it. Then restart HA.

  4. Via HACS, take the offer to update Evohome RF to 0.20.x. If, after clicking on UPDATE, you don't then see Pending Restart, restart HA and try again. Otherwise, restart HA: after that, the integration will be called Ramses CC.

  5. Edit your configuration.yaml, adding ramses_cc:, by renaming evohome_cc: and making any necessary changes (see New Configuration Schema, below) . Restart HA.

  6. Be patient: it will take at least one sync-cycle for you entities to become (un)available. As there is no ramses_cc cache to start with (it isn't migrated), it may take 24 hours for some entities to become available (.e.g. battery_state).

  7. Delete the config/custom_components/evohome_cc folder.

  8. Report any bugs, on the Forum.

Installing the new name/schema from scratch

Unfortunately, even if you are installing ramses_cc from scratch, you will still have to use the migration process, but as follows:

1a. Via HACS, add a custom repository: zxdavb/evohome_cc | Integration. Download the repository (called Evohome_RF), select version 0.18.8, and continue with step 2, above.

Breaking Changes

The custom integration is now called ramses_rf instead of evohome_cc - this is to reflect increasing support for HVAC, as well as CH/DHW.

Warning: If you do not change your configuration.yaml to have ramses_cc: and not evohome_cc:, you may continue to run the older release, and be unaware of it.

In addition, there is a new schema format for configuration.yaml that will affect many systems - this is unfortunate, but the advantages will outweigh the inconvenience.

ramses_cc will not start with an invalid schema.

The slug for ventilation units remotes is now REM (remote), instead of SWI (switch).

New Configuration Schema:

Tip: Always use the most minimal schema you can: see below.

Summary: use restore_cache/ramses_rf/appliance_control/actuators instead of restore_state/config/heating_control/devices.

Beware: devices includes the zone sensor, but actuators must not (most people won't require an actuators key).

(Sorry, there are more changes from 0.20.18)

The new format is:

ramses_cc:
  serial_port: /dev/ttyUSB0
  restore_cache: true

  ramses_rf:
    enable_eavesdrop: false
    enforce_known_list: false

  schema:
    controller: 01:123456
    system:
      appliance_control: 10:123456
    stored_hotwater:
      sensor: 07:123456
      hotwater_valve: 13:123456
      heating_valve: 13:654321
    zones:
      01:
        class: radiator_valve
        sensor: 01:123456
        actuators:
          - 04:123456
          - 04:654321
      02:
        class: zone_valve
        sensor: 34:123456
        actuators:
          - 13:111111

... instead of:

evohome_cc:
  serial_port: /dev/ttyUSB0
  restore_state: true

  config:
    enable_eavesdrop: false
    enforce_known_list: false

  schema:
    controller: 01:123456
    system:
      heating_control: 10:123456
    stored_hotwater:
      sensor: 07:123456
      hotwater_valve: 13:123456
      heating_valve: 13:654321
    zones:
      01:
        class: radiator_valve
        sensor: 01:123456
        devices:
          - 01:123456
          - 04:123456
          - 04:654321
      ...

Use the most minimal schema you can

I strongly recommend to always use the most minimal schema that works for you. For the above example, that would be:

  schema:
    controller: 01:123456
    system:
      appliance_control: 10:123456
    zones:
      01:
        sensor: 01:123456

You can obtain a suggested minimal schema by looking at the extra state attributes of the gateway (the evofw3/HGI80-compatible) device, which will be called 18:123456 configuration or similar.

If you need too, turn eavesdropping on until the gateway has establish that schema. Do not leave eavesdropping on.

New Schema for HVAC:

Devices in orphans_hvac will be instantiated when HA starts, rather than waiting for them to be eavesdropped.

The known_list will specify what type of HVAC device it is, when it is instantiated.

ramses_rf:
  schema:
    orphans_hvac:
      - 32:111111
      - 32:222222
      - 32:333333
      - 32:444444
  known_list:  # NB: is now a dict (no leading -) of dicts (trailing :)
    32:111111: {class: REM, _note: "RF remote"}
    32:222222: {class: FAN, _note: "HRU/WTW, CVE/CVD, PIV"}
    32:333333: {class: HUM, _note: "humidity sensor"}
    32:444444: {class: CO2, _note: "CO2 sensor"}

After Migration:

You can delete the following files/folders:

  • config/custom_components/evohome_cc
  • config/.storage/evohome_cc

Warning: Don't confuse evohome with evohome_cc - they are two distinct files/folders.

New Alpha Release [BREAKING CHANGES]

28 Jun 07:57
Compare
Choose a tag to compare
Pre-release

WARNING: This release is a one-way migration. Read everything, and prepare fully: you must read Breaking Changes, below.

There is no supported means to return to an earlier release without subsequently losing some/all of your historical state data.

Overview

This release offers a lot of value, but there are so many changes, that it is unlikely be completely stable. So I need people to install it, and report any bugs, ready for next Winter.

Unfortunately, I've felt is necessary to rename the integration / change the configuration schema, so people will have to manually migrate their configuration, and take the other steps listed below. The old name/schema will no longer be maintained.

Some of improvements you'll notice are:

  • much (many?) fewer packets transmitted per unit time - especially if you use the restore_cache feature
  • it won't blow the HGI80 rate limit, unless you do multiple back-to-back restarts, without a cache
  • heating zone heat_demand should be more accurate for many edge-cases (UFH is a WIP due to lack of testers)
  • lots of HVAC love, such as all the fan state attributes - this is ongoing/WIP

Unless you enforce_known_list, the block list is enforced by default - please configure a known_list when you can, as a block list is only marginally better than no list at all.

In the short term, after we get this release stable, you'll see:

  • uploading / downloading zone/DHW schedules (yes: and DHW!)
  • controlling HVAC systems via a faked switch

Basic Steps

Migrating from the old name/schema

This process takes about 10-15 minutes. During migration, the entities will have their state history preserved.

Please be familiar with the Breaking Changes, below.

  1. Take a backup of your system.

  2. Disable the Evohome RF integration by commenting-out the evohome_cc: section in your configuration.yaml, and restart HA.

  3. Via HACS, check that Show beta versions is enabled for the Evohome RF integration. If you get an error message, No manifest.json file found, you can ignore it. Then restart HA.

  4. Via HACS, take the offer to update Evohome RF to 0.20.x. If, after clicking on UPDATE, you don't then see Pending Restart, restart HA and try again. Otherwise, restart HA: after that, the integration will be called Ramses CC.

  5. Edit your configuration.yaml, adding ramses_cc:, by renaming evohome_cc: and making any necessary changes (see New Configuration Schema, below) . Restart HA.

  6. Be patient: it will take at least one sync-cycle for you entities to become (un)available. As there is no ramses_cc cache to start with (it isn't migrated), it may take 24 hours for some entities to become available (.e.g. battery_state).

  7. Delete the config/custom_components/evohome_cc folder.

  8. Report any bugs, on the Forum.

Installing the new name/schema from scratch

Unfortunately, even if you are installing ramses_cc from scratch, you will still have to use the migration process, but as follows:

1a. Via HACS, add a custom repository: zxdavb/evohome_cc | Integration. Download the repository (called Evohome_RF), select version 0.18.8, and continue with step 2, above.

Breaking Changes

The integration has changed its name, and the configuration schema has changed. In addition, there are some changes to the names of certain entities.

The custom integration is now called ramses_rf instead of evohome_cc - this is to reflect increasing support for HVAC, as well as CH/DHW.

Warning: If you do not change your configuration.yaml to have ramses_cc: and not evohome_cc:, you may continue to run the older release, and be unaware of it.

In addition, there is a new schema format for configuration.yaml that will affect many systems - this is unfortunate, but the advantages will outweigh the inconvenience.

ramses_cc will not start with an invalid schema.

New Configuration Schema:

Tip: Always use the most minimal schema you can: see below.

Summary: use restore_cache/ramses_rf/appliance_control/actuators instead of restore_state/config/heating_control/devices.

Beware: devices includes the zone sensor, but actuators must not (most people won't require an actuators key).

The new format is:

ramses_cc:
  serial_port: /dev/ttyUSB0
  restore_cache: true

  ramses_rf:
    enable_eavesdrop: false
    enforce_known_list: false

  schema:
    controller: 01:123456
    system:
      appliance_control: 10:123456
      stored_hotwater:
        sensor: 07:123456
        hotwater_valve: 13:123456
        heating_valve: 13:654321
      zones:
        '01':
          class: radiator_valve
          sensor: 01:123456
          actuators:
            - 04:123456
            - 04:654321
        '02':
          class: zone_valve
          sensor: 34:123456
          actuators:
            - 13:111111

... instead of:

evohome_cc:
  serial_port: /dev/ttyUSB0
  restore_state: true

  config:
    enable_eavesdrop: false
    enforce_known_list: false

  schema:
    controller: 01:123456
    system:
      heating_control: 10:123456
      stored_hotwater:
        sensor: 07:123456
        hotwater_valve: 13:123456
        heating_valve: 13:654321
      zones:
        '01':
          class: radiator_valve
          sensor: 01:123456
          devices:
            - 01:123456
            - 04:123456
            - 04:654321
        ...

Other breaking changes:

The two gateway sensors have merged into binary_sensor.18_xxxxxx_status:

  • binary_sensor.18_xxxxxx_config, and
  • binary_sensor.18_xxxxxx_gateway

It may be useful to rename it to binary_sensor.18_xxxxxx_gateway to preserve your automations.

General Tips

Use the most minimal schema you can

I strongly recommend to always use the most minimal schema that works for you. For the above example, that would be:

  schema:
    controller: 01:123456
    system:
      appliance_control: 10:123456
      zones:
        01:
          sensor: 01:123456

You can obtain a suggested minimal schema by looking at the extra state attributes of the gateway (the evofw3/HGI80-compatible) device, which will be called 18:123456 status or similar.

If you need too, turn eavesdropping on until the gateway has establish that schema. Do not leave eavesdropping on.

Use a known_list if you can:

ramses_cc:
  serial_port: /dev/ttyUSB0
  block_list:
    - 01:136410  # neighbour
  known_list:  # zxdavb_production
    - 01:145038: {alias: CTL}
...
  ramses_rf:
    enforce_true_list: false
  schema:
    controller: 01:145038

Be aware: known_list is under ramses_cc: and enforce_known_list under ramses_rf:.

After Migration:

You can delete the following files/folders:

  • config/custom_components/evohome_cc
  • config/.storage/evohome_cc

Warning: Don't confuse evohome with evohome_cc - they are two distinct files/folders.

Known bugs

Stored HW has a heat demand - this is not an attribute of Stored HW - it will be removed.

Latest Beta 0.19.2

15 Mar 20:50
Compare
Choose a tag to compare
Latest Beta 0.19.2 Pre-release
Pre-release

This pre-release includes many changes since 0.19.1:

  • tweaks some HVAC parsers
  • refactors the RF transport stack (QoS, respects duty cycle, avoids Tx during sync)

It is recommended to use the latest pre-release that works for you.

Selected commits

evohome_cc: bumps client only

ramses_rf:

633e73e duty_cycle, track_sync, refactor QoS, tweak dt_now
b4af040 bugfix seqn decorator
8955ea4 tweak dt_now() (used by win32)
bdb170a Add 2411, tweak 4401
0f0951c tweak test eavesdrop device class
5892cfd tweak 1FC9, 31D9
d259687 tweak 10E0

Latest Stable 0.18.8

14 Mar 11:35
Compare
Choose a tag to compare

Overview

This stable release includes only bug fixes since 0.18.8:

  • it includes only a client bump (no changes in the evohome_cc codebase)

It is strongly recommended to use the latest stable release.

Selected commits

Version 0.18.8

evohome_cc: bumps client only

ramses_rf:

b48441c bugfix heat_demand (0 is not falsy)
756e42b bugfix _faked_* attr names
dcbc6b5 bugfix _validate() for complex idx
baa8940 bugfix CTLs wont RP|0008
7cd5767 bugfix set_zone_name API

Version 0.18.7

evohome_cc: bumps client only

ramses_rf:

5be326c tweak HVAC discovery, bugfix send_cmd()
0b23cdf bugfix OTB msgs DB (which completely freezes **ramses_rf**)
a9200b2 mypy, test transform
e75a0a0 refactor devices: split heat + hvac

Old Beta 0.19.1

28 Feb 09:54
Compare
Choose a tag to compare
Old Beta 0.19.1 Pre-release
Pre-release

This pre-release includes the following changes since 0.19.0:

  • bugfixes (esp. for OTB), and
  • refactoring driven by the CH/DHW & HVAC divide
  • mypy work (is picking up unreported bugs)
  • unit tests (new, finally)
  • other code quality work

It includes some autodetection of device class for HVAC devices. It is a big improvement on where we were, but in many cases, the device class will have to be specified via known_devices (I don't expect that this issue will ever be fully resolved).

CH/DHW devices don't have this problem - it is a straight-forward matter to determine their device class.

It is recommended to use the latest pre-release that works for you.

Selected commits

evohome_cc: bumps client only

ramses_rf:

5be326c tweak HVAC discovery, bugfix send_cmd()
0b23cdf bugfix OTB msgs DB (which completely freezes **ramses_rf**)
a9200b2 mypy, test transform
e75a0a0 refactor devices: split heat + hvac