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

sciorty · April 7, 2023, 4:19pm

Still nothing.
First of all, I think I previously did a mistake with the remote IDs: 32:126818 is the existing physical remote that I have, so I should not fake it I guess. Here an example of what a command looks like from the existing remote (so I’m just listening):

2023-04-07T18:05:29.449678 068  I --- 32:126818 32:142858 --:------ 22F1 003 000207
2023-04-07T18:05:29.588942 080  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06147FFF071305DAF000004150500000EFEF7FFF7FFF00

So I changed the configuration by creating a new remote (32:126819):

ramses_cc:
  serial_port: /dev/ttyACM0
  packet_log: packets.log
  advanced_features:
    send_packet: true
  ramses_rf:
    enforce_known_list: true
  orphans_hvac: [32:142858, 32:126818, 32:126819]
  known_list:
    32:142858 : {class: FAN} 
    32:126818:
      class: REM
    32:126819:
      class: REM
      faked: true
      commands:
        low:          ' I --- 32:126819 32:142858 --:------ 22F1 003 000207'
        medium:       ' I --- 32:126819 32:142858 --:------ 22F1 003 000307'
        high:         ' I --- 32:126819 32:142858 --:------ 22F1 003 000707'
        bypass_open:  ' W --- 32:126819 32:142858 --:------ 22F7 003 00C8EF'
        bypass_close: ' W --- 32:126819 32:142858 --:------ 22F7 003 0000EF'
        bypass_auto:  ' W --- 32:126819 32:142858 --:------ 22F7 003 00FFEF'
        reset_filter: ' W --- 32:126819 32:142858 --:------ 10D0 002 00FF'

I turned the machine off and then on, launched the fake_device service with the new ID that I created and then nothing new… If I launch the command the machine does not reply (as you can see is the same of the physical remote but with a different ID):

2023-04-07T18:07:00.540011 000  I --- 32:126819 32:142858 --:------ 22F1 003 000707

Unfortunately I do not have any LED visible on the machine to show eventual binding mode But I guess the procedure should be that.
Also, if I try to bind again the faked remote with the machine, the logs say: The device id already exists: 32:126819
Is it normal?

sciorty · April 7, 2023, 4:34pm

Ok maybe I had to remove the create_device: true since it was already present.

This are the errors I got once I try to pair the device:

Logger: ramses_rf.device.base
Source: custom_components/ramses_cc/__init__.py:125 
Integration: RAMSES RF (documentation, issues) 
First occurred: 18:30:11 (4 occurrences) 
Last logged: 18:30:46

Binding 32:126819 (REM): requesting (<Code._22F1: '22F1'>, <Code._22F3: '22F3'>)

And:

Logger: ramses_rf.protocol.message
Source: /usr/local/lib/python3.10/site-packages/ramses_rf/protocol/message.py:350 
First occurred: 18:30:16 (2 occurrences) 
Last logged: 18:30:48

I --- 32:126819 --:------ 32:126819 1FC9 018 0022F181E6F30022F381EF63001FC981EF63 < AssertionError()
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/message.py", line 331, in _validate
    result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/parsers.py", line 141, in wrapper
    result = fnc(payload, msg, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/parsers.py", line 1313, in parser_1fc9
    bindings = [
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/parsers.py", line 1314, in <listcomp>
    _parser(payload[i : i + 12])
  File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/parsers.py", line 1280, in _parser
    assert seqx[6:] == payload[6:12]  # all with same controller
AssertionError

zxdavb · April 7, 2023, 11:10pm

I would love to see this packet log, to check there is no error in the code. Please include the service call as yaml.

I think the easiest way is to simply impersonate the existing remote, which with be stateless with respect to 22F1 packets (i.e. it wont remember the last 22F1 it sent). That way, you don’t have to make any bindings.

Send a packet log of a 22F1 sent from both:
a) the physical switch/remote
b) the faked switch/remote, please include the service call as yaml too

Use this for now:

  known_list:
    32:142858 : {class: FAN} 
    32:126818:
      class: REM
      faked: true
      commands:
        low:          ' I --- 32:126818 32:142858 --:------ 22F1 003 000207'
        medium:       ' I --- 32:126818 32:142858 --:------ 22F1 003 000307'
        high:         ' I --- 32:126818 32:142858 --:------ 22F1 003 000707'
        bypass_open:  ' W --- 32:126818 32:142858 --:------ 22F7 003 00C8EF'
        bypass_close: ' W --- 32:126818 32:142858 --:------ 22F7 003 0000EF'
        bypass_auto:  ' W --- 32:126818 32:142858 --:------ 22F7 003 00FFEF'
        reset_filter: ' W --- 32:126818 32:142858 --:------ 10D0 002 00FF'

Finally, can you confirm the make / model of your fan / remote.

zxdavb · April 7, 2023, 11:49pm

This is simply a corrupted packet - note the bytes swapped around in the first element of the payload:

... 32:126819 1FC9 018 00-22F1-81E6F3 00-22F3-81EF63 00-1FC9-81EF63
... 32:126819                     6F             F6             F6

