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

Share your Projects!
2793

OK, @galaxy_explorer for this error:

RP --- 01:182924 18:068640 --:------ 000C 006 020800FFFFFF < AssertionError()

…here is the cause:

2022-09-20T20:51:53.642701 063  I --- 63:262143 --:------ 01:182924 12B0 003 020000
2022-09-20T20:52:17.532239 063  I --- 63:262143 --:------ 01:182924 3150 002 0200

What the above means is that there is a TRV called 63:262143 - if should be called 04:xxxxxx!

This is the TRV for Zone 2 - Loft.

This happens occasionally - the most recent other example is an OTB, also called 63:262143.

check your PM

to be clear - the firmware for this device has an invalid device ID.

1 Like
2794

the sensors unavailable are:

  • 10:262143 boiler_output_temp
  • 10:262143 boiler_return_temp
  • 10:262143 ch_max_setpoint
  • 10:262143 ch_setpoint
  • 10:262143 ch_water_pressure
  • 10:262143 dhw_flow_rate
  • 10:262143 dhw setpoint
  • 10:262143 dhw temp
  • max rel modulation
  • 10:262143 outside temp
  • 10:262143 percent
  • 10:262143 value
  • 12:079416 temperature
2795

This is what an OTB supports, below.

Note that the OT device (usually a boiler has to support these too).

Honeywell R8810A:

Functions and Features
ch: max setpoint adjustment
ch: otc control
ch: remote lockout-reset
ch: remote parameters
ch: remote room setpoint
ch: roomtemp control
ch: service/diagnostics
dhw: setpoint adjustment

general: standard ID’s
ID 000:HB0: Master status: CH enable
ID 000:HB1: Master status: DHW enable
ID 000:HB2: Master status: Cooling enable
ID 000:HB3: Master status: OTC active
ID 000:HB5: Master status: Summer/winter mode
ID 000:HB6: Master status: DHW blocking
ID 000:LB0: Slave Status: Fault indication
ID 000:LB1: Slave Status: CH mode
ID 000:LB2: Slave Status: DHW mode
ID 000:LB3: Slave Status: Flame status
ID 001: Control Setpoint i.e. CH water temperature Setpoint (°C)
ID 002:HB0: Master configuration: Smart power
ID 002:LB: Master MemberID Code
ID 003:HB0: Slave configuration: DHW present
ID 003:HB1: Slave configuration: Control type
ID 003:HB4: Slave configuration: Master low-off&pump control
ID 005:HB0: Service request
ID 005:HB1: Lockout-reset
ID 005:HB2: Low water pressure
ID 005:HB3: Gas/flame fault
ID 005:HB4: Air pressure fault
ID 005:HB5: Water over-temperature
ID 005:LB: OEM fault code
ID 006:HB0: Remote boiler parameter transfer-enable: DHW setpoint
ID 006:HB1: Remote boiler parameter transfer-enable: max. CH setpoint
ID 006:LB0: Remote boiler parameter read/write: DHW setpoint
ID 006:LB1: Remote boiler parameter read/write: max. CH setpoint
ID 009: Remote override room Setpoint
ID 010: Number of Transparent-Slave-Parameters supported by slave
ID 012: Size of Fault-History-Buffer supported by slave
ID 014 : Maximum relative modulation level setting (%)
ID 016: Room Setpoint (°C)
ID 017: Relative Modulation Level (%)
ID 018: Water pressure in CH circuit (bar)
ID 019: Water flow rate in DHW circuit. (litres/minute)
ID 024: Room temperature (°C)
ID 025: Boiler flow water temperature (°C)
ID 026: DHW temperature (°C)
ID 027: Outside temperature (°C)
ID 028: Return water temperature (°C)
ID 048: DHW Setpoint upper & lower bounds for adjustment (°C)
ID 049: Max CH water Setpoint upper & lower bounds for adjustment (°C)
ID 056: DHW Setpoint (°C) (Remote parameter 1)
ID 057: Max CH water Setpoint (°C) (Remote parameters 2)
ID 126: Master product version number and type
ID 127: Slave product version number and type

