RAMSES-III protocol + new firmware on honeywell controller - R3 not supported

[Tchirana]

Describe the bug
I had been running strong and true with a device from IndaloTech/ramses_esp in latest Homeassistant and latest version of the integration when one of my DT92 THM failed. So I got it replaced by a DT4R and here the show starts:
Had to contact Resideo because the DT4R was not binding to my controller and they knew the problem. Seems like the DT4R with production date over 2530 come by default with RAMSES-III protocol. They pushed an update on my evotouch controller (02.47.00.01 / wifi 02.00.20.00).
Because I use a mix of TRV and THM (HR80, HR92, HR93 DT92, DT4R) which use different versions of RAMSES , Resideo instructed that after the update to go in advanced settings > System Parameters and enable the last option there LEGACY RF COMPONENTS.
On honeywell side all looks good, all my zones are ok and basically I see no functionality change.
On HA side things went haywire.

Because I had a ghost THM left from this move to DT4R I completely removed the ramses_cc integration, deleted the ramses_cc cache file from .storage of HomeAssistant , reboot HAOS server, redownloaded from HACS the integration , set it up again (i use ramses_esp over mqtt) and surprize, my zones (RAD) are not detected anymore. I have some logs saved also.
This was not ok so I reverted my backup of HA and now I have all the zones back because they were in the ramses_cc cache file but they have status unavailable. I also have logs from the integration and I see that the zones are detected:

025-10-30 12:49:44.815 INFO (MainThread) [ramses_rf.dispatcher] ||  01:226586 |            |  I | setpoint         | [..] || [{'zone_idx': '00', 'setpoint': 20.0}, {'zone_idx': '01', 'setpoint': 5.0}, {'zone_idx': '02', 'setpoint': 21.5}, {'zone_idx': '03', 'setpoint': 5.0}, {'zone_idx': '04', 'setpoint': 20.0}, {'zone_idx': '05', 'setpoint': 19.5}, {'zone_idx': '06', 'setpoint': 20.5}, {'zone_idx': '07', 'setpoint': 18.0}, {'zone_idx': '08', 'setpoint': 20.0}]
2025-10-30 12:49:44.838 INFO (MainThread) [ramses_rf.dispatcher] ||  01:226586 |            |  I | temperature      | [..] || [{'zone_idx': '00', 'temperature': 21.28}, {'zone_idx': '01', 'temperature': 24.27}, {'zone_idx': '02', 'temperature': 22.5}, {'zone_idx': '03', 'temperature': 21.54}, {'zone_idx': '04', 'temperature': 20.69}, {'zone_idx': '05', 'temperature': 20.89}, {'zone_idx': '06', 'temperature': 23.71}, {'zone_idx': '07', 'temperature': 20.57}, {'zone_idx': '08', 'temperature': 21.8}]
2025-10-30 12:49:45.253 INFO (MainThread) [ramses_rf.dispatcher] ||  04:153234 |            |  I | temperature      |      || {'temperature': 20.44}
2025-10-30 12:49:51.254 INFO (MainThread) [ramses_rf.dispatcher] ||  04:153234 |  01:226586 |  I | device_battery   |  06  || {'zone_idx': '06', 'battery_low': False, 'battery_level': None}
2025-10-30 12:49:51.265 INFO (MainThread) [ramses_rf.dispatcher] ||  04:153234 |            |  I | device_battery   |      || {'battery_low': False, 'battery_level': None}
2025-10-30 12:49:52.963 INFO (MainThread) [ramses_rf.dispatcher] ||  18:109940 |  01:226586 | RQ | zone_mode        |  04  || {'zone_idx': '04'}
2025-10-30 12:49:56.252 INFO (MainThread) [ramses_rf.dispatcher] ||  04:157378 |  01:226586 |  I | setpoint         |  04  || {'zone_idx': '04', 'setpoint': 20.0}
2025-10-30 12:50:04.254 INFO (MainThread) [ramses_rf.dispatcher] ||  04:153236 |  01:226586 |  I | heat_demand      |  06  || {'zone_idx': '06', 'heat_demand': 0.0}
2025-10-30 12:50:04.752 INFO (MainThread) [ramses_rf.dispatcher] ||  04:245957 |  01:226586 |  I | heat_demand      |  03  || {'zone_idx': '03', 'heat_demand': 0.0}
2025-10-30 12:50:05.252 INFO (MainThread) [ramses_rf.dispatcher] ||  04:153236 |  01:226586 |  I | setpoint         |  06  || {'zone_idx': '06', 'setpoint': 20.5}
2025-10-30 12:50:07.253 INFO (MainThread) [ramses_rf.dispatcher] ||  04:115445 |            |  I | temperature      |      || {'temperature': 21.28}
2025-10-30 12:50:09.250 INFO (MainThread) [ramses_rf.dispatcher] ||  04:153233 |  01:226586 |  I | setpoint         |  08  || {'zone_idx': '08', 'setpoint': 20.0}
2025-10-30 12:50:12.253 INFO (MainThread) [ramses_rf.dispatcher] ||  04:245957 |            |  I | temperature      |      || {'temperature': 21.54}
2025-10-30 12:50:17.751 INFO (MainThread) [ramses_rf.dispatcher] ||  04:245957 |  01:226586 |  I | heat_demand      |  03  || {'zone_idx': '03', 'heat_demand': 0.0}

