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

[zxdavb (David Bonnes)]

@TheMystery

Unfortunately, ramses_rf cannot discover:

• when the appliance_control: is an OTB (OpenTherm bridge)
• when the zone sensor: is the controller

It cannot ‘discover’, but it could ‘eavesdrop’. However, leaving eavesdropping enabled is a bad idea, and the best thing is to simple specify them in a hand-crafted schema when you know what’s what:

ramses_cc: 
  01:111111: 
    system: 
      appliance_control: 10:123446 # an OTB 
    zones: 
      "07": {sensor: 01:111111} # controller is the sensor

NB:The following applies for controller-as-a-zone-sensor only…

@TheMystery

Does this mean if you use the controller as a temperature sonsor in the [a] zone that you need to set it in the configuration?

No. In fact, there is no real value in doing so, except you have a complete schema.

@TheMystery

The temp for my main zone is available after the migration so i think i don’t have to do anything?

Correct. You don’t have to do anything.

However, for the OTB, it is useful to have it specified in the schema. But equally, it would be useful to simply mention it in the orphans list:

ramses_cc:
  orphans_heat: [10:123446]

Doing either of the above will ensure the device is instantiated early.

If any of that was helpful, perhaps you coudl clarify the Wiki a little?

[zxdavb (David Bonnes)]

@galaxy_explorer

I have a new installation, it works to some extent but I get a few weird errors in the log that I am yet to fully resolve, one of them is this.

The obvious answer is that it is your neighbour’s kit. The solution to that would be to use a known_list.

Honeywell Jasper kit is not well understood - are you near some commercial real estate (like shops/restaurants)? I’d love to know exactly what kit it is…

And this: ‘63:262143’: class: hvac_device shouldn’t be there.

If you like, PM me a packet log, and your configuration.yaml - I’d like to see it.

[zxdavb (David Bonnes)]

@ivovangastel

i am not sure if this gateway transmits all the sensor data an original OT boiler would transmit.

Please list the data you are getting.

[zxdavb (David Bonnes)]

@TheMystery

i had to add my bdr91 to appliance control

You shouldn’t need to add any BDR to the schema by hand (only an OTB).

