Honeywell CH/DHW via RF - evohome, sundial, hometronics, chronotherm

In HCE80 cooling feature must be enabled with buttons (once during installation). When it is enabled, cooling mode is activated closing by H/C contact and heating mode is active when H/C contact is open. Digging though many manuals, I haven’t found any mentioning of possibility to activate cooling mode from controller (without closing H/C contact). Although I will try contacting Honeywell support for clarification.

I will try to get one. Although, I have full controll over my heatpump via modbus TCP and there is no digital input for mode switching. So spending 100+EUR for a device which will only force evotouch to send mode switching command and will not be connected anywhere is a bit eh…

Is it possible at least to complete the fake binding to evotouch? In ramses_rf I see the option -X with binding, but did nont yet understood how it works. As I understand BDR91T has ID 13:xxx. I wonder, what evotouch would send if binding process could be completed.

Well, if it would be interesting for you, I could give you access to RPI with RF dongle for several days on separate internet channel when I will receive BDR91T. I guess you could get more information this way when just analyzing packet logs. My heat pump can run independently and while outside temperatures are above -5C you could do whatever you want with the system without causing any problems.

David, apologies if I have this wrong, but can you confirm if this section of the ramses_protocol wiki is correct or not, as I thought FA was DHW.

In the majority of cases, the domain_id is one of:

F9: stored DHW
FA: central heating (circulating volume)
FC: the boiler (or similar)

Also this may be wrong?

The demand is either a percentage (0 to 100), or a boolean (0x00 = on, 0xC8 = off). If a relay/actuator cannot handle partial demands, then any non-zero value is 'on'.

Shouldn’t 0x00 be off, and 0xC8 be on?

I would update the Wiki (dependent upon your response), but don’t have edit permission.

FC is now called appliance controller. It appears that FB is cooling.

Yes.

The ‘partial’ refers to modulation, and that applies only to OTBs (R8810A/R8820A). BDRs can only be on/off - the TPI magic is performed by the controller.

As the relay cannot handle percentages, (IIRC) it treats it as a boolean, and any valid non-zero value is true.

The protocol wiki is sadly, massively, out of date (some of it may even be wrong) - any edits are welcome.

The plan was to make if PR-able - fro now, I will adjust the permissions

What’s worse is that several times, fundamental assumptions were made, and then I subsequently discovered exceptions that required huge re-writes - some took days & days to fix.

For example, I had assumed every device type was indicated by the first two digits of its device ID (e.g. an address starting 02: was a HCC80 / HCE80) - this is true only for CH/DHW & not for HVAC.

(I will respond to your last message later)

I cannot find a BDR91T installation guide / wiring diagram! if someone has a URL they can sign-post me to, I’d be grateful.

@digitallife If I understand correctly, this is how the BDR91T could do changeover (from heat/cool or vice-versa) - you see it’s connecting to terminals 3+4

These terminals are what I previously referred to as H/C contacts. And those mentioned packets are sent by HCE80 when closing and opening these terminals.
I do understand that it possible to implement this as in the diagram you have provided. But from all the advertising of new evohome features I was sure, that evotouch should be able to change the mode of HCE80 wirelessly.
Using wireless relay, to control another wireless device through the wires when both are controlled from the same wireless controller… I wonder what kind of genius designed this.

I have a BRDG-03R13 which is a USB RS485 interface and RF wireless. Can this be used for the integration with HA (in combination with Orcon ventilation unit).

I don’t know - can you TTY to it? Try this: Connect it to a linux system and do something like:

tail -f /dev/ttyUSB0

If you get packets, then you’re on a winner.

I have only ever heard of a BRDG-03M11, which is a repeater… Is the BRDG03-R13 a repeater too? Or something else? I’d be interested in seeing a manual for it.

BTW, Itho systems use the same RAMSES II protocol as everything else, so that will be of no concern.

Yes, that should be possible because I see a serial USB device in Windows. I will connect it to HA this afternoon.

