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

galaxy_explorer · April 11, 2023, 5:40pm

I recently purchased a Nuaire Drimaster (DRI-ECO-HEAT-HC) and I’ve been testing RAMSES_CC with it but I am unsure what to expect. I don’t have a RF 4-way switch (DRI-ECO-4S) to play with as I couldn’t justify the expensive price tag

A few HA entities are created but most are showing “unavailable”. I was expecting to see entities like fan speed (0 to 6), operating mode (1 to 5), heater mode (auto/off), boost mode (boost/normal), runtime hours, filter status, etc. I was wondering whether anyone else could share their experiences with the Nuaire Drimaster.

My other question, is it possible to “bind” a faked remote without a physical one. In other words, can I put the Nuaire Drimaster into binding mode and then send a bind request (“Boost” message) from a “faked” remote. This would avoid the need to purchase one, especially as it will never be used again once it has been faked in HA

Entities from my HA instance
Nuaire

Screenshot from the Nuaire remote monitoring tool (DRI-ECO-RM)
Nuaire_Remote

zxdavb · April 12, 2023, 5:16am

I also have a DRI-ECO-HEAT-HC - and it was the first HVAC device supported by ramses_rf/ramses_cc.

For those who do not know, it is a PIV (positive input ventilation) fan - like an extractor fan (EXT), but it blows into the house, and not out.

This is an architectural problem:

there is a wide variation in attributes between - and within - all the FAN subtypes (HRUs, PIVs, and EXTs)
some of the physical fans also include other HVAC devices, such as CO2 sensors, etc.
but ramses_rf/ramses_cc basically treats all fans the same (as FANs).

So, what you will see is all available sensors, etc. for the device, but many will be unavailable.

This need addressing, but in the meantime, you can simply disable the unavailable entities.

I cannot recall any more specifics that that, as my PIV is currently decommissioned (I could look through old logs, given time, but see below).

Yes, you can do as you describe (faking a remote, REM). You can also fake a CO2 sensor (CO2), and and humidity sensor (HUM).

You have also described how it is done - simply follow the wiki here and here, and let me know how you get on.

Those wiki pages need tidying up…

BTW, I woudl really like a packet log that includes the DRI-ECO-RM binding to the PIV, and it retreiving the run-time and status - it is not clear to me if that is compatible with the RAMSES II protocol, or not.

zxdavb · April 12, 2023, 5:19am

To be clear, you:

create a faked remote
put the PIV into binding mode
issue the bind request

Then, at anytime in the future, you can:

issue the boost request.

galaxy_explorer · April 12, 2023, 8:25pm

@zxdavb, thanks for your detailed response. I’ve done some more testing and I have the impression that binding a faked Nuaire 4-way switch remote (DRI-ECO-4S) isn’t possible. The Nuaire Drimaster doesn’t use a normal pairing request but it expects the “Boost” and “Heater Off” commands to be sent and held. I expect this a special binding command that would need to be captured from the log but without a physical switch I can’t do that. Furthermore, I don’t know whether the concept of “hold” for 2 to 5 seconds is supported in the remote or whether it’s actually required for binding.

Extract from DRI-ECO-4S manual below.

For my sanity, he is my configuration and methods I tried to use to bind.

# configuration.yaml
ramses_cc:
  serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
  restore_cache:
    restore_schema: false
    restore_state: false
  advanced_features:
    send_packet: true
  packet_log:
    file_name: evohome_ramses.log
  ramses_rf:
    enforce_known_list: false
    enable_eavesdrop: true
  orphans_hvac: [30:098165, 32:222222]
  known_list:
    30:098165: {class: FAN} # Nuaire PIV
    32:222222:
      class: REM
      faked: true
      commands:
        normal:      ' I --- 32:222222 30:098165 --:------ 22F1 003 00020A'
        boost:       ' I --- 32:222222 30:098165 --:------ 22F1 003 00030A'
        heater_auto: ' I --- 32:222222 30:098165 --:------ 22F1 003 000A0A'
        heater_off:  ' I --- 32:222222 30:098165 --:------ 22F1 003 00090A'
      _note: Nuaire DRI-ECO-4S (4-way switch)

I also tried the following service calls for the binding request


# send_command service
service: remote.send_command
data:
  command: boost
  hold_secs: 10
target:
  entity_id: remote.32_222222

# fake_device service
service: ramses_cc.fake_device
data:
  device_id: "32:222222"
  create_device: false
  start_binding: true

It looks like I may need to save up my pennies and buy the overpriced switch (DRI-ECO-4S).

zxdavb · April 12, 2023, 11:31pm