But I also see these errors:

2025-10-30 09:43:30.266 WARNING (MainThread) [ramses_tx.message]  I --- 01:226586 --:------ 01:226586 30C9 003 FC7FFF < Payload doesn't match '^(0[0-9A-F][0-9A-F]{4})+$': FC7FFF
2025-10-30 09:52:03.221 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=2E04|RQ|01:226586, tx_count=1/4>: echo_timeout=0.5
2025-10-30 09:52:04.225 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=2E04|RQ|01:226586, tx_count=2/4>: echo_timeout=1.0
2025-10-30 09:52:06.229 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=2E04|RQ|01:226586, tx_count=3/4>: echo_timeout=2.0
2025-10-30 09:52:08.294 WARNING (paho-mqtt-client-) [ramses_tx.transport] MqttTransport(QosProtocol(WantEcho, len(queue)=0)): the ESP device is offline (via LWT): RAMSES/GATEWAY/18:109940
2025-10-30 09:52:10.232 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=2E04|RQ|01:226586, tx_count=4/4>: echo_timeout=4.0
2025-10-30 09:52:10.233 WARNING (MainThread) [ramses_rf.entity_base] 01:226586 (evohome): Failed to send discovery cmd: 2E04|RP|01:226586: <ProtocolContext state=WantEcho cmd_=2E04|RQ|01:226586, tx_count=4/4>: Exceeded maximum retries
2025-10-30 09:57:03.223 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=2E04|RQ|01:226586, tx_count=1/4>: echo_timeout=0.5
2025-10-30 10:03:30.509 WARNING (MainThread) [ramses_tx.message]  I --- 01:226586 --:------ 01:226586 30C9 003 FC7FFF < Payload doesn't match '^(0[0-9A-F][0-9A-F]{4})+$': FC7FFF
2025-10-30 10:21:39.204 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=12B0|RQ|01:226586|02, tx_count=1/4>: echo_timeout=0.5
2025-10-30 10:21:40.208 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=12B0|RQ|01:226586|02, tx_count=2/4>: echo_timeout=1.0
2025-10-30 10:23:30.649 WARNING (MainThread) [ramses_tx.message]  I --- 01:226586 --:------ 01:226586 30C9 003 FC7FFF < Payload doesn't match '^(0[0-9A-F][0-9A-F]{4})+$': FC7FFF
2025-10-30 10:42:36.842 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=2349|RQ|01:226586|02, tx_count=1/4>: echo_timeout=0.5
2025-10-30 10:42:55.472 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=2349|RQ|01:226586|05, tx_count=1/4>: echo_timeout=0.5
2025-10-30 10:43:30.912 WARNING (MainThread) [ramses_tx.message]  I --- 01:226586 --:------ 01:226586 30C9 003 FC7FFF < Payload doesn't match '^(0[0-9A-F][0-9A-F]{4})+$': FC7FFF
2025-10-30 10:51:15.986 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=12B0|RQ|01:226586|07, tx_count=1/4>: echo_timeout=0.5
2025-10-30 11:01:19.810 WARNING (paho-mqtt-client-) [ramses_tx.transport] MqttTransport(QosProtocol(IsInIdle, len(queue)=0)): the ESP device is offline (via LWT): RAMSES/GATEWAY/18:109940
2025-10-30 11:01:30.033 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=3EF1|RQ|13:187431, tx_count=1/4>: echo_timeout=0.5
2025-10-30 11:03:31.101 WARNING (MainThread) [ramses_tx.message]  I --- 01:226586 --:------ 01:226586 30C9 003 FC7FFF < Payload doesn't match '^(0[0-9A-F][0-9A-F]{4})+$': FC7FFF
2025-10-30 11:04:39.802 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=3EF1|RQ|13:187431, tx_count=1/4>: echo_timeout=0.5
2025-10-30 11:15:14.468 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=3EF1|RQ|13:187431, tx_count=1/4>: echo_timeout=0.5
2025-10-30 11:17:15.191 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=3EF1|RQ|13:187431, tx_count=1/4>: echo_timeout=0.5
2025-10-30 11:23:31.247 WARNING (MainThread) [ramses_tx.message]  I --- 01:226586 --:------ 01:226586 30C9 003 FC7FFF < Payload doesn't match '^(0[0-9A-F][0-9A-F]{4})+$': FC7FFF
2025-10-30 11:28:23.744 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=3EF1|RQ|13:187431, tx_count=1/4>: echo_timeout=0.5
2025-10-30 11:31:26.030 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=0008|RQ|13:187431, tx_count=1/4>: echo_timeout=0.5
2025-10-30 11:32:34.091 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=2349|RQ|01:226586|07, tx_count=1/4>: echo_timeout=0.5
2025-10-30 11:32:36.041 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=2349|RQ|01:226586|06, tx_count=1/4>: echo_timeout=0.5
2025-10-30 11:37:36.173 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=2349|RQ|01:226586|06, tx_count=1/4>: echo_timeout=0.5
2025-10-30 11:39:15.299 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=2349|RQ|01:226586|00, tx_count=1/4>: echo_timeout=0.5
2025-10-30 11:42:55.572 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=2349|RQ|01:226586|03, tx_count=1/4>: echo_timeout=0.5
2025-10-30 11:43:32.277 WARNING (MainThread) [ramses_tx.message]  I --- 01:226586 --:------ 01:226586 30C9 003 FC7FFF < Payload doesn't match '^(0[0-9A-F][0-9A-F]{4})+$': FC7FFF
2025-10-30 11:47:06.135 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=2E04|RQ|01:226586, tx_count=1/4>: echo_timeout=0.5
2025-10-30 12:02:57.641 WARNING (MainThread) [ramses_tx.protocol_fsm] TOUT.. = <ProtocolContext state=WantEcho cmd_=2349|RQ|01:226586|05, tx_count=1/4>: echo_timeout=0.5
2025-10-30 12:03:31.647 WARNING (MainThread) [ramses_tx.message]  I --- 01:226586 --:------ 01:226586 30C9 003 FC7FFF < Payload doesn't match '^(0[0-9A-F][0-9A-F]{4})+$': FC7FFF