Does the same error occur every time? I suspect not. If you retry this (don’t bother, but let me know the result if you do), it likely wont happen again.

sciorty · April 8, 2023, 8:50am

So, this is my config now:

#RAMSES RF
ramses_cc:
  serial_port: /dev/ttyACM0
  packet_log: packets.log
  advanced_features:
    send_packet: true
  ramses_rf:
    enforce_known_list: true
  orphans_hvac: [32:142858, 32:126818]
  known_list:
    32:142858 : {class: FAN} 
    32:126818:
      class: REM
      faked: true
      commands:
        low:          ' I --- 32:126818 32:142858 --:------ 22F1 003 000207'
        medium:       ' I --- 32:126818 32:142858 --:------ 22F1 003 000307'
        high:         ' I --- 32:126818 32:142858 --:------ 22F1 003 000707'
        bypass_open:  ' W --- 32:126818 32:142858 --:------ 22F7 003 00C8EF'
        bypass_close: ' W --- 32:126818 32:142858 --:------ 22F7 003 0000EF'
        bypass_auto:  ' W --- 32:126818 32:142858 --:------ 22F7 003 00FFEF'
        reset_filter: ' W --- 32:126818 32:142858 --:------ 10D0 002 00FF'

Restarted Home Assistant and deleted the packets log, this is what i see (i rebooted the ventilation unit and sent an “high” and then “low” command with the real remote, highlighted in bold):

2023-04-08T10:36:32.369250 # ramses_rf 0.22.40
2023-04-08T10:36:34.737703 ...  I --- 32:142858 63:262142 --:------ 10E0 038 000001C88E0C0A6AFEFFFFFFFFFF1D0307E5564D442D30325250533636000000000000000000 # 10E0| I|32:142858
2023-04-08T10:36:34.777825 ...  I --- 32:142858 --:------ 32:142858 313F 009 007C02154D130107D0 # 313F| I|32:142858
2023-04-08T10:36:34.803114 ...  I 066 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008 # 31D9| I|32:142858|00 (00)
2023-04-08T10:36:34.895839 ...  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06017FFF073105D1F000004150500000EFEF7FFF7FFF00 # 31DA| I|32:142858
2023-04-08T10:36:50.544015 000 RQ --- 18:070400 32:142858 --:------ 22E5 001 00
2023-04-08T10:36:52.280862 086  I 067 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
2023-04-08T10:36:52.388006 081  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF061B7FFF072005F3F000004150500000EFEF7FFF7FFF00
2023-04-08T10:37:00.497278 000 RQ --- 18:070400 32:142858 --:------ 22E9 001 00
2023-04-08T10:37:10.457983 000 RQ --- 18:070400 32:142858 --:------ 22F2 001 00
2023-04-08T10:37:22.156213 000 RQ --- 18:070400 32:142858 --:------ 22F4 001 00
2023-04-08T10:37:32.105637 000 RQ --- 18:070400 32:142858 --:------ 22F8 001 00
2023-04-08T10:37:41.983656 000 RQ --- 18:070400 32:142858 --:------ 313E 001 00
2023-04-08T10:37:42.315484 079  I --- 32:142858 --:------ 32:142858 313F 009 007C03334D130107D0
2023-04-08T10:37:47.779090 083  I --- 32:142858 --:------ 32:142858 042F 009 000053445300549F70
2023-04-08T10:37:47.861020 000 RQ --- 18:070400 32:142858 --:------ 3222 001 00
2023-04-08T10:37:47.976550 082  I --- 32:142858 --:------ 32:142858 3120 007 0070B000000AFF
2023-04-08T10:37:48.598808 082  I --- 32:142858 --:------ 32:142858 3120 007 0070B000000AFF
2023-04-08T10:38:00.722131 000 RQ --- 18:070400 32:142858 --:------ 10D0 001 00
2023-04-08T10:38:07.631563 081  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF061A7FFF072305F2F000C84164000000EFEF7FFF7FFF00
2023-04-08T10:38:07.668531 000 RQ --- 18:070400 32:142858 --:------ 22F1 001 00
2023-04-08T10:38:17.592709 000 RQ --- 18:070400 32:142858 --:------ 2210 001 00
2023-04-08T10:38:37.433023 000 RQ --- 18:070400 32:142858 --:------ 22E5 001 00
2023-04-08T10:38:47.312014 000 RQ --- 18:070400 32:142858 --:------ 22E9 001 00
2023-04-08T10:38:47.639241 083  I --- 32:142858 --:------ 32:142858 313F 009 007C08344D130107D0
2023-04-08T10:38:57.199125 000 RQ --- 18:070400 32:142858 --:------ 22F2 001 00
2023-04-08T10:38:57.662073 083  I 002 32:142858 --:------ 32:142858 31D9 017 002A02FE20202020202020202020202008
2023-04-08T10:38:57.760462 083  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF061B7FFF071E05FAF000004150500000EFEF7FFF7FFF00
2023-04-08T10:39:07.131600 000 RQ --- 18:070400 32:142858 --:------ 22F4 001 00
2023-04-08T10:39:16.994346 000 RQ --- 18:070400 32:142858 --:------ 22F8 001 00
2023-04-08T10:39:26.930583 000 RQ --- 18:070400 32:142858 --:------ 313E 001 00
2023-04-08T10:39:36.826632 000 RQ --- 18:070400 32:142858 --:------ 3222 001 00
2023-04-08T10:39:49.760685 000 RQ --- 18:070400 32:142858 --:------ 10D0 001 00
**2023-04-08T10:39:57.141511 057  I --- 32:126818 32:142858 --:------ 22F1 003 000707**
2023-04-08T10:39:57.166316 080  I 003 32:142858 --:------ 32:142858 31D9 017 002A07FE20202020202020202020202008
2023-04-08T10:39:57.223239 000 RQ --- 18:070400 32:142858 --:------ 22F1 001 00
2023-04-08T10:39:57.268353 082  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06217FFF07270604F0000057C8C80000EFEF7FFF7FFF00
2023-04-08T10:39:57.714994 082  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06207FFF07250604F0000057C8C80000EFEF7FFF7FFF00
2023-04-08T10:40:07.099105 000 RQ --- 18:070400 32:142858 --:------ 2210 001 00
**2023-04-08T10:40:09.846678 052  I --- 32:126818 32:142858 --:------ 22F1 003 000207**
2023-04-08T10:40:09.875486 087  I 004 32:142858 --:------ 32:142858 31D9 017 002A02FE20202020202020202020202008
2023-04-08T10:40:09.981715 086  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06227FFF07260603F000004150500000EFEF7FFF7FFF00
2023-04-08T10:40:17.030494 000 RQ --- 18:070400 32:142858 --:------ 22E0 001 00
2023-04-08T10:40:17.731153 082  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06227FFF07260601F000004150500000EFEF7FFF7FFF00
2023-04-08T10:40:26.893241 000 RQ --- 18:070400 32:142858 --:------ 22E5 001 00
2023-04-08T10:40:36.797229 000 RQ --- 18:070400 32:142858 --:------ 22E9 001 00