Unfortunately, I am not at home (and wont be for another few months), so we cannot benefit from the 4-way switch that I have there… Nor can I find a binding of that particular switch in the logs I do have access to…

However, your conclusion may not be sound - holding those two buttons down may simply be the way you get it to send the bind request (I|1FC9).

If you’re willing to try again/more…

Please confirm that you are not using a HGI80.

Please use the device id 32:206251 for the switch.

Please provide packet logs taken during your binding attempts.

Try the bind request again, but the other thing you could try is simply sending a 22F1 command.

galaxy_explorer · April 13, 2023, 10:13am

@zxdavb I updated the switch ID to use 32:206251

I tried to send a raw packet as follows, I was unsure on the exact format. How is the source identifier from the 4-way switch get sent? What is the payload for the bind request?

# send packet
service: ramses_cc.send_packet
data:
  device_id: '30:098165'
  verb: I
  code: 1FC9
  payload: FF

I also tried the send command, it didn’t work either.

# send_command service
service: remote.send_command
data:
  command: boost
target:
  entity_id: remote.32_206251

I also tried the fake device command, it didn’t work either.

# fake_device service
service: ramses_cc.fake_device
data:
  device_id: "32:206251"
  create_device: false
  start_binding: true

I probably need to wait until your return or buy the switch! … it’s not urgent, so we can tackle this later if preferred. I will send my log nevertheless.

zxdavb · April 13, 2023, 12:28pm

When you use this service call:

service: ramses_cc.fake_device
data:
  device_id: "32:206251"
  create_device: false
  start_binding: true

Here is a corresponding fragment from the packet log - all I have done is delete uninteresting packets:

2023-04-13T11:08:27.804124 000  I --- 32:206251 --:------ 32:206251 1FC9 018 0022F18325AB0022F38325AB001FC98325AB
2023-04-13T11:08:27.852074 063  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-13T11:08:28.952348 063  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-13T11:08:30.052433 064  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75

2023-04-13T11:08:30.786438 000  I --- 32:206251 --:------ 32:206251 1FC9 018 0022F18325AB0022F38325AB001FC98325AB
2023-04-13T11:08:31.826676 000  I --- 32:206251 --:------ 32:206251 1FC9 018 0022F18325AB0022F38325AB001FC98325AB
2023-04-13T11:08:31.851551 063  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-13T11:08:32.951834 062  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75

2023-04-13T11:08:33.704896 000  I --- 32:206251 --:------ 32:206251 1FC9 018 0022F18325AB0022F38325AB001FC98325AB
2023-04-13T11:08:34.051998 062  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75

2023-04-13T11:08:36.312369 000  I --- 32:206251 --:------ 32:206251 1FC9 018 0022F18325AB0022F38325AB001FC98325AB
2023-04-13T11:08:36.352087 063  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-13T11:08:37.452426 062  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-13T11:08:38.552569 062  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75

Here, you can see the initial packet (the I|1FC9), followed by a valid response from the PIV (W|1FC9). The retransmits are within reason.

I don’t know why, but the final I|1FC9 of the 3-step handshake is not being transmitted by ramses_rf…

NOTE: this is good news - the PIV responded to the bind request from the faked remote!

IIRC, this bug has been around for a while?

Not sure, but I think I recall that other (non-Nuaire) switches/remotes have been surviving with the missing 3rd step, but it must be the case that Nuaire isn’t tolerating this issue.

Lemme think about next steps… Probably best I create a test suite for it.

What you can try is to send this bespoke packet immediately after the fake_device service call…

 I --- 32:206251 30:098165 --:------ 1FC9 001 00

So you will want something like this in your packet log:

2023-04-13T11:08:36.000000 000  I --- 32:206251 --:------ 32:206251 1FC9 018 0022F18325AB0022F38325AB001FC98325AB
2023-04-13T11:08:36.500000 063  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-13T11:08:36.990000 000  I --- 32:206251 30:098165 --:------ 1FC9 001 00

galaxy_explorer · April 16, 2023, 9:25pm

@zxdavb thanks for investigating this. I put together a simple automation to trigger the bespoke packet directly after the fake_device call but it didn’t seem to work. It could be because I didn’t construct the bespoke send_packet correctly or it is not impersonating the PIV unit. The log (extract below) seems to indicate the request is coming from the gateway (SSM-D2) which makes sense but could this be why it’s not working?

Automation script using for testing

alias: " Nuaire 4-way switch fake binding"
description: ""
trigger: []
condition: []
action:
  - service: ramses_cc.fake_device
    data:
      device_id: "32:206251"
      create_device: false
      start_binding: true
  - service: ramses_cc.send_packet
    data:
      device_id: "32:206251"
      verb: I
      code: 1FC9
      payload: "00"