Any more info requests or ways to how I should investigate this further I am happy and willing to provide.

[Tchirana]

Attaching some files:
with system cleanly initialised after the fw upgrade:

ramses_cc.log

with system rolled back and using the old ramses_cc cache file:

ramses_cc_after_rollback.log

I am on the last stable release of ramses_cc 0.51.9-1 but I went to 0.52.1 also and it does not make any difference.

[silverailscolo]

For state=WantEcho try rebooting the ramses_esp. Bad reception?
GitHub issues are not for user support. Keep to the forum for that. And as for GitHub, when you are talking HACS enter bugs on the ramses_cc repo, not this one.

[Tchirana]

Ok, but since this is related to new protocol....
I'll try reboot of esp but reception is good. It may have some glitches
The no zones is what bothers me and highly suspect the new R3
I talked to resideo since they might also have issues. If I set the temp on a hr80 trv i get sn override on the controller as it should. But when I cancel that from controller the old hr80 does not get sync and the override is back on the controller. I have to cancel that on the controller and get the batteries out of the trv so it syncs again. Uffffff

[ghoti57]

RAMSES-III is encrypted.
All the USB dongles out there are going to struggle with this.

It may be possible to identify the frame in the radio signals but extracting the fields from the packet may prove impossible.

There's a high probability that Resideo have also added some new interpretation to some of the fields in packets being sent to legacy devices that trigger the syntax checking @zxdavb built into ramses_rf/cc.

The best way to get data that might help is with an evofw3 device connected to a terminal emulator program.
Entering T07 as a command line turns on debug code that dumps raw packets and any attempt to decode that packet.

This functionality is not in ramses_esp

[Tchirana]

Ok. I have a device with evofw3. I will set it in another pc and try to capture comms.

[Tchirana]

Here it goes:

Let me explain:

• i have 2 DT4R and a bunch of HR80 , 1 HR93, 1 HR92 , a bdr91, and the evotouch is a 3000 variant.
• 2 zones are composed of 1 DT4R+2 HR80 (i have 2 rads in one room)
• 1 zone is HR93
• 1 zone is HR92
• 5 zones is 1xHR80