While this is how i try to send the “high” command with the faked device:

service: remote.send_command
data:
  command: high
target:
  entity_id: remote.32_126818

This is ehat appears in the log (in bold) followed by nothing:

2023-04-08T10:47:02.179746 000 RQ --- 18:070400 32:142858 --:------ 3222 001 00
2023-04-08T10:47:15.044435 000 RQ --- 18:070400 32:142858 --:------ 10D0 001 00
2023-04-08T10:47:20.053479 000  I --- 18:070400 63:262142 --:------ 7FFF 023 00110187600C6CF332324631204933323A313236383138
2023-04-08T10:47:20.307674 000  I --- 18:070400 63:262142 --:------ 7FFF 023 00110187600C6CF332324631204933323A313236383138
**2023-04-08T10:47:20.487840 000  I --- 32:126818 32:142858 --:------ 22F1 003 000707**
2023-04-08T10:47:20.720966 000 RQ --- 18:070400 32:142858 --:------ 22F1 001 00
2023-04-08T10:47:30.460930 000 RQ --- 18:070400 32:142858 --:------ 2210 001 00
2023-04-08T10:47:40.364651 000 RQ --- 18:070400 32:142858 --:------ 22E0 001 00

zxdavb · April 8, 2023, 10:35am

No need to delete the log - you might want that data later.

Your physical remote switch does this (I merely have removed some packets from the log, and added comments at the end of lines):

2023-04-08T10:38:57.662073 083  I 002 32:142858 --:------ 32:142858 31D9 017 002A02FE20202020202020202020202008
   ...
2023-04-08T10:39:57.141511 057  I --- 32:126818 32:142858 --:------ 22F1 003 000707  # set fan mode 07
2023-04-08T10:39:57.166316 080  I 003 32:142858 --:------ 32:142858 31D9 017 002A07FE20202020202020202020202008
   ...
2023-04-08T10:40:09.846678 052  I --- 32:126818 32:142858 --:------ 22F1 003 000207  # set fan mode 02
2023-04-08T10:40:09.875486 087  I 004 32:142858 --:------ 32:142858 31D9 017 002A02FE20202020202020202020202008

Note: Each 22F1 results in an answering 31D9, and you can see the FAN going from mode 02 (the 31D9 payload starts 002A02...), to mode 07 (002A07...), back to mode 02 (002A02...)

Now, for the impersonation, it sends:

2023-04-08T10:47:20.487840 000  I --- 32:126818 32:142858 --:------ 22F1 003 000707  # impersonation

… but does not get a corresponding 31D9 packet from the FAN at all!.

If we compare the two 22F1 packets (physical above, impersonation below), we have:

2023-04-08T10:39:57.141511 057  I --- 32:126818 32:142858 --:------ 22F1 003 000707  # set fan mode 07
2023-04-08T10:47:20.487840 000  I --- 32:126818 32:142858 --:------ 22F1 003 000707  # impersonation

Comparing the two: there is nothing wrong with the impersonated packet at all: they’re identical.

Conclusion: The FAN cannot hear the USB dongle.

Next steps: Try tuning the dongle if you have that option. Try moving the dongle closer to the FAN.

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