mode: single

Log file extract

2023-04-16T22:13:08.521034 072  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-16T22:13:09.428142 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878BEA200A31464339204936333A323632313432
2023-04-16T22:13:09.674133 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878BEA200A31464339204936333A323632313432
2023-04-16T22:13:09.878178 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878BEA200A31464339204936333A323632313432
2023-04-16T22:13:10.078352 000  I --- 32:206251 --:------ 32:206251 1FC9 018 0022F18325AB0022F38325AB001FC98325AB
2023-04-16T22:13:10.121121 072  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-16T22:13:10.185110 000  I --- 18:068640 32:206251 --:------ 1FC9 001 00
2023-04-16T22:13:11.215272 000  I --- 18:068640 32:206251 --:------ 1FC9 001 00
2023-04-16T22:13:12.222849 000  I --- 18:068640 32:206251 --:------ 1FC9 001 00
2023-04-16T22:13:12.321492 073  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-16T22:13:13.244771 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878BEA2EF331464339204936333A323632313432
2023-04-16T22:13:13.489728 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878BEA2EF331464339204936333A323632313432
2023-04-16T22:13:13.736777 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878BEA2EF331464339204936333A323632313432
2023-04-16T22:13:13.937660 000  I --- 32:206251 --:------ 32:206251 1FC9 018 0022F18325AB0022F38325AB001FC98325AB
2023-04-16T22:13:14.021615 072  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-16T22:13:14.049608 000  I --- 18:068640 32:206251 --:------ 1FC9 001 00
2023-04-16T22:13:15.086730 000  I --- 18:068640 32:206251 --:------ 1FC9 001 00
2023-04-16T22:13:15.121821 070  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-16T22:13:16.099058 000  I --- 18:068640 32:206251 --:------ 1FC9 001 00
2023-04-16T22:13:16.221093 072  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-16T22:13:17.123090 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878BEA3E1931464339204936333A323632313432
2023-04-16T22:13:17.370122 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878BEA3E1931464339204936333A323632313432
2023-04-16T22:13:17.574229 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878BEA3E1931464339204936333A323632313432
2023-04-16T22:13:17.776260 000  I --- 32:206251 --:------ 32:206251 1FC9 018 0022F18325AB0022F38325AB001FC98325AB
2023-04-16T22:13:17.821137 074  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-16T22:13:17.847110 000  I --- 18:068640 32:206251 --:------ 1FC9 001 00
2023-04-16T22:13:18.875283 000  I --- 18:068640 32:206251 --:------ 1FC9 001 00
2023-04-16T22:13:18.921351 074  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-16T22:13:19.880526 000  I --- 18:068640 32:206251 --:------ 1FC9 001 00
2023-04-16T22:13:20.021606 074  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-16T22:13:20.905722 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878BEA4CE031464339204936333A323632313432
2023-04-16T22:13:21.151818 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878BEA4CE031464339204936333A323632313432
2023-04-16T22:13:21.359689 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878BEA4CE031464339204936333A323632313432
2023-04-16T22:13:21.557761 000  I --- 32:206251 --:------ 32:206251 1FC9 018 0022F18325AB0022F38325AB001FC98325AB
2023-04-16T22:13:21.621766 073  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-16T22:13:21.696723 000  I --- 18:068640 32:206251 --:------ 1FC9 001 00
2023-04-16T22:13:22.724805 074  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-16T22:13:22.731841 000  I --- 18:068640 32:206251 --:------ 1FC9 001 00
2023-04-16T22:13:23.729071 000  I --- 18:068640 32:206251 --:------ 1FC9 001 00
2023-04-16T22:13:23.822012 074  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75

galaxy_explorer · April 16, 2023, 9:49pm

@zxdavb on my second attempt, I created a new remote command with the bespoke binding command (as below) and then retried the modified automation but still no luck, however probably closer to success…

  known_list:
    30:098165: {class: FAN} # Nuaire PIV
    32:206251:
      class: REM
      faked: true
      commands:
        normal:      ' I --- 32:206251 30:098165 --:------ 22F1 003 00020A'
        boost:       ' I --- 32:206251 30:098165 --:------ 22F1 003 00030A'
        heater_auto: ' I --- 32:206251 30:098165 --:------ 22F1 003 000A0A'
        heater_off:  ' I --- 32:206251 30:098165 --:------ 22F1 003 00090A'
        bind:        ' I --- 32:206251 30:098165 --:------ 1FC9 001 00'
      _note: Nuaire DRI-ECO-4S (4-way switch)

Modified automation