Schema is below:

"01:226586":
  system:
    appliance_control: "13:187431"
  zones:
    "00":
      _name: MainBedroom
      actuators:
        - "04:115445"
      class: radiator_valve
      sensor: "04:115445" <<<< HR80
    "01":
      _name: Bedroom1
      actuators:
        - "04:120170"
      class: radiator_valve
      sensor: "04:120170" <<< HR92
    "02":
      _name: Living
      actuators:
        - "04:116909" <<<< HR80
        - "00:031413" <<< HR80
      class: radiator_valve
      sensor: "22:014440" < DT4R
    "03":
      _name: Office
      actuators:
        - "04:118841"
      class: radiator_valve
      sensor: "04:118841"  <<< HR93
    "04":
      _name: Kitchen
      actuators:
        - "04:157378"
      class: radiator_valve
      sensor: "04:157378" <<< HR80
    "05":
      _name: EntranceHall
      actuators:
        - "04:157256"
      class: radiator_valve
      sensor: "04:157256". << HR80
    "06":
      _name: Dining
      actuators:
        - "04:153234" << HR80
        - "04:153236"  << HR80
      class: radiator_valve
      sensor: "22:014439"   <<< DT4R
    "07":
      _name: Dressing
      actuators:
        - "04:153231"
      class: radiator_valve
      sensor: "04:153231"  < HR80
    "08":
      _name: Bathroom
      actuators:
        - "04:153233"
      class: radiator_valve
      sensor: "04:153233"  <<< HR80

With the latest firmware what I see is this:

• zones are not detected anymore, even if (look in the ha log) I see the zones correctly decoded , messages with zodne_idx , like it seems to know from which zone which device comes. I got over it by adding this ^^^^ to the schema section in the HA integration and the zones are there, I can even see the temperature of that zone reported in the HA device but I have no controls. Also the zones are automatically named RAD xx:xxxxxxx without the friendly name as they were previously. Controls is reported as Unknown. I think It does not properly import them
• the schema is not build automatically, it's just blank in the controller, i had to manually enter it so I got the zones back
• the controller has also no controls so I cannot set the modes anymore.
• status of the HGI is correctly reported
• The HR93 is not detected automatically at all. I tried setting it in the known devices of the HA integration and in the schema and it appeared in the list of detected devices but all entities are unknown, so basically it's useless.

For any questions or elbow grease on trying to decode / make this new stuff work I am all in :)

hr93binding.log
nanocul_evofw3.log
ramses_packet.log
ramses_homeassitant.log

[ghoti57]

hr93binding.log contains the following sequence of messages

044  I --- 04:118841 --:------ 04:118841 1FC9 024 0030CA11D03900000011D03900018811D039001FC811D039
# A9.6A A9.A9.59.AA.A5.69 A9.A9.59.AA.A5.69      I --- 04:118841 --:------ 04:118841
A9.55.5A.69 A9.6A                                1FC9 024
AA.AA A5.AA.5A.66 A9.A9.59.AA.A5.69              00 30CA 04:118841 
AA.AA AA.AA.AA.AA A9.A9.59.AA.A5.69              00 0000 04:118841
AA.AA AA.A9.6A.6A A9.A9.59.AA.A5.69              00 0188 04:118841
AA.AA A9.55.5A.6A A9.A9.59.AA.A5.69              00 1FC8 04:118841
56.A6.                                           checksum

051  W --- 01:226586 04:118841 --:------ 1FC8 075 030230CA020000020189019BCB96EEFF8F6F8F3E9281E77943B515ED7B8F232F19C92E52116DA0CB67E142E62F747059227D2DC4365AFA82A2A58939D216E34E * Too long
# A6.5A AA.95.95.99.A9.66 A9.A9.59.AA.A5.69      W --- 01:226586 04:118841 --:------
A9.55.5A.6A 9A.65                                1FC8 075
AA.A5.AA.A6.A5.AA.5A.66.AA.A6.AA.AA.AA.AA.AA.A6  030230CA02000002
AA.A9.6A.69.AA.A9.69.65.5A.65.69.96.56.56.55.55  0189019BCB96EEFF
6A.55.96.55.6A.55.A5.56.69.A6.6A.A9.56.95.95.69  8F6F8F3E9281E779
9A.A5.65.99.A9.99.56.59.95.65.6A.55.A6.A5.A6.55  43B515ED7B8F232F
A9.69.5A.69.A6.56.99.A6.A9.A9.96.59.66.AA.5A.65  19C92E52116DA0CB
96.95.56.A9.9A.A6.56.96.A6.55.95.9A.95.AA.99.69  67E142E62F747059
A6.A6.95.59.A6.59.5A.9A.A5.96.99.66.55.66.6A.A6  227D2DC4365AFA82
66.A6.66.99.6A.69.A5.69.59.A6.A9.96.56.A5.9A.56  A2A58939D216E34E
A6.95.A5.55.66.6A.96.A9.59.59.5A.65.66.AA        * Too long

