3.1 I'm stuck: Help me

Here is a checklist that will solve most problems:

• to start, you must have a packet log that is being populated with data
• if you have one, check your configured schema
• if you have one, check your configured known_list

If required, have a look at the troubleshooting wiki.

If you still have issues, and can't find an answer on this wiki, reach out on the HA forum. If you notice any deficiencies with this wiki (that can't be addressed with a simple edit), please report them as issues.

Do you have packets being logged?

Once you have a packet log, you can confirm packets are being Rx/Tx, and get useful information from it.

For example:

> cat packet.log | grep ' 01:' | head  # for HVAC, try ' 18:' 
...
> cat packet.log | grep ' 1F09 ' | head  # for HVAC, use ' 31D' 
...

NOTE: You need to get this working before bothering with anything else.

You should start with an absolute minimal configuration, for example (i.e. your serial port name may be different):

ramses_cc:
  serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
  packet_log: packet.log

Is your serial_port configured correctly? For more information, see serial_port configuration.

If you have an evofw3-compatible dongle:

• if it isn't one of these, YMMV
• if it is NanoCUL-based, what baud rate did you flash it at?
• you could look at the evofw3 or the RAMSES_ESP wiki

Is your schema configured correctly?

The schema should be minimal: as simple as required, and exclude all information that can be auto-discovered. For clarity, this schema is sometimes called the config schema.

Note: The system will build a schema automatically, except as below. Many problems are caused when a schema is over-configured.

For evohome (CH/DHW) systems, this means only:

• the controller (and only if it is a zone sensor) and
• the OTB (if you have one)

... should be in the schema - very rarely, there are exceptions to this rule.

For example (your device ids will be different):

ramses_cc:
  01:123456:
    system:
      appliance_control: 10:123456
    zones:
      "01": {sensor: 01:123456}

For HVAC devices (but not so much for CH/DHW), and particularly HVAC remotes, it can be useful to add them to the schema as orphans so that they are instantiated during startup.

For example (your device ids will be different):

ramses_cc:
  orphans_hvac: [20:123456, 24:12356, 37:123456]

Except for faked devices, the above is not required (the system will be no more effective), but will be beneficial (the system will be more efficient).

Tip: You can find your:

• config schema in the attributes of the HGI 18:xxxxxx Gateway status binary sensor (suggested for configuration.yaml)
• working schemas in the attributes of the CTL 01:xxxxxx System status binary sensor (this is the place to find which thermostat is in which zone)

For more information, see schema configuration.

Is your known_list configured correctly?

Note: Enforcing a valid known_list is strongly recommended, but mis-configuring it will cause real headaches.

The obvious thing to do is to have enforce_known_list: false (the default), and to remove the block_list, and see what happens (there shouldn't be any need to remove a known_list).

Before you set enforce_known_list: true, the device id of:

• your devices,
• all your devices (includes your gateway), and
• nothing but your devices

... must be in the known_list.

Note: your gateway device id starts with 18: but is not 18:000730 - that is a sentinel value.

Tip: You can find your:

• working known list in the attributes of the 18:xxxxxx status binary sensor

For more information, see known_list configuration.