Manual can be found here https://www.airios.eu/brdg-02r13

BTW It’s an Orcon device, not ITHO.

New releases:

  • 0.21.5 now considered stable (let me know if not - in which case, please try 0.21.6).
  • 0.21.6 is recommended, especially if you have multiple controllers
  • 0.22.0 has new features for OTB (R8810A/R8820A), and hackers (message_events)

There are a lot of OTB changes - some are obvious (three new binary sensors), other not. Any questions, just ask.

@zxdavb nice work! :grinning:

Is the “set zone schedule” service working in any of these releases? I recall somewhere on the release notes that it was currently broken? Could you share a JSON schedule service call example?

set_zone_schedule:
  name: Set the Weekly schedule of a Zone
  description: >-
    Upload the zone's weekly schedule from a portable format.

  fields:
    entity_id: *entity_id_zone

    schedule:
      name: Schedule
      description: The weekly schedule of the zone in JSON format.
      required: true
      selector:
        text:
          multiline: true

@zxdavb Was anything fixed regarding this report I made against 0.21.4?

No. I have to fix a timing bug in the RF engine.

Pull requests are welcome :slight_smile:

1 Like

The only fixes I made were for 0.21.4. Are you running that version?

I’ll ask you to install 0.21.6 (you can roll back to 0.21.5 if you need to) & test it then.

Please let me know & I’ll have a look.

I have been running 0.21.5 since it was out.

I’ll check out 0.21.6, thanks.

Hi,

I’ve just updated to 0.22 and got the following error

Logger: homeassistant.config
Source: config.py:835
First occurred: 15:20:48 (1 occurrences)
Last logged: 15:20:48

Invalid config for [ramses_cc]: value None is of the wrong type for a regular expression for dictionary value @ data['ramses_cc']['advanced_features']['message_events']. Got None. (See /config/configuration.yaml, line 21). Please check the docs at https://github.com/zxdavb/ramses_cc

I don’t have any advanced_features set in my config, any idea what I should add?

Thanks

EDIT
adding this into my config fixed it

  advanced_features:
    message_events: None

Same issue for me, after update to 0.22, all entities became unavailable and I could not reboot until I’ve added below, and now all entities are back to normal

  advanced_features:
    message_events: None

My apologies - the work around is valid.

I have fixed this bug (a last-minute regression).

I have updated the release notes.

Nope, sorry. Same issues as with release 0.21.4. Summarising:

remote.learn_command doesn’t show any errors but also seems to do nothing. No new commands are added when I press a button on the remote.

ramses_cc.learn_command gives a trace:

service: ramses_cc.learn_command
data:
  entity_id: remote.29_xxxxxx
  command: away
  timeout: 120

Trace:

Deze fout is ontstaan door een aangepaste integratie.

Logger: homeassistant.helpers.script.websocket_api_script
Source: custom_components/ramses_cc/remote.py:135 
Integration: RAMSES RF (documentation, issues) 
First occurred: 18:55:01 (1 occurrences) 
Last logged: 18:55:01

websocket_api script: Error executing script. Unexpected error for call_service at pos 1: must be exactly one command to learn
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 451, in _async_step
    await getattr(self, handler)()
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 684, in _async_call_service_step
    await service_task
  File "/usr/src/homeassistant/homeassistant/core.py", line 1738, in async_call
    task.result()
  File "/usr/src/homeassistant/homeassistant/core.py", line 1775, in _execute_service
    await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 769, in handle_service
    await service.entity_service_call(
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 678, in entity_service_call
    future.result()  # pop exception if have
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 931, in async_request_call
    await coro
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 715, in _handle_entity_call
    await result
  File "/config/custom_components/ramses_cc/remote.py", line 209, in svc_learn_command
    await self.async_learn_command(*args, **kwargs)
  File "/config/custom_components/ramses_cc/remote.py", line 135, in async_learn_command
    raise TypeError("must be exactly one command to learn")
TypeError: must be exactly one command to learn

I have identified this bug - fix coming.