Too long -> too many bytes of raw data
limit is 162 (includes 20 before payload) i.e. 71 octets of payload

043  I --- 04:118841 01:226586 --:------ 1FC8 069 0102FFFF01AD93209A79DBEF85A3AB56924258727ECC87991F00F8736BCF82361682242C03671C06F725C87CB98AD0EC659BFA715E5C0F44329E6042197B6554 * Truncated
# A9.5A A9.A9.59.AA.A5.69 AA.95.95.99.A9.66      I --- 04:118841 01:226586 --:------ 
A9.55.5A.6A 9A.99                                1FC8 069
AA.A9.AA.A6.55.55.55.55.AA.A9.66.59.69.A5.A6.AA  0102FFFF01AD9320
69.66.95.69.59.65.56.55.6A.99.66.A5.66.65.99.96  9A79DBEF85A3AB56
69.A6.9A.A6.99.6A.95.A6.95.56.5A.5A.6A.95.69.69  924258727ECC8799
A9.55.AA.AA.55.6A.95.A5.96.65.5A.55.6A.A6.A5.96  1F00F8736BCF8236
A9.96.6A.A6.A6.9A.A6.5A.AA.A5.96.95.A9.5A.AA.96  1682242C03671C06
55.95.A6.99.5A.6A.95.5A.65.69.6A.66.59.AA.56.5A  F725C87CB98AD0EC
96.99.69.65.55.66.95.A9.99.56.99.5A.AA.55.9A.9A  659BFA715E5C0F44
A5.A6.69.56.96.AA.9A.A6.A9.69.95.65.96.99.99.9A  329E6042197B6554 
A9.99.95.A6.55.6A.95.59.66.56                    * Truncated
96.6A.                                           checksum

Truncated -> Payload too long
limit is 64

So there's a number of problems here.
Firstly, both evofw3 and ramses_esp will not accept messages with payload longer than 064
Secondly, the HR93 and controller are using messages 1FC8 which I do not believe is supported in ramses_rf/cc

The currently supported bind sequence uses 1FC9 which includes copies of the one or other of the two device addresses
There is no sign in the payload data in 1FC8 of either address.
I suspect 1FC8 may be a RAMSES-III version of 1FC9

The bind offer from the HR93 also appears to offer binding options for commands 0000 and 0188. What are these?

[ghoti57]

Subsequently the same log contains messages between the HR93 and controller like this

053  I --- 04:118841 01:226586 --:------ 0502 076 0008000A75C6BF8E3E6351200FA3D82BB08DE5622F63640C30C541A91D0A95E7E0BF3ADB52713CF4110D61FA9B142B4CA90966D856A13AAFE6C4BE28D11CEC1C * Too long 
# 69.5A A9.A9.59.AA.A5.69 AA.95.95.99.A9.66
AA.99.AA.A6.9A.5A.AA.AA.AA.6A.AA.AA.AA.66.95.99.       0008000A75C6BF8E
5A.96.65.55.6A.56.A5.56.96.A5.99.A9.A6.AA.AA.55.       3E6351200FA3D82B
66.A5.59.6A.A6.65.65.AA.6A.59.56.99.96.A6.A6.55.       B08DE5622F63640C 
96.A5.96.9A.AA.5A.A5.AA.5A.99.9A.A9.66.69.A9.59.       30C541A91D0A95E7
AA.66.69.99.56.95.56.AA.65.55.A5.66.59.65.99.A6.       E0BF3ADB52713CF4
95.A9.A5.5A.55.9A.A9.A9.AA.59.96.A9.55.66.69.65.       110D61FA9B142B4C
A9.9A.A6.65.9A.5A.66.69.AA.69.96.96.59.6A.99.96.       A90966D856A13AAF
66.A9.A5.66.66.55.56.96.5A.9A.65.56.A6.6A.59.A9.       E6C4BE28D11CEC1C * Too long
A9.5A.56.5A.A9.5A.69.A6.55.6A.96.69.9A.55.9A.56.
69.A6.69.56.