alias: " Nuaire 4-way switch fake binding"
description: ""
trigger: []
condition: []
action:
  - service: ramses_cc.fake_device
    data:
      device_id: "32:206251"
      create_device: false
      start_binding: true
  - service: ramses_cc.send_command
    data:
      repeats: 3
      delay: 0.2
      command: bind
      entity_id: remote.32_206251
mode: single

Log extract

2023-04-16T22:47:00.435411 056  I --- 01:182924 --:------ 01:182924 0008 002 FA00
2023-04-16T22:47:00.453883 056  I --- 01:182924 --:------ 01:182924 0008 002 F900
2023-04-16T22:47:09.586352 000 RQ --- 18:068640 13:088711 --:------ 3EF1 001 00
2023-04-16T22:47:09.600356 073 RP --- 13:088711 18:068640 --:------ 3EF1 007 00003C003C00FF
2023-04-16T22:47:09.932335 000 RQ --- 18:068640 13:182591 --:------ 3EF1 001 00
2023-04-16T22:47:09.946304 086 RP --- 13:182591 18:068640 --:------ 3EF1 007 00003C003C00FF
2023-04-16T22:47:16.746523 076  I --- 04:262143 --:------ 04:262143 30C9 003 000747
2023-04-16T22:47:25.712607 000 RQ --- 18:068640 01:182924 --:------ 1260 001 00
2023-04-16T22:47:25.728459 056 RP --- 01:182924 18:068640 --:------ 1260 003 001661
2023-04-16T22:47:25.909569 000 RQ --- 18:068640 13:182591 --:------ 0008 001 00
2023-04-16T22:47:25.920501 087 RP --- 13:182591 18:068640 --:------ 0008 002 0000
2023-04-16T22:47:29.056005 000 RQ --- 18:068640 01:182924 --:------ 1F41 001 00
2023-04-16T22:47:29.074003 057 RP --- 01:182924 18:068640 --:------ 1F41 006 000000FFFFFF
2023-04-16T22:47:32.631552 000 RQ --- 18:068640 01:182924 --:------ 0418 003 000000
2023-04-16T22:47:32.659503 056 RP --- 01:182924 18:068640 --:------ 0418 022 004000B004050100000046976548FFFFFF7000109BEF
2023-04-16T22:47:34.395936 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878C09A25231464339204936333A323632313432
2023-04-16T22:47:34.640870 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878C09A25231464339204936333A323632313432
2023-04-16T22:47:34.844820 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878C09A25231464339204936333A323632313432
2023-04-16T22:47:35.044751 000  I --- 32:206251 --:------ 32:206251 1FC9 018 0022F18325AB0022F38325AB001FC98325AB
2023-04-16T22:47:35.106921 067  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-16T22:47:35.696001 000 RQ --- 18:068640 01:182924 --:------ 2E04 001 FF
2023-04-16T22:47:35.714828 056 RP --- 01:182924 18:068640 --:------ 2E04 008 01FFFFFFFFFFFF00
2023-04-16T22:47:36.207175 067  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-16T22:47:36.772285 067 RQ --- 30:098165 32:206251 --:------ 10E0 001 00
2023-04-16T22:47:37.137294 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878C09AD0731464339204936333A323632313432
2023-04-16T22:47:37.307197 067  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-16T22:47:37.382251 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878C09AD0731464339204936333A323632313432
2023-04-16T22:47:37.586311 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878C09AD0731464339204936333A323632313432
2023-04-16T22:47:37.786340 000  I --- 32:206251 --:------ 32:206251 1FC9 018 0022F18325AB0022F38325AB001FC98325AB
2023-04-16T22:47:37.805247 067 RQ --- 30:098165 32:206251 --:------ 10E0 001 00
2023-04-16T22:47:38.826499 000  I --- 32:206251 --:------ 32:206251 1FC9 018 0022F18325AB0022F38325AB001FC98325AB
2023-04-16T22:47:38.907344 068  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-16T22:47:39.370820 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878C09B5C031464339204936333A323632313432
2023-04-16T22:47:39.614610 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878C09B5C031464339204936333A323632313432
2023-04-16T22:47:39.820709 000  I --- 18:068640 63:262142 --:------ 7FFF 023 001101878C09B5C031464339204936333A323632313432
2023-04-16T22:47:40.010952 067  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75
2023-04-16T22:47:40.029630 000  I --- 32:206251 --:------ 32:206251 1FC9 018 0022F18325AB0022F38325AB001FC98325AB
2023-04-16T22:47:41.107718 068  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75

RedSnowDonkey · April 19, 2023, 2:54pm

Hi. I have a Nuaire Drimaster DRI-ECO-HEAT-HC and an evofw3 SSM-D2 dongle. I’ve gotten the dongle to show up and configured it (the basics) but now I’m getting a tad lost…

