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

Share your Projects!
3699

This does sound like a bug? I will have a look.

Another cause could be that your hand-crafted schema is incorrect (i.e. it is not a superset of what the controller’s true schema (which is one reason why schemas should be thin).

Again, to be clear, we’re talking about:

ramses_cc:
  restore_cache: 
    restore_schema: false
    # restore_state: true

If needs be, it is pretty safe to use ramses_cc with this feature disabled.

The real difficulty is with the consequence of disabling restore_state.

3700

By `needs be’, I mean you may be able to ignore this error.

Please post your schema if you wish me to comment on it.

3701

Hello David, Is if possible if I post you my schema that you give me your comment on it?

3702

I only hard code HR80’s to keep eavesdropping off. The schema to me is as expected. There’s a separate round thermostat in there as well, with its own gateway and BDR.

ramses_cc:
  restore_cache:
    restore_schema: false
#    restore_state: false
  scan_interval: 60
  serial_port: /dev/ttyACM0
  packet_log: packet.log
  ramses_rf:
#    enable_eavesdrop: false
    enforce_known_list: true
#    disable_discovery: false
#  orphans_heat: [13:032522, 30:173916, 34:046925]
  01:201047:
    zones:
      "00":
        sensor: 01:201047
        actuators: [04:177708, 04:177712, 04:179991, 04:179993, 04:179995, 04:177718, 04:177709, 04:176841]
      "01":
        actuators: [04:173125, 04:173131, 04:179981]
      "02":
        actuators: [04:173127, 04:177713]
      "03":
        actuators: [04:177711, 04:173146, 04:179866]
  known_list:
    01:201047:
    04:000946:
    04:000948:
    04:000950:
    04:001454:
    04:001484:
    04:039319:
    04:039323:
    04:039325:
    04:039359:
    04:039361:
    04:039363:
    04:039365:
    04:053851:
    04:053853:
    04:053859:
    04:053861:
    04:060846:
    04:097396:
    04:173125:
    04:173127:
    04:173131:
    04:173146:
    04:176841:
    04:177708:
    04:177709:
    04:177711:
    04:177712:
    04:177713:
    04:177718:
    04:179866:
    04:179981:
    04:179991:
    04:179993:
    04:179995:
    04:182388:
    13:259021:
    18:071950: {class: HGI}
    22:027973:
    22:027984:
    22:028665:
    22:028675:
    22:028744:
    22:028749:
    22:028759:
    22:090207:
    22:090227:
    22:090231:
    22:219003:
    13:032522:
    30:173916:
    34:046925:

And here the binary sensor schema:

schema: 
system:
  appliance_control: '13:259021'
orphans: []
stored_hotwater: {}
underfloor_heating: {}
zones:
  '00':
    _name: Room1
    class: radiator_valve
    sensor: '01:201047'
    actuators:
      - '04:039319'
      - '04:039325'
      - '04:053851'
      - '04:053859'
      - '04:176841'
      - '04:177708'
      - '04:177709'
      - '04:177712'
      - '04:177718'
      - '04:179991'
      - '04:179993'
      - '04:179995'
  '01':
    _name: Room2
    class: radiator_valve
    sensor: '22:090227'
    actuators:
      - '04:173125'
      - '04:173131'
      - '04:179981'
  '02':
    _name: Room3
    class: radiator_valve
    sensor: '22:090231'
    actuators:
      - '04:173127'
      - '04:177713'
  '03':
    _name: Room4
    class: radiator_valve
    sensor: '22:028749'
    actuators:
      - '04:173146'
      - '04:177711'
      - '04:179866'
  '04':
    _name: Room5
    class: radiator_valve
    sensor: '22:028665'
    actuators:
      - '04:001454'
      - '04:001484'
  '05':
    _name: Room6
    class: radiator_valve
    sensor: '22:027984'
    actuators:
      - '04:182388'
  '06':
    _name: Room7
    class: radiator_valve
    sensor: '22:028744'
    actuators:
      - '04:053853'
      - '04:053861'
  '07':
    _name: Room8
    class: radiator_valve
    sensor: '22:028675'
    actuators:
      - '04:039359'
      - '04:039363'
      - '04:039365'
  '08':
    _name: Room9
    class: radiator_valve
    sensor: '22:219003'
    actuators:
      - '04:000950'
      - '04:039323'
  '09':
    _name: Room10
    class: radiator_valve
    sensor: '22:028759'
    actuators:
      - '04:097396'
  0A:
    _name: Room11
    class: radiator_valve
    sensor: '22:090207'
    actuators:
      - '04:000946'
  0B:
    _name: Room12
    class: radiator_valve
    sensor: '22:027973'
    actuators:
      - '04:039361'
      - '04:060846'
3703

You can post it here, so that other can benefit from any observations I make (e.g. see my comments on @Spaco’s schema, below).

Alternatively, you can PM me, but I will only reply if I am interested (i.e. I am not providing support).

3704

I should start by saying that many people send me packet logs, and this sort of behaviour should be encouraged (it helps me dev/test the code).

Importantly, I do not back up this data, for reasons of confidentially.

For very boring reasons, I have lost all that data, collected over 3-4 years, and I need to replace it, especially for HVAC (Itho, Orcon, Nuaire, etc.).

SO, if you have HVAC, do consider sending me packet logs, thanks.

Are you one of the few that have the strange HR80s that can’t be discovered? ( I always meant to get to the bottom of that, but haven’t had time… )

Yes, eavesdropping is to be avoided at all costs, and used only when required, and only for the minimum amount of time required.

All: for the vast majority of you, having the TRVs in your hand-crafted schema is a bad idea. (IIRC,

in Spaco’s case, he was specifically advised by me to do so)

And why isn’t the appliance controller in the schema?

I think in your case, I would really like a 24-48h packet log - to have another look at it.

Theory says that ramses_rf can handle multiple schemas, although that is really only for 01: (evohome) controllers.

3705

I can reproduce this error.

1 Like
3706

Just sent a packet log. Indeed have HR80’s that can’t be discovered.

Is it better to explicitly identify the controller in the config? it seems to show up OK in the generated schema…

3707

Thanks - looking at your packet log, some of your TRVs are OK, others are not. Odd.

3708

Its a big house :slight_smile: even with a decent antenna some TRV’s are at the edge of range.

3709

Ramses_cc is interfering with the operation of my boiler. I have an evohome controller talking through an OTB to my Intergas boiler. I also have a separate (second) evohome controller not connected to any heating device.

By “interfering” I mean fundamentally changing the boiler output. The boiler doesn’t respond correctly to a 100% heat demand when the integration is running and keeps cycling to off and the house remains cool. When I then shutdown ramses_cc, the boiler fires up (almost instantly) with maximum 100% output and the house heats up.

Has anyone else run into similar boiler behaviour change?

Is it possible to run ramses_cc in pure “listen only” mode to help me understand what’s going on? I can’t currently “observe” the change in boiler behaviour between the on/off integration states in home assistant as obviously the moment I shut down the integration I lose all the logging of system behaviour!

Could I prevent ramses from speaking to the OTB (which I assume must be where the issue lies as that’s the only device in communication with the boiler)? If I added the OTB device to the block_list - would that have other implications?

3710

This is my config file. Can you tell me if this is the right way to do it?
I have upgraded to 0.30.2

ramses_cc:
  serial_port:
    port_name: /dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port0
    baudrate: 115200
  scan_interval: 60
  restore_cache:
    restore_schema: false

  packet_log:
    file_name: /config/ramses_packet.log
    rotate_backups: 7

  known_list:
    01:059830:                # Honeywell Evohome thermostaat
    10:041708:                # OpenTherm Bridge bij CV
    18:012902: {class: HGI}   # Gateway (only 18: and 30: (RFG) need defining)
    04:084924:                # 00 Woonkamer groot
    04:085268:                # 00 Woonkamer klein
    04:085344:                # 00 Gang
    04:084922:                # 00 Keuken
    04:085272:                # 01 Badkamer
    04:085270:                # 02 Slaapkamer
    04:049111:                # 03 Werkkamer
    04:085348:                # 04 Zolder tuinkant
    04:085346:                # 04 Zolder voorkant
    04:085350:                # 05 Logeerkamer
    04:084926:                # 06 Berging
    04:084920:                # 07 Wc

  01:059830:
    system:
      appliance_control: 10:041708  # 1 of 2 - OTB as appliance controller
    zones:
      "00":
        _name: Woonkamer
        class: radiator_valve
        sensor: 01:059830  # controller is the sensor
        actuators:
          - '04:085344'
          - '04:085268'
          - '04:084924'
          - '04:084922'
      "01": 
        _name: Badkamer
        class: radiator_valve
        sensor: 04:085272
        actuators:
          - '04:085272'
      "02": 
        _name: Slaapkamer
        class: radiator_valve
        sensor: 04:085270
        actuators:
          - '04:085270'
      "03":
        _name: Werkkamer
        class: radiator_valve
        sensor: 04:049111
        actuators:
        - '04:049111'
      "04":
        _name: Badkamer
        class: radiator_valve
        sensor: 04:085346
        actuators:
        - '04:085346'
        - '04:085348'
      "05":
        _name: Logeerkamer
        class: radiator_valve
        sensor: 04:085350
        actuators:
        - '04:085350'
      "06":
        _name: Berging
        class: radiator_valve
        sensor: 04:084926
        actuators:
        - '04:084926'
      "07":
        _name: Wc
        class: radiator_valve
        sensor: 04:084920
        actuators:
        - '04:084920'


  ramses_rf:
#    enable_eavesdrop: false
    enforce_known_list: true  # set true as soon as you can
    max_zones: 8
#    orphans_heat: [10:041708]
3711

Just thought I’d share, I upgraded to latest master, which version.py shows as 0.30.0 but I think might be 0.30.2

It’s actually fixed a couple of annoying issues I had related to changing system mode and preset via HA cards for my evohome.

Everything else so far seems to be working fine. Thanks!

3712

First of all, I am always open to being wrong… With that in mind…

I am very clear that ramses_rf never sends an instruction to the OTB (i.e. it only asks for information).

You can see this for yourselves by looking at all the packets from the gateway (18:xxxxxx) to the OTB (10:xxxxxx):

> cat packet.log | grep ' 18:.* 10:.* 3220 ' | python client.py parse

2023-11-15T18:19:39.510386 ||  18:006402 |  10:048122 | RQ | opentherm_msg    |  00  || {'msg_id': 0, 'msg_type': <OtMsgType.READ_DATA: 'Read-Data'>, 'msg_name': 'status_flags', 'description': 'Status'}
2023-11-15T18:20:02.391644 ||  18:006402 |  10:048122 | RQ | opentherm_msg    |  00  || {'msg_id': 0, 'msg_type': <OtMsgType.READ_DATA: 'Read-Data'>, 'msg_name': 'status_flags', 'description': 'Status'}

… they are all READ_DATA.

Nonetheless, I have previously had a report from one user (and only ever one user) that described the behaviour you describe, above. In his case, I put it down to a derange OpenTherm implementation on the boiler…

That is, ramses_rf is causing the behaviour you describe (albeit, the cause is due to the boiler?).

I will go back through my notes and let you know more, when I have the chance.

Until then, try this:

ramses_cc:
  ramses_rf:
    user_native_ot: never  # if that works, can then try avoid

With never, it only ever sends one ’ 3220 ’ packet, an RQ|3220|00 (it shouldn’t even send that - it’s a bug):

If that doesn’t work, let me know, and I’ll offer another solution - I think it was the RQ|3220|00 causing his issues… :frowning:

If you’re desparate, remove the OTB from your known_list.

3713

yes:

ramses_cc:
  ramses_rf:
    disable_sending: true

Assuming you’re enforce_known_list: true, it is enough to remove it from the known_list. But block_list will work too - it just shouldn’t really be in both lists.

The implication is only that you will lose the OTB sensors - nothing else.

As I said - ramses_rf only request information from the OTB, it never send the OTB instructions.

3714

… or just remove the restore_cache: section altogether.

The above is a minimal schema (OTB, and controller-as-sensor). Minimal schemas are best practice. The rest of your schema can be determined by discovery, except in rare edge-cases.

Please keep the devices in your known_list, though.

3715

Here we go:

3716

@evoboff Check your PM.

3717

Thanks for the advice!

3718

Noticed all of the zone window open sensors on the controller are unavailable since updating to 0.30.2

Individual TRV windows sensors are still available.

1000075592
10000755921080×1780 220 KB