This is why you should: “Always use the minimal schema you can” (this si available from teh 18:123456_sensor

I strongly suggest you remove it from the schema, disable the schema cache, and restart HA.

ramses_cc:
  restore_cache:
    restore_schema: false
    restore_state:  true

After you restart, set restore_schema: true (so it is ready fro when you might next reboot).

If the BDR doesn’t go back in the schema automatically, your system is mis-configured.

If you wish, PM me your packet log & I’ll check it fro you.

[phdelodder (Philippe Delodder)]

Made a new one:

[zxdavb (David Bonnes)]

@zxdavb

If you wish, PM me your packet log & I’ll check it fro you.

I have the benefit of a packet log you sent me a long while ago - it appear that your system was configured correctly the, and would respond to discovery as expected.

[ivovangastel (Ivo)]

i am receiving the following sensors:

• 10:262143 bit_6_6

• 10:262143 bit_3_7

• 10:262143 ch_active

• 10:262143 dhw_active

• 10:262143 flame_active

• 10:262143 boiler_setpoint

• 10:262143 heat_demand

• 10:262143 oem_code

• 10:262143 rel_modulation_level

• 10:262143 rel_modulation_level_ot

[TheMystery (Johnny)]

Oké i Will remove it from the config and wait a little longer if it appears correctly in the schema.

[zxdavb (David Bonnes)]

@ivovangastel

i noticed i have a lot of sensors of the boiler unavailable

@ivovangastel

i am receiving the following sensors

Which sensors are unavailable?

[wim001]

I also have only these sensors also.

[zxdavb (David Bonnes)]

The OTB has a set list of what is will retrieve from the ‘boiler’ (in your case, the EMS-OT g/w).

OTB will ignore any msg_ids outside of this set (but ramses_rf knows not to ask).

The issue is that the EMS-OT g/w may not tell the OTB this data, even though it knows the answer… In which case, ramses_rf will simply stop asking.

This happens shortly after startup of HA (like withing 10 minutes), so you wont see this if teh packet log wasn’t when HA was started.

[wim001]

[zxdavb (David Bonnes)]

You can look in homeassistant.log fro messages like:

OTB: deprecating code 0x1300: it appears unsupported

[wim001]

This is in the log:

Logger: ramses_rf.entity_base
Source: runner.py:119
First occurred: 20:57:20 (28 occurrences)
Last logged: 21:10:39

No response for task(3220|RP|10:130890|7B): throttling to 1/24h
No response for task(3220|RP|10:130890|0F): throttling to 1/24h
No response for task(3220|RP|10:130890|30): throttling to 1/24h
No response for task(3220|RP|10:130890|31): throttling to 1/24h
No response for task(3220|RP|10:130890|05): throttling to 1/24h

[zxdavb (David Bonnes)]

There you go:

SCHEMA_MSG_IDS: tuple = (
    "03",  # ..3: "Slave configuration",
    "06",  # ..6: "Remote boiler parameter flags",                      # 0x38, 0x39
    "7D",  # 125: "Opentherm version Slave",                            # not native
    "7F",  # 127: "Slave product version number and type",
    # These are STATUS seen RQ'd by 01:/30:, but here to retreive less frequently
    "71",  # 113: "Number of un-successful burner starts",
    "72",  # 114: "Number of times flame signal was too low",
    "74",  # 116: "Number of starts burner",
    "75",  # 117: "Number of starts central heating pump",
    "76",  # 118: "Number of starts DHW pump/valve",
    "77",  # 119: "Number of starts burner during DHW mode",
    "78",  # 120: "Number of hours burner is in operation (i.e. flame on)",
    "79",  # 121: "Number of hours central heating pump has been running",
    "7A",  # 122: "Number of hours DHW pump has been running/valve has been opened",
    "7B",  # 123: "Number of hours DHW burner is in operation during DHW mode",
)

PARAMS_MSG_IDS: tuple = (
    "0E",  # .14: "Maximum relative modulation level setting (%)"
    "0F",  # .15: "Max. boiler capacity (kW) and modulation level setting (%)",
    "30",  # .48: "DHW Setpoint upper & lower bounds for adjustment (°C)",
    "31",  # .49: "Max CH water Setpoint upper & lower bounds for adjustment (°C)",
    "38",  # .56: "DHW Setpoint (°C) (Remote parameter 1)",             # see: 0x06
    "39",  # .57: "Max CH water Setpoint (°C) (Remote parameter 2)",    # see: 0x06
)

STATUS_MSG_IDS: tuple = (
    "00",  # ..0: "Master/Slave status flags",                          # not RAMSES
    "01",  # ..1: "CH water temperature Setpoint (°C)",                 # also R/W
    "11",  # .17: "Relative Modulation Level (%)",
    "12",  # .18: "Water pressure in CH circuit (bar)",
    "13",  # .19: "Water flow rate in DHW circuit. (L/min)",
    "19",  # .25: "Boiler flow water temperature (°C)",
    "1A",  # .26: "DHW temperature (°C)",
    "1B",  # .27: "Outside temperature (°C)",  # TODO: any value here?
    "1C",  # .28: "Return water temperature (°C)",
    # These are error/state codes...
    "05",  # ..5: "Fault flags & OEM codes",                            # not RAMSES
    "73",  # 115: "OEM diagnostic code",                                # not RAMSES
)

[wim001]

How can I restore the sensors that are not availble

This is my config
ramses_cc:
serial_port: /dev/ttyUSB0
orphans_heat: [10:130890]
ramses_rf:
enable_eavesdrop: false
enforce_known_list: true
restore_cache:
restore_schema: false
restore_state: false
01:168864:
system:
appliance_control: 10:130890
scan_interval: 60
packet_log:
file_name: /config/ramses_cc.log
rotate_backups: 7
known_list:
01:168864: # Evo display controller
10:130890: # Opentherm module
04:049816: # Badkamer
04:049818: # Woonkamer
04:049750: # Werkkamer 1ste
04:049814: # Eileen
04:049884: # Gang
04:049746: # Slaapkamer
04:049812: # Werkkamer 2de
18:207134: {class: HGI} # Nanocul

[zxdavb (David Bonnes)]

@wim001

How can I restore the sensors that are not availble

Start with this:

ramses_cc:
  serial_port: /dev/ttyUSB0
ramses_rf:
  enable_eavesdrop: false
  enforce_known_list: true
restore_cache:
  restore_schema: true
  restore_state: true
01:168864:
  system:
    appliance_control: 10:130890
scan_interval: 60
packet_log:
  file_name: /config/ramses_cc.log
  rotate_backups: 7
known_list:
  01:168864: # Evo display controller
  04:049746: # Slaapkamer
  04:049750: # Werkkamer 1ste
  04:049812: # Werkkamer 2de
  04:049814: # Eileen
  04:049816: # Badkamer
  04:049818: # Woonkamer
  04:049884: # Gang
  10:130890: # Opentherm module
  18:207134: {class: HGI} # Nanocul

Please ask a better question. What sensors, specifically? Were they available before? When did they become unavailable.

Some sensors only Tx once per 24h - so keep your cache enabled.

If your referring to the OTB sensors - if they’re being deprecated, then they should never have been available?

[galaxy_explorer]

I did implement a known_list however when I enable this a load of Assertion Errors appear in the HA log - extract below. So if I disable the known_list I get orphan devices, if I enable the known_list I get Assertion Errors

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

RP --- 01:182924 18:068640 --:------ 313F 009 00F9240035140907E6 < AssertionError(F9 unexpected for CTL)
RP --- 01:182924 18:068640 --:------ 313F 009 00F92C0035140907E6 < AssertionError(F9 unexpected for CTL)
RP --- 01:182924 18:068640 --:------ 313F 009 00F90E0135140907E6 < AssertionError(F9 unexpected for CTL)
RP --- 01:182924 18:068640 --:------ 313F 009 00F92B0135140907E6 < AssertionError(F9 unexpected for CTL)
RP --- 01:182924 18:068640 --:------ 313F 009 00F9110235140907E6 < AssertionError(F9 unexpected for CTL)

I will share files in PM.

[wim001]

@zxdavb

Please ask a better question. What sensors, specifically? Were they available before? When did they become unavailable.

The sensors in the list where availble but I tried so many things I lost when
they worked it was with version 2.22 e I thought

sensor.10_130890_ch_water_pressure
sensor.10_130890_dhw_temp
sensor.10_130890_value
sensor.10_130890_boiler_return_temp
sensor.10_130890_ch_max_setpoint
sensor.10_130890_dhw_setpoint

[zxdavb (David Bonnes)]

@galaxy_explorer

I did implement a known_list however when I enable this a load of Assertion Errors appear in the HA log - extract below. So if I disable the known_list I get orphan devices, if I enable the known_list I get Assertion Errors

You can simply/safely ignore these AssertionErrors - I will make a fix at some stage.

What make / model controller is it?

Please send me a 24-48 packet log if you can, this one is too short to be especially useful - it has no 10E0 packets, and no Jasper packets (all packets are logged, regardless of your filtering).