I’m not finding the documentation all too helpful, but I’ve started to try to piece things together to register some allowed devices (as I’ve found some “devices” from my previous logs) with the following config (trying to include a faked remote as another post suggested it):

  serial_port: /dev/ttyACM1
  orphans_hvac: [32:123456]
  known_list:
    30:071135: {class: FAN}
    18:070418: {class: RFS}
    63:262142: {class: OTB}
    32:123456: {class: REM, faked: true}

My log now shows (amongst other things):

2023-04-19 15:45:53.434 WARNING (MainThread) [ramses_rf.protocol.schemas] Best practice is exactly one gateway (HGI) in the known_list: []
2023-04-19 15:45:53.447 WARNING (MainThread) [ramses_rf.protocol.schemas] It is strongly recommended to use the known_list as a whitelist (device_id filter), configure: enforce_known_list = True
2023-04-19 15:45:57.959 WARNING (MainThread) [ramses_rf.protocol.transport] Not using any device filter: using a known_list (as a whitelist) is strongly recommended)
2023-04-19 15:45:57.964 WARNING (MainThread) [ramses_rf.protocol.parsers] I --- 30:071135 63:262142 --:------ 10E0 038 000001C90023006CFEFEFFFFFFFF1C0707E5425244472D30324A415330310000000000000000 < Support the development of ramses_rf by reporting this packet, with the make/model of device: RFG:071135 (device type 30 not known to have signature: 0001C90023006CFEFE)
2023-04-19 15:46:04.122 WARNING (MainThread) [ramses_rf.protocol.transport] Not using any device filter: using a known_list (as a whitelist) is strongly recommended)
2023-04-19 15:46:04.200 WARNING (MainThread) [ramses_rf.protocol.transport] I --- 18:070418 63:262142 --:------ 7FFF 016 0010018799FAD06676302E32312E3430 < Active gateway set to: 18:070418

There’s a ton of new entites turning up but most of them are unavailable (so I’ve obviously misconfigured something).

I’m now baffled as to what to do next - I’ve probably done something wrong in the config but I really don’t understand what I’m doing (and can’t understand the instructions - they seem to just leap between “here’s a simple config” to “now just put loads of things in your config (when we haven’t explained how to work out what to put in)” - no offence meant - I know how difficult this all can be!).

I’m not a complete newbie, having coded my way around a few things in the past, but this is completely baffling me and I’d appreciate some help, if someone has the time to explain what I’ve done wrong and need to do next…

Thanks (in hope)!

zxdavb · April 19, 2023, 10:39pm

RedSnowDonkey:

 serial_port: /dev/ttyACM1
  orphans_hvac: [32:123456]
  known_list:
    30:071135: {class: FAN}
    18:070418: {class: RFS}
    63:262142: {class: OTB}
    32:123456: {class: REM, faked: true}

For now, change the above to this:

ramses_cc:
  serial_port: /dev/ttyACM1
  orphans_hvac: [30:071135, 32:123456]
  known_list:
    18:070418: {class: HGI}
    30:071135: {class: FAN}
    32:123456:
      class: REM
      faked: true
      commands:
        normal:      ' I --- 32:206251 30:098165 --:------ 22F1 003 00020A'
        boost:       ' I --- 32:206251 30:098165 --:------ 22F1 003 00030A'
        heater_auto: ' I --- 32:206251 30:098165 --:------ 22F1 003 000A0A'
        heater_off:  ' I --- 32:206251 30:098165 --:------ 22F1 003 00090A'
        bind:        ' I --- 32:206251 30:098165 --:------ 1FC9 001 00'

ANd send us (PM if you like) a 24h log.

RedSnowDonkey · April 20, 2023, 8:34am

zxdavb:

ramses_cc:
  serial_port: /dev/ttyACM1
  orphans_hvac: [30:071135, 32:123456]
  known_list:
    18:070418: {class: HGI}
    30:071135: {class: FAN}
    32:123456:
      class: REM
      faked: true
      commands:
        normal:      ' I --- 32:206251 30:098165 --:------ 22F1 003 00020A'
        boost:       ' I --- 32:206251 30:098165 --:------ 22F1 003 00030A'
        heater_auto: ' I --- 32:206251 30:098165 --:------ 22F1 003 000A0A'
        heater_off:  ' I --- 32:206251 30:098165 --:------ 22F1 003 00090A'
        bind:        ' I --- 32:206251 30:098165 --:------ 1FC9 001 00'

Very quick reply - thank you. I’ve made the change, rebooted, but still getting a ton of unavailable entities and not much in the way of functions (that I can work out, at least).

I’m not entirely sure which log to copy (I’m just looking at the Home Assistant Core log in the UI for now, as the others don’t seem too relevant):

