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.
You can look in homeassistant.log fro messages like:
OTB: deprecating code 0x1300: it appears unsupported
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
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
)
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
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?
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.
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
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).
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.
the sensors unavailable are:
This is what an OTB supports, below.
Note that the OT device (usually a boiler has to support these too).
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
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.
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.
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
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.
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.
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?
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.