2796

I should also say that ramses_rf will request every message ID that the OTB is not to support - but only if it can’t use the RAMSES II equivalient!

Note: the msg_ids (data ids) are hex, below, most documentation is in decimal.

    OT_TO_RAMSES = {
        # "00": Code._3EF0,  # master/slave status (actuator_state)
        "01": Code._22D9,  # boiler_setpoint
        "0E": Code._3EF0,  # max_rel_modulation_level (is a PARAM?)
        "11": Code._3EF0,  # rel_modulation_level (actuator_state, also Code._3EF1)
        "12": Code._1300,  # ch_water_pressure
        "13": Code._12F0,  # dhw_flow_rate
        "19": Code._3200,  # boiler_output_temp
        "1A": Code._1260,  # dhw_temp
        "1B": Code._1290,  # outside_temp
        "1C": Code._3210,  # boiler_return_temp
        "38": Code._10A0,  # dhw_setpoint (is a PARAM)
        "39": Code._1081,  # ch_max_setpoint (is a PARAM)
    }

There is also a list maintained by the OTGW team here, that is also useful: tclcode.com

@ivovangastel Is this what you have: EMS-OT OpenTherm converter? It is the one that I use.

2797

I will need to make the RAMSES-instead-of-OT thing optional:

ramses_cc:
  ramses_rf:
    use_native_ot: avoid  # always, prefer, avoid, never

Currently it’s avoid, but I am planning to make it prefer.

In the meantime, you can experiment if you wish.

You’ll have to turn on two features:

ramses_cc:
  advanced_features:
    message_events: true  # listen for ramses_cc_message events
    send_packet: true

Then you can send whatever OT messages your like:

service: ramses_cc.send_packet
data:
  device_id: "10:123456"
  verb: RQ
  code: "3220"
  payload: "0080730000"

Above: the 73 is 0x73 or 115 decimal, which is “OEM diagnostic code”, see: ramses_protocol/Opentherm Protocol v2-2.pdf

(4.0 is the latest version, but I only have 2.2, and there isn’t much difference).

Note: the 80 is a parity bit - IIRC it will work without it, but if 80 doesn’t work, use 00.

2798

yes, that is the precise EMS-OT converter i have inbetween my boiler and the OTB.
to read out my EMS bus i use the following: https://github.com/emsesp/EMS-ESP32

2799

First thing: go back to 0.20.22e and see what happens. Do you know how to do that?

I’m sorry - I haven’t got time to explain how, atm.

2800

I have one of those too! (but mine is the old 16 bit version, and I haven’t got it working, presently).

Anyone who wants to send me the latest 32bit/wifi (S32) version is welcome to do so.

Or perhaps people could PayPal me a few £ and I’ll buy one? (I have a very good coffee machine here)

If anyone is interested, PM me.

2801

I changed the config yesterday evening but in my schema I have still this:


schema:
  system:
    appliance_control: null

My heating is still off, is it possible that this is the reason that its still null?

2802

i understood you can upgrade the ESP8266 version to the newer types with an ESP32 mini.
Kees made a wiki about the upgrade: wiki upgrade i have only have the interface board (even older design) i still have it connected via jumper wires. so i could easily made the change from ESP8266 to ESP32. i am willing to paypal you for all your efforts and support. let me know how.

2803

I have been going through my log and I have seen:

2022-09-21 14:42:24.186 WARNING (MainThread) [ramses_rf.protocol.transport] I --- 18:005567 63:262142 --:------ 7FFF 016 0010018360121FE776302E32302E3335 < Active gateway set to: 18:005567
2022-09-21 14:42:37.942 WARNING (MainThread) [ramses_rf.device.heat] RP --- 10:040239 18:005567 --:------ 12F0 003 007FFF < OTB: deprecating code 0x12F0: it appears unsupported

I can simply ignore them?

2804

yes. The first should be an info

2805