2023-04-20 09:26:13.015 WARNING (MainThread) [custom_components.ramses_cc.schemas] Using a merged schema (cached schema is not a superset of config schema), if required, use 'restore_cache: restore_schema: false'
2023-04-20 09:26:13.091 WARNING (MainThread) [ramses_rf.protocol.schemas] It is strongly recommended to use the known_list as a whitelist (device_id filter), configure: enforce_known_list = True
2023-04-20 09:26:14.171 WARNING (MainThread) [ramses_rf.protocol.transport] Not using any device filter: using a known_list (as a whitelist) is strongly recommended)
2023-04-20 09:26:14.237 WARNING (MainThread) [ramses_rf.protocol.parsers] I --- 30:071135 63:262142 --:------ 10E0 038 000001C90023006CFEFEFFFFFFFF1C0707E5425244472D30324A415330310000000000000000 < Support the development of ramses_rf by reporting this packet, with the make/model of device: RFG:071135 (device type 30 not known to have signature: 0001C90023006CFEFE)
2023-04-20 09:26:18.421 WARNING (MainThread) [ramses_rf.protocol.transport] RQ --- 18:070418 13:173115 --:------ 0008 001 00 < Active gateway set to: 18:070418
2023-04-20 09:26:22.878 WARNING (MainThread) [homeassistant.setup] Setup of ramses_cc is taking over 10 seconds.
2023-04-20 09:26:23.792 WARNING (MainThread) [ramses_rf.protocol.transport] Not using any device filter: using a known_list (as a whitelist) is strongly recommended)

There doesn’t seem to be anything else of relevance in there so far… and the remote switch (remote.32_123456) doesn’t do anything (it fails)…

Any ideas or pointers?

Jemster · April 20, 2023, 9:16am

I’ve the same setup with the Eco Drimaster Heat. Lots of unavailable properties. But from looking at the logs I think that is just because the unit doesn’t monitor / support these values.

I do have the 4 way remote already bound to my drimaster unit, so I watched the packet logs while pressing buttons and got all the IDs I needed from there.

I then hooked up some automations in HA and it has been happily turning on the heat on cold days in the afternoon and turning it off at bedtime for the past few months. Nice!

Can post some config when I get home but I think it looks similar to your own. You don’t have a physical remote switch you can bind even temporarily?

galaxy_explorer · April 20, 2023, 9:54am

I would definitely be interested in seeing your configuration.

That is the very problem we are trying to solve, i.e. bind a “faked” switch that doesn’t physically exist. I am sure that @zxdavb would appreciate a packet log from the 4-way switch (DRI-ECO-4S) “binding” process (see below) but I appreciate that you may not want to do this if your PIV unit is installed and working

zxdavb · April 20, 2023, 10:00am

Sure: please provide a packet log that is ~24h in duration and I can help you best.

I can see that the system is corrupted by the previous config:

… so, add this to your config:

ramses_cc:
  restore_cache: 
    restore_schema: false

… then restart HA. Once restarted, you can remove it (the whole restore_cache: section). There will be no need to reboot HA again - the configuration setting is used only when HA is next restarted.

The 4-way switch needs to be bound to the Nuaire PIV (the FAN); see the posts from @galaxy_explorer , above.

Correct. For a Nuaire PIV, most will be unavailable - but @RedSnowDonkey should sort out his schema first, before jumping to any permanent conclusions.

Part of the difficulty that @galaxy_explorer is having when creating a fully-faked 4-way switch is because I don’t have a packet log of one being bound to a PIV - would @Jemster kindly help us (me, @galaxy_explorer & @RedSnowDonkey) out by re-binding his switch to the PIV, whilst recording a packet log, and then posting it here?

It woudl look like this (spaces and dashes added to payloads for readability):

 I --- 32:111111 --:------ 32:111111 1FC9 018 00-22F1-A1B207 00-22F3-A1B207 00-1FC9-A1B207
 W --- 30:888888 32:111111 --:------ 1FC9 006 00-22F1-119038
 I --- 32:111111 30:888888 --:------ 1FC9 006 00-1FC9-59B207

(22F1 and 22F3 are the relevant command classes)

zxdavb · April 20, 2023, 10:35am

You’re on the right track!

OK, with either method (and previously), we got this:

2023-04-16T22:13:10.078352 000  I --- 32:206251 --:------ 32:206251 1FC9 018 0022F18325AB0022F38325AB001FC98325AB
2023-04-16T22:13:10.121121 072  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75

(I hadn’t noticed the 21 at the start of the payload until now)

As I said, the good news is that the FAN (the Nuaire PIV) liked the first packet from the faked REM (the faked 4-way switch) enough that it made