(Note: I've edited the reformatted raw data above)

Again another new message that's currently too long

[Tchirana]

Hmmmm. so this zone that contains the HR93 is a "pure" RF3 zone .

Can it be a shared encription key present in the payload?

@ghoti57 what do you use to to display the logs like that or you just reformatted?

Let me grab the binding and comms from a zone that uses the new 1 DT4R (RF3) and 2 HR80 (RF2)
I suspect that I will see a some compatibility communicattion or not....

[Tchirana]

This zone was deleted and recreated on the controller and it is named DiningNG
the HR80 are: 04:153234 and 04:153236
the DT4R is: 22:014439

052 I --- 04:153234 63:262142 --:------ 1FC9 006 0030C9125692

who is 63:262142.

Is this the entire binding process of DT4R:?

063  I --- 22:014439 --:------ 22:014439 1FC9 024 0023095838670030C9583867000008583867001FC8583867
# A9.6A.99.6A.A5.6A.96.95.99.6A.A5.6A.96.95.A9.55.5A.69.A9.6A.AA.AA.A6.A5.AA.69.99.6A.A5.6A.96.95.AA.AA.A5.AA.5A.69.99.6A.A5.6A.96.95.AA.AA.AA.AA.AA.6A.99.6A.A5.6A.96.95.AA.AA.A9.55.5A.6A.99.6A.A5.6A.96.95.AA.66.
053  W --- 01:226586 22:014439 --:------ 1FC8 069 0107230901379337A6FBE5963A70D0527A4F629C26265F37DE78C09904129BFFC96350A0D30E4DED7EB4B162AF70717E89C4E5CA8517397122FE5018A074B003 * Truncated
# A6.5A.AA.95.95.99.A9.66.99.6A.A5.6A.96.95.A9.55.5A.6A.9A.99.AA.A9.AA.95.A6.A5.AA.69.AA.A9.A5.95.69.A5.A5.95.66.96.55.65.56.99.69.96.A5.66.95.AA.59.AA.99.A6.95.66.9A.55.96.A6.69.5A.A6.96.A6.96.99.55.A5.95.59.56.95.6A.5A.AA.69.69.AA.9A.A9.A6.69.65.55.55.5A.69.96.A5.99.AA.66.AA.59.A5.AA.56.9A.59.56.59.95.56.65.9A.65.A9.96.A6.66.55.95.AA.95.A9.95.56.6A.69.5A.9A.56.99.5A.66.6A.99.A9.95.A5.69.95.A9.A6.A6.55.56.99.AA.A9.6A.66.AA.95.9A.65.AA.AA.A5.6A.96.A6.A5.55.6A.66.65.95.69.A9.99.

Both 1FC8 and 1FC9

064  I --- 22:014439 01:226586 --:------ 1FC8 069 01FFFFFF0160283C15B8BC387C2832CD5AA52ED34AF93EB080DA51999EB29AD2BD0E99EA294B6DB3B21818E2716406109408D50688AA340FC86FE481E93475B6 * Truncated
# A9.5A.99.6A.A5.6A.96.95.AA.95.95.99.A9.66.A9.55.5A.6A.9A.99.AA.A9.55.55.55.55.55.55.AA.A9.96.AA.A6.6A.A5.5A.A9.99.65.6A.65.5A.A5.6A.95.5A.A6.6A.A5.A6.5A.59.99.66.66.99.A6.56.59.A5.9A.66.55.69.A5.56.65.AA.6A.AA.59.66.99.A9.69.69.69.56.65.A6.69.66.59.A6.65.59.AA.56.69.69.56.66.A6.69.9A.65.96.59.65.A5.65.A6.A9.6A.A9.6A.56.A6.95.A9.96.9A.AA.96.A9.AA.69.9A.AA.6A.59.99.AA.96.6A.6A.66.66.A5.9A.AA.55.5A.6A.96.55.56.9A.6A.A9.56.69.A5.9A.95.99.65.96.96.56.5A.59.A9.65.55.65.6A.56.69.A5.
054  I --- 01:226586 22:014439 --:------ 2309 014 0007037E45719AF940C5BD5DFF9D * Checksum error
# 69.5A.AA.95.95.99.A9.66.99.6A.A5.6A.96.95.A6.A5.AA.69.AA.56.AA.AA.AA.95.AA.A5.95.56.9A.99.95.A9.69.66.55.69.9A.AA.5A.99.65.59.99.59.55.55.69.59.A9.A6.
082  I --- 00:031413 --:------ 01:226586 3150 002 0500
# A9.6A.AA.AA.95.66.65.99.AA.95.95.99.A9.66.A5.A9.99.AA.AA.A6.AA.99.AA.AA.69.65.
054  I --- 01:226586 22:014439 --:------ 2309 014 0007037F04D820F916C18A309282 * Checksum error
# 69.5A.AA.95.95.99.A9.66.99.6A.A5.6A.96.95.A6.A5.AA.69.AA.56.AA.AA.AA.95.AA.A5.95.55.AA.9A.59.6A.A6.AA.55.69.A9.96.5A.A9.6A.66.A5.AA.69.A6.6A.A6.95.65.
095  I --- 04:115445 --:------ 01:226586 1060 003 03 * Invalid Manchester Code
# A9.6A.A9.A9.5A.A6.55.99.AA.95.95.99.A9.66.A9.AA.96.AA.AA.A5.AA.A5.55.15.
095  I --- --:------ --:------ --:------ ???? ???  * Invalid Manchester Code
# A9.6A.A9.29.
058  W --- 22:014439 01:226586 --:------ 2309 014 0002020C6F56F8677D02FF9FA8EE * Checksum error
# 66.5A.99.6A.A5.6A.96.95.AA.95.95.99.A9.66.A6.A5.AA.69.AA.56.AA.AA.AA.A6.AA.A6.AA.5A.96.55.99.96.55.6A.96.95.95.59.AA.A6.55.55.69.55.66.6A.56.56.66.95.
049  W --- 22:014439 --:------ --:------ ???? ???  * Invalid Manchester Code
# 66.5A.99.6A.A5.6A.96.95.54.
051  I --- 01:226586 22:014439 --:------ 2309 014 000703809CA8C31A67EE659611C8 * Checksum error
# 69.5A.AA.95.95.99.A9.66.99.6A.A5.6A.96.95.A6.A5.AA.69.AA.56.AA.AA.AA.95.AA.A5.6A.AA.69.5A.66.6A.5A.A5.A9.66.96.95.56.56.96.99.69.96.A9.A9.5A.6A.5A.66.
051  I --- 01:226586 22:014439 --:------ 2349 024 000703819257A26C1CCCB4585DFCA38F965044FC22301AB3 * Checksum error
# 69.5A.AA.95.95.99.A9.66.99.6A.A5.6A.96.95.A6.A5.9A.69.A9.6A.AA.AA.AA.95.AA.A5.6A.A9.69.A6.99.95.66.A6.96.5A.A9.5A.5A.5A.65.9A.99.6A.99.59.55.5A.66.A5.6A.55.69.96.99.AA.9A.9A.55.5A.A6.A6.A5.AA.A9.66.65.A5.AA.56.
051  I --- 01:226586 22:014439 --:------ 2309 014 00070382B3981C88819D9C99D81A * Checksum error
# 69.5A.AA.95.95.99.A9.66.99.6A.A5.6A.96.95.A6.A5.AA.69.AA.56.AA.AA.AA.95.AA.A5.6A.A6.65.A5.69.6A.A9.5A.6A.6A.6A.A9.69.59.69.5A.69.69.59.6A.A9.66.59.56.
058  W --- 22:014439 01:226586 --:------ 0009 014 0002020E500B49A07B497ED8BA41 * Checksum error
# 66.5A.99.6A.A5.6A.96.95.AA.95.95.99.A9.66.AA.AA.AA.69.AA.56.AA.AA.AA.A6.AA.A6.AA.56.99.AA.AA.65.9A.69.66.AA.95.65.9A.69.95.56.59.6A.65.66.9A.A9.9A.96.
038  I --- 01:226586 22:014439 --:------ 0009 014 00070383D6F4CA5ABCD5291BCDC0 * Checksum error
# 69.5A.AA.95.95.99.A9.66.99.6A.A5.6A.96.95.AA.AA.AA.69.AA.56.AA.AA.AA.95.AA.A5.6A.A5.59.96.55.9A.5A.66.99.66.65.5A.59.99.A6.69.A9.65.5A.59.5A.AA.56.9A.
038  I --- 04:153234 --:------ 04:153234 30C9 003 0007FC
# A9.6A.A9.A6.99.96.69.A6.A9.A6.99.96.69.A6.A5.AA.5A.69.AA.A5.AA.AA.AA.95.55.5A.55.99.

If I suppose that wrong manchester code message means junk in rf am I correct?

I need to study a bit on the codes
dt4r_hr80_binding.log

[ghoti57]

I think you're seeing checksum errors because of the reliability of the evofw3 device you're using.
There's no change in the manchester encoding and I see no evidence of any chnage in the frame structure.

The biggest problem for the evofw3 ( and ramses_esp) firmware is the length of the new messages.

The DT4R binding sequence has the same characteristics as the HR93

063  I --- 22:014439 --:------ 22:014439 1FC9 024 0023095838670030C9583867000008583867001FC8583867
# A9.6A 99.6A.A5.6A.96.95 99.6A.A5.6A.96.95          I --- 22:014439 --:------ 22:014439 
A9.55.5A.69 A9.6A                                    1FC9 024 
AA.AA A6.A5.AA.69 99.6A.A5.6A.96.95                  00 2309 583867 
AA.AA A5.AA.5A.69 99.6A.A5.6A.96.95                  00 30C9 583867
AA.AA AA.AA.AA 6A.99.6A.A5.6A.96.95                  00 0008 583867
AA.AA A9.55.5A.6A 99.6A.A5.6A.96.95                  00 1FC8 583867
AA.66.

583867 is 22:014439

Again offering 1FC8 for the binding algorithm

However no other new message formats in the rest of the log file.

[ghoti57]

I'm just manually reformatting these messages by referencing the ramses protocol wiki that @zxdavb wrote while he was developing ramses_rf (for @silverailscolo's benefit)