Been tuning my config, is this a minimal or do I need to strip some parts out?

ramses_cc:
  serial_port: /dev/ttyUSB0
  restore_cache: true
  packet_log:
    file_name: /config/ramses_cc_packet.log
    rotate_bytes: null
    rotate_backups: 7
  ramses_rf:
    enable_eavesdrop: false
    enforce_known_list: true
  01:223036:
    system:
      appliance_control: 10:040239 
    zones:
      "00": {sensor: 01:223036}
  known_list:
    01:223036:                            # Evohome (Temperature control system)
    04:231770:
    04:231772:
    04:231774:
    04:231776:
    04:050559:
    04:155445:
    04:155403:
    04:081849:
    04:155443:
    04:155407:
    04:155551:
    04:155533:
    04:155537:
    10:040239:                            # OTB
    18:005567:
2806

Ok

So i have stuff and i think its sort of working but i really dont understand what im supposed to be doing with these known lists etc

im using a hgi 80 with an opentherm bridge the controller is in a zone with a trv i have 7 zones one with 2 valves in it. any help greatfully received!

2807

You define each TRV, HGI80 and OTB in the know list.

You can find the info in the sensor schema

2808

ok so where do i find the sensor schema?

you have to talk to me like i have absolutely no idea because i dont

everything just popped up in domoticz and just worked

2809

Go to: /developer-tools/state and filter on “schema”. You would find something like binary_sensor.01_223036_schema, in the attribute list you can find the stuff to add to you known list.

2810

The issue is that the RF comms are relatively unreliable with very poor error detection / correction.

Thus, corrupted but valid packets are common, and many of these have ‘ghost’ device IDs.

Using a known_list (we once used the phrase ‘whitelist’) allows ramses_rf to discard these corrupted packets (and provide for other benefits, such as faking).

I can’t recall how Domoticz did it, but if they’re not using the same technology, either they’re missing out on features (such as auto discovery), or ghost devices are popping up.

I can see that 2. configuration.yaml · zxdavb/ramses_cc Wiki (github.com) needs a bit of tweaking - could someone have a go at it?

Actually, the above is not optimal: instead go to the **18:xxxxxx status binary sensor - the known_list is in there.

NOTE: I am shortly to investigate reports where the above sensor does not appears unless you first list the gateway in teh known list, along with its type:

ramses_cc:
  known_list:
    18:xxxxxx: class: HGI  # or: gateway_interface

image
image424×941 42.8 KB

2811

No.

WHen I do this:

cat .secrets-0.14.x/themystery/2021-06-25_11-30-55.log | grep 000C | python client.py -k parse

I get this:

Schema[01:155341 (evohome)] = {
    "system": {
        "appliance_control": "13:189740"
    },
...

I dunno why it is not working for you. Please PM me a packet log that includes a restart of HA.

2812

I have a regular BDR (13: device) I don’t specify this as appliance_control, nor do I add 18: to known_list in configuration.yaml.

The 18: status sensor is there,but no appliance_control. It all seems to be working as intended.

schema:
  '01:201047':
    system:
      appliance_control: null
    zones:
      '00':
        sensor: '01:201047'
config:
  enforce_known_list: true
known_list:
  - '01:201047':
      class: controller
  - '04:xxxxxx': bunch of them
      class: radiator_valve
  - '13:259021':
      class: electrical_relay
  - '18:070162':
      class: gateway_interface
  - '22:xxxxxx': bunch of them
      class: thermostat
  - '13:032522':
      class: electrical_relay
  - '30:173916':
      class: rf_gateway
  - '34:046925':
      class: thermostat
block_list: []
other_list: []
_is_evofw3: true
device_class: problem
friendly_name: 18:070162 status

Also, the last 3 are specified as orphans_heat: [13:032522, 30:173916, 34:046925] in configuration.yaml, but don’t show up in the 01: schema sensor:

schema:
  system:
    appliance_control: null
  orphans: []
  stored_hotwater: {}
  underfloor_heating: {}
  zones:
    '00':...