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

When you change the DHW setpoint on the controller, it broadcasts a dhw_params packet:

|| CTL:145038 |            |  I | dhw_params       |  00  || {'dhw_idx': '00', 'setpoint': 51.5, 'overrun': 0, 'differential': 10.0}

NOTE: what the OTB does with that information is up to it!

In reality, the controller will issue a call (for heat) for DHW (when DHW is scheduled to be enabled), until it receives a signal from the DHW sensor that the measured temperature is at the setpoint.

Edit: to be clear: the controller doesnā€™t tell the OTB the DHW setpoint, it merely tells it to heat the DHW cylinder, or not.

But there are a lot of ways that this can be implemented, beginning with the way it is all wired up.

You can also set the DHW setpoint via OTB (msg_id is 56), and I guess for some systems that might have some effect - but this is not the evohome way.

Thanks. What about for central heating? Is a desired water temperature sent, or some form of demand, such as a percentage?

The controller sends a demand, that is converted into a modulated demand (OTB) or TPI (BDR).

Hi all,

I have evohome system, consisting of HCE80 (7 zones), evotouch and 7x T87RF thermostats.

I am strugling with making this system to work properly with heating/coolong, especially switching between modes. After many emails with Honeywell support I have finally received 19.33 update for my evotouch, which has the capability to switch between heating/cooling and thought that finally everything will work!

Unfortunately notā€¦ HCE80 ignores mode change in evotouch - it seems that it only accepts mode change from H/C input. And evotouch ignores mode change in HCE80. So still need to manually switch both units.

So I bought transceiver, snapped on to arduino and started monitoring communications.

When closing H/C contact (or enabling cooling mode with buttons when H/C contact is closed) on HCE80 it sends following packet:

03:21:20.484 I ā€” 02:044994 --:------ 02:044994 22D0 004 0010000A < AssertionErrorā€¦

When H/C contact is opened, it send the following packet (although this packet is not transmitted, when cooling mode is disabled with buttons):

03:21:24.184 I ā€” 02:044994 --:------ 02:044994 22D0 004 0000000A < AssertionErrorā€¦

As I see in the code, these are not implemented yet, so perhaps may be useful to David.

Unfortunately, when switching heating and cooling in evotouch I havenā€™t noticed any extra packets ā€“ only new setpoints for zones are sent.

Digging in evohome manuals I did not find any suggestions for proper system configuration for heating and cooling. Only in some FAQ it is mentioned, that BDR91T (not an easy purchase) should be used for heat pump switchover. And what about HCE80 H/C contact ā€“ use additional BDR91T to switch contact of HCE80? That would be completely crazy.

So I have few questions:

Would there be a possibility to fake BDR91T and bind it to evotouch. In this case evotouch should send something, what could be used to trigger few cheap wireless relays and change modes of HCE80 and heat pump.

Or perhaps there is a command, which could be sent to evotouch for switching heating and cooling?

P.S. The amount of work on ramses libraries is just staggering!

Hmmā€¦ Sound like a bit flag - cooling_active or some such. BTW, I am not sure what the H/C (heat/cool) contact is.

I do not have a HCE80 to test/dev with, so please PM me a packet log if you wish (preferably annotated).

You really need a BDR91T - I picked one up from eBay last week (so that I could return the one loaned to me) for GBP 15 (including a DTS92!) - so keep an eye out.

The BDR91T supports additional command classes (packet codes) over the BDR91A, including 11F0 and 2D49 - I am afraid they are not well understood (nor is 22D0) - I am waiting for the community to chip in with packet logs.

IIRC, it also has a 2nd switch relay (for hot/cold), and well as the usual on/off (for TPI).

Faking a BDR91 is definitely on the radar, but until these packets are better understood, it would just be a BDR91A.

There are some things you could try - constructed packets, etcā€¦ Iā€™d start with:

W ā€” 18:000730 02:044994 --:------ 22D0 004 0010000A

(would probably need cooling mode enabled with the buttons?)

I canā€™t spare my gen3 evohome controller, but I do have a CM927 floating around - so I coudl have a look at thatā€¦

What would really help if someone with a config like yours, but with a BDR91T, was able to contribute a packet log.

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.