[Tchirana]

I think you're seeing checksum errors because of the reliability of the evofw3 device you're using. There's no change in the manchester encoding and I see no evidence of any chnage in the frame structure.

The biggest problem for the evofw3 ( and ramses_esp) firmware is the length of the new messages.

The DT4R binding sequence has the same characteristics as the HR93

063  I --- 22:014439 --:------ 22:014439 1FC9 024 0023095838670030C9583867000008583867001FC8583867
# A9.6A 99.6A.A5.6A.96.95 99.6A.A5.6A.96.95          I --- 22:014439 --:------ 22:014439 
A9.55.5A.69 A9.6A                                    1FC9 024 
AA.AA A6.A5.AA.69 99.6A.A5.6A.96.95                  00 2309 583867 
AA.AA A5.AA.5A.69 99.6A.A5.6A.96.95                  00 30C9 583867
AA.AA AA.AA.AA 6A.99.6A.A5.6A.96.95                  00 0008 583867
AA.AA A9.55.5A.6A 99.6A.A5.6A.96.95                  00 1FC8 583867
AA.66.

583867 is 22:014439

Again offering 1FC8 for the binding algorithm

However no other new message formats in the rest of the log file.

ATmega328P nanocul. Whst is the best one to use? I have had issues with this even woth the old firmware on the controller. I'll get a proper device and put the CC on it