Parsed, the above gives:

22:13:10.078 ||  32:206251 |            |  I | rf_bind          | [..] || {'phase': 'offer', 'bindings': [['00', '22F1', '32:206251'], ['00', '22F3', '32:206251'], ['00', '1FC9', '32:206251']]}
22:13:10.121  W --- 30:098165 32:206251 --:------ 1FC9 006 2131DA797F75 < Corrupt payload: Payload doesn't match '^((0[0-9A-F]|F[69ABCF])([0-9A-F]{10}))+$': 2131DA797F75

It should look like this (spaces added for readability):

22:13:10.078 ||  32:206251 |            |  I | rf_bind          | [..] || {'phase': 'offer',  'bindings': [['00', '22F1', '32:206251'], ['00', '22F3', '32:206251'], ['00', '1FC9', '32:206251']]}
22:13:10.121 ||  30:098165 |  32:206251 |  W | rf_bind          | [..] || {'phase': 'accept', 'bindings': [['00', '31DA', '30:098165']]}

Because the second packet isn’t accepted by ramses_rf, it can’t be passed up to the faked remote, and it wont subsequently respond.

The issue is that the payload starts with 21 (2131DA797F75) instead of 00 (0031DA797F75).

Sigh.

The above is an example of one of the difficulties I’ve had working with an undocumented protocol… IN this case, early in development, they were all 00 - always!

Then, after some time (over a year), I ran into HVAC (all dev had been for CH/DHW before that), and other values became acceptable.

I ‘Sigh’ because fixing it in the codebase will take some time/effort… I will PM you, I think - we may have a workaround.

RedSnowDonkey · April 20, 2023, 11:17am

Ok. So I’ve updated my config (again) as I don’t think the previous values of the devices weren’t quite correct (as they were Galaxy’s, not mine):

ramses_cc:
  restore_cache: 
    restore_schema: false
  serial_port: /dev/ttyACM1
  orphans_hvac: [30:071135, 32:206251]
  known_list:
    18:070418: {class: HGI}
    30:071135: {class: FAN}
    32:206251:
      class: REM
      faked: true
      commands:
        normal:      ' I --- 32:206251 30:071135 --:------ 22F1 003 00020A'
        boost:       ' I --- 32:206251 30:071135 --:------ 22F1 003 00030A'
        heater_auto: ' I --- 32:206251 30:071135 --:------ 22F1 003 000A0A'
        heater_off:  ' I --- 32:206251 30:071135 --:------ 22F1 003 00090A'
        bind:        ' I --- 32:206251 30:071135 --:------ 1FC9 001 00'

Unfortunately, I can’t get the remote to do anything, including sending a bind command (although I can get the PIV into Binding Mode, as per the instructions). I tried to follow the ‘binding automation’ route but no joy (and just a few errors in my logs, including the ‘fake remote’ not accepting any parameters, the ‘send packet’ command not existing, and an equivalent ‘send remote command’ not working).

Happy to hang tight there, but how do I get a “packet log”? I can’t seem to see that option in the System/Logs UI menu…

zxdavb · April 20, 2023, 12:41pm

See: here

sciorty · April 20, 2023, 8:23pm

Sorry, I finally had the occasion to move the dongle closer to the machine (just 1m under), still no luck. I also tuned the antenna (Arduino UNO + CC1101 with latest evofw):

