Skip to content

2.2 Configuration steps 4‐6

Egbert Broerse edited this page Jul 7, 2026 · 2 revisions

Configuration, continued from here

4. Advanced features

screen_advanced

Enable send_packet

Enable send_packet service is an advanced feature. By turning on this switch, you will have the ramses_cc.send_packet service call available in HA. It allows you to broadcast bespoke packets via RF. It may not have value to every user, so is off by default.

The parameters this service call currently accepts are:

service: ramses_cc.send_packet
data:
  device_id: '01:123456'
  from_id: '18:123456'
  verb: RQ
  code: 1F09
  payload: FF

Regex Match Event

By entering the following in the Advanced field, you will have an event triggered whenever a matching message is seen by the integration.

"RP.* 10:"  # regex that matches all packets from an OTB (OpenTherm Bridge)

The value is a regex (regular expression). Clearing the field disables this feature, and the matching events being fired.

In the HA log, you should see:

Before 0.55.6:

2022-11-03 11:26:33.236 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event ramses_cc_message[L]: dtm=2022-11-03T11:26:33.234940, src=10:048122, dst=18:006402, verb=RP, code=3200, payload=temperature=34.8, packet=RP --- 10:048122 18:006402 --:------ 3200 003 000D98>

Since 0.55.6, with regex = I.* 29: for example:

2026-04-16 21:23:19.816 DEBUG (MainThread) [custom_components.ramses_cc.event] handle_event ramses_cc_regex_match, data: 
{'type': <RamsesEventType.REGEX: 'ramses_cc_regex_match'>, 'device_id': '29:099029', 'dtm': '2026-04-16T21:23:19.752926', 'src': '29:099029', 'dst': '29:123456', 'verb': ' I', 'code': '12A0', 'payload': {'indoor_humidity': 0.43}, 'packet': ' I --- 29:123456 --:------ 29:123456 12A0 002 002B'}

Use a HA Automation to listen for these events.

Before 0.55.6: You must listen directly to the event bus for ramses_cc_message:

trigger:
  - platform: state
    entity_id: event.ramses_cc_message
...

Since 0.55.6: Using the Automation UI, create a new automation. As trigger, select Entities > Events, or filter for/select the event.ramses_cc_regex_event entity.

You can create a sensor of a parameter that is not currently exposed to HA by Ramses RF (here, the parameter is temperature_2):

Before 0.55.6:

template:
  - trigger:
      - platform: event
        event_type: "ramses_cc_message"
    sensor:
      - name: "temperature_2"
        state: "{{ trigger.event.data.payload.temperature_2}}"

Since 0.55.6:

template:
- sensor:
    - name: fan_mode
      state: "{{ state_attr( 'event.ramses_cc_regex_event', 'data')['payload']['temperature_2']}}"

5. Packet log

screen_packetlog

A packet log is not required, but can aid troubleshooting and help development.

If your packet log is being populated with packets, you know that your USB gateway is receiving packets OK). To determine if the gateway is transmitting packets OK, you'll have to look for 'echo' packets (note the digits 000 in the RQ):

2023-11-29T11:24:21.764290 000 RQ --- 18:006402 10:048122 --:------ 3220 005 0080730000  # echo packet
2023-11-29T11:24:21.791060 073 RP --- 10:048122 18:006402 --:------ 3220 005 00B0730000  # reply packet

Tip: The first 3-digit number is the RSSI. Anything below 070 is good.

If you use Hass OS, the file path is relative to the config folder. So if you enter

  packet.log

files by that name will appear in the `/config/ folder. You might create a dedicated directory for the log files, as in the example screen shot.

If you use a local repo, enter:

  ~/home-assistant/.config/packet.log

The packet log can be further configured by setting the maximum file size and the number of log files to keep. Unless a maximum size is configured, the packet log is rolled over every midnight and the last 7 logs are retained by default.

6. Manage Caches

  • Clear Cached Schemas
  • Clear Packet Cache
  • Clear Discovery State, see
  • Clear Known Devices List screen_clearcache

Ramses RF will periodically save the current schema and the latest state (the most recent packets). During startup, this data can be restored, and provide for significant gains in performance/UX. It saves this data, even if it is not configured to restore it upon startup of HA.

For troubleshooting, you can prevent the restore of one or the other by turning ON one or both switches and click Send.

After turning on the "Accept packets from known devices only", both caches are automatically cleared.

Next, restart Home Assistant to tell Ramses RF to use the new settings.

Ramses RF System Settings

From the Ramses RF integration entry, you can configure standard Home Assistant options for device discovery and polling.

  1. Click the 3-dots menu on the integration card.
Integration Card Menu
  1. Select System options from the dropdown menu.
System Options Menu
  1. You will be presented with the System options dialog.
System Options Dialog

Available Options

  • Enable newly added entities: When enabled, Home Assistant will automatically add new devices discovered by the RF monitor (eavesdropping).

    Recommendation: This is very useful after initial setup to populate your devices. However, do not routinely leave this enabled, as it may pick up neighbors' devices or phantom signals.

  • Enable polling for changes: When enabled, Home Assistant will actively poll ramses_rf for state changes. This corresponds to the Scan Interval set in the Gateway Configuration, described on page 2.1 under point 4.

A look behind the scenes

If you want to see the JSON in .storage/core.config_entries, open the file and search for 'ramses_cc':

{
  "version": 1,
  "minor_version": 1,
  "key": "core.config_entries",
  "data": {
    "entries": [
      {
        "entry_id": "e16dd713122857453e961025a1653816",
        "version": 1,
        "minor_version": 1,
        "domain": "ramses_cc",
        "title": "RAMSES RF",
        "data": {},
        "options": {
          "ramses_rf": {
            "disable_qos": false,
            "enforce_known_list": true,
            "use_native_ot": "always"
          },
          "serial_port": {
            "port_name": "/dev/ttyACM0"
          },
          "scan_interval": 5,
          "advanced_features": {
            "send_packet": true
          },
          "known_list": {
            "18:006402": {
...

Migrating a legacy .yaml configuration

You can migrate from the older scheme to the current method until we drop this feature in 2027 at the end of the 3 year deprecation period. The legacy ramses_cc: section in your configuration.yaml will overwrite the present Ramses RF config flow entry.

After migration, the configuration is stored in a JSON-formatted file, at .storage/core.config_entries.

Until the defunct configuration is removed from configuration.yaml, every time HA restarts, there will be a warning message:

2024-05-08 17:32:56.949 WARNING ... [homeassistant.helpers.config_validation] 
   The 'ramses_cc' option near .../configuration.yaml:3 is deprecated, please remove it from your configuration

Best practice is to remove the ramses_cc: section from your configuration.yaml file to avoid any confusion, although leaving it there won't cause any issues, other than the warning message.

When you are having trouble during migration and the fragment is still in place, a trick is to remove the Ramses RF config entry in the UI and restart HA - then it will re-import from configuration.yaml to create a new entry. As stated above, we will drop this method in 2027.

Clone this wiki locally