[ghoti57]

Just a thought on the 0502 message earlie i.e.

053  I --- 04:118841 01:226586 --:------ 0502 076 0008000A75C6BF8E3E6351200FA3D82BB08DE5622F63640C30C541A91D0A95E7E0BF3ADB52713CF4110D61FA9B142B4CA90966D856A13AAFE6C4BE28D11CEC1C * Too long 
# 69.5A A9.A9.59.AA.A5.69 AA.95.95.99.A9.66
AA.99.AA.A6.9A.5A.AA.AA.AA.6A.AA.AA.AA.66.95.99.       0008000A75C6BF8E
5A.96.65.55.6A.56.A5.56.96.A5.99.A9.A6.AA.AA.55.       3E6351200FA3D82B
66.A5.59.6A.A6.65.65.AA.6A.59.56.99.96.A6.A6.55.       B08DE5622F63640C 
96.A5.96.9A.AA.5A.A5.AA.5A.99.9A.A9.66.69.A9.59.       30C541A91D0A95E7
AA.66.69.99.56.95.56.AA.65.55.A5.66.59.65.99.A6.       E0BF3ADB52713CF4
95.A9.A5.5A.55.9A.A9.A9.AA.59.96.A9.55.66.69.65.       110D61FA9B142B4C
A9.9A.A6.65.9A.5A.66.69.AA.69.96.96.59.6A.99.96.       A90966D856A13AAF
66.A9.A5.66.66.55.56.96.5A.9A.65.56.A6.6A.59.A9.       E6C4BE28D11CEC1C * Too long
A9.5A.56.5A.A9.5A.69.A6.55.6A.96.69.9A.55.9A.56.
69.A6.69.56.

(Note: I've edited the reformatted raw data above)

The payload begins
AA.AA.AA.6A AA.AA.AA 0008 000A

Could this be 8 (4 byte values) and 10 (4 byte values)
That does make a payload of 2+2+32+40=76

No idea what it would represent