# !F F=21656a
# !F Tune
# !c 0d 21 65 6a
# !c 0d 21 65 5a
045  I --- 32:126818 32:142858 --:------ 22F1 003 000207
# !c 0d 21 65 4a
071  I 239 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
# !c 0d 21 65 3a
073  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06DB7FFF079806B6F000004150500000EFEF7FFF7FFF00
# !c 0d 21 65 2a
046  I --- 32:126818 32:142858 --:------ 22F1 003 000207
# !c 0d 21 65 1a
073  I 240 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
# !c 0d 21 65 0a
072  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06DA7FFF079806B6F000004150500000EFEF7FFF7FFF00
# !c 0d 21 64 fa
044  I --- 32:126818 32:142858 --:------ 22F1 003 000307
# !c 0d 21 64 ea
072  I 241 32:142858 --:------ 32:142858 31D9 017 002A030020202020202020202020202008
# !c 0d 21 64 da
072  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06DA7FFF079606B4F00000428C8C0000EFEF7FFF7FFF00
# !c 0d 21 64 ca
043  I --- 32:126818 32:142858 --:------ 22F1 003 000307
# !c 0d 21 64 ba
070  I 242 32:142858 --:------ 32:142858 31D9 017 00 * Invalid Manchester Code
# A9.66.6A.A6.A6.56.AA.66.6A.A6.A6.56.AA.66.55.A6.A5.A9.59.69.A9.A9.AA.AA.A6.E6.
073  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06DA7FFF079706B5F00000428C8C0000EFEF7FFF7FFF00
# !c 0d 21 64 aa
044  I --- 32:126818 --:------ --:------ ???? ???  * Invalid Manchester Code
# A9.5A.6A.A9.56.55.96.A6.7F.
# !F F=2164aa tuning
# !F F=2164aa tuning
# !F F=2164aa tuning
# !F F=2164aa tuning
# !F F=2164aa tuning
# !F F=2164aa tuning
# !F F=2164aa tuning
# !F F=2164aa tuning
# !c 0d 21 64 b2
# !c 0d 21 64 b6
071  I --- 32:142858 --:------ 32:142858 ???? ???  * Invalid Manchester Code
# A9.6A.6A.A6.A6.56.AA.66.6A.A6.A6.56.AA.66.B5.
070  I 248 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
069  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06D57FFF079406AEF000004150500000EFEF7FFF7FFF00
072  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06E37FFF079006BDF000004150500000EFEF7FFF7FFF00
070  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06E77FFF078F06C7F000004150500000EFEF7FFF7FFF00
072  I --- 32:142858 --:------ 32:142858 313F 009 007C1C130C1F0107D0
071  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06EB7FFF078F06C7F000004150500000EFEF7FFF7FFF00
071  I 252 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
071  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06F07FFF079006CFF000004150500000EFEF7FFF7FFF00
069  I --- 32:142858 --:------ 32:142858 313F 009 007C1D310C1F0107D0
073  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06E57FFF079106C1F000004150500000EFEF7FFF7FFF00
072  I 254 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
071  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06F27FFF079006D2F000004150500000EFEF7FFF7FFF00
071  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF07007FFF079106E8F000004150500000EFEF7FFF7FFF00
071  I 001 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
070  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06F37FFF079106CFF000004150500000EFEF7FFF7FFF00
070  I --- 32:142858 --:------ 32:142858 313F 009 007C1F310D1F0107D0
072  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF07017FFF079106E7F000004150500000EFEF7FFF7FFF00
071  I 003 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
070  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06FC7FFF079206DFF000004150500000EFEF7FFF7FFF00
070  I --- 32:142858 --:------ 32:142858 313F 009 007C21130E1F0107D0
072  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF07017FFF079106E7F000004150500000EFEF7FFF7FFF00
073  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF07137FFF079206F9F000004150500000EFEF7FFF7FFF00
070  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF071C7FFF07900709F000004150500000EFEF7FFF7FFF00
073  I --- 32:142858 --:------ 32:142858 313F 009 007C25310F1F0107D0
071  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF07127FFF078F06F8F000004150500000EFEF7FFF7FFF00
071  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF07127FFF078F06FBF000004150500000EFEF7FFF7FFF00
072  I 011 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
070  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF07117FFF079206FBF000004150500000EFEF7FFF7FFF00
071  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF07097FFF079206EBF000004150500000EFEF7FFF7FFF00
072  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF07077FFF079106E8F000004150500000EFEF7FFF7FFF00
073  I 013 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
072  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF07097FFF079306EBF000004150500000EFEF7FFF7FFF00
071  I 014 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
071  I 016 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
071  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06EE7FFF078E06CDF000004150500000EFEF7FFF7FFF00
071  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06E37FFF078C06C1F000004150500000EFEF7FFF7FFF00
071  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06E27FFF078D06BFF000004150500000EFEF7FFF7FFF00
070  I 026 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
072  I 029 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
071  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06E17FFF078906BCF000004150500000EFEF7FFF7FFF00
071  I --- 32:142858 --:------ 32:142858 313F 009 007C3231141F0107D0
071  I 030 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
071  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06DA7FFF078C06B2F000004150500000EFEF7FFF7FFF00
072  I --- 32:142858 --:------ 32:142858 313F 009 007C3313151F0107D0
071  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06DB7FFF078706B7F000004150500000EFEF7FFF7FFF00
# !F F=216519
# !F Saved F=216519

Logs on ramses integration have still the same behavior as before. It’s like the machine is discarding the messages, or the radio is able to receive but not to transmit. How could I test the radio TX?

zxdavb · April 21, 2023, 6:09am

Now, that rings a bell…

IIRC, if you install the evofw3 FW onto the dongle with the wrong bootloader (board manager?), then you can Rx but not Tx.

I suggest you see if reviewing issues at the evofw3 repo is helpful.

For example: nanoCUL not transmitting · Issue #31 · ghoti57/evofw3 · GitHub