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

trailro · March 29, 2023, 2:33pm

All devices are in a 90 sqm open space… so there is no clear barrier tbh. The usb device is placed in the same room so is the controller and TRV’s hence why this seems very weird.

erdek · March 30, 2023, 7:27am

Thanks to this post I finally got it working!
Replacing an existing Honeywell room sensor a few weeks ago was easy, but now I wanted to replace a TRV temperature sensor with a HA zigbee room sensor.
I wasn’t exactly sure how to use the ramses_cc.fake_device service call, and from my interpretation of the wiki (WIP) I assumed there was no need to create a device as long as it was in the known_list. This always resulted in successful service calls, but errors in the HA log.
(Btw: this was done on beta 0.22.40)

I have updated the wiki (3. How to: Faking Sensors, second note under step 3), please check for typos as I’m not a native English speaker

behold81 · April 1, 2023, 8:11am

What is the best device available in the Uk?

Last time I looked there was nothing easily available

zxdavb · April 2, 2023, 9:38am

This is an important question - the answer boils down to what is the ‘truth’ in an evohome system?

For example, if a TRV announces that it’s measured temperature is 20.51 'C, but the controller doesn’t receive that packet, is the ‘true’ temperature of the corresponding zone 20.51 'C or the previous received value (say 20.49 'C)?

The answer, I think, is largely what the evohome controller believes to be true. After all, it is the controller’s interface that you look at (the controller UI would display 20.0 instead of 20.5), or you see via the vendor’s app, and it is the controller that sends the corresponding call for heat to the boiler relay (or not).

So, even if ramses_rf did see the packet that the controller missed, it does not use that packet when it tracks the temperature of a zone (although it does for the corresponding HA sensor).

Instead, it simply asks the controller for the zone temperature (or eavesdrops similar packets from the controller), and uses that answer as the ‘truth’.

In this way, the HA zone, and the corresponding zone in the controller’s UI have the same value - assuming all is well (e.g. the controller heard the RQ from the USB dongle, and the dongle heard the responding RP).

Unfortunately, this strategy can not work for each zone’s heat demand because:

the controller never announces the zone’s heat demand
the controller will simply not respond to any valid RQ for this information

So, ramses_rf does what the controller does: it listens for the TRVs announcing their own heat demands, and uses that information to construct the zone’s heat demand (this is one reason why a schema is required).

It would not be uncommon for the controller to receive such packets and the dongle fail to do so - in such cases, you will see the behaviour you describe.

All you can do to mitigate this issue is to ensure the best possible reception between the various devices.

NB: This is the only instance in the CH/DHW domain that the controller’s ‘truth’ is obtained from a source other than the controller.

Take-away lesson:

remember the packet log is what the USB dongle sees, not what the controller sees.

zxdavb · April 2, 2023, 9:41am

This is not expected behaviour - as described above. Try ‘tuning’ the USB dongle if you have that option.

zxdavb · April 2, 2023, 10:34am

Thanks, I have tweaked it further: 3. How to: Faking Sensors (WIP)

I accept it isn’t a great wiki - further input is welcome.

zxdavb · April 2, 2023, 10:36am

These are the best available in Europe: 868MHz wireless dongles for RAMSES - strongly recommended.

Other may indicate the ebay link for the nanoCUL that are available from ?Germany.

sciorty · April 4, 2023, 2:04pm

I’m banging my head on the wall. This is my configuration:

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'

I can see the sensors of my ventilation unit and the fan speed that changes when i set it with the physical remote:

But the commands that i’m trying to send through the “virtual” remote do not work:

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

This is the log:

2023-04-04T15:42:03.723586 082  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF064D7FFF07210624F000004150500000EFEF7FFF7FFF00
2023-04-04T15:52:04.119159 080  I 104 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
2023-04-04T15:52:04.217644 080  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06517FFF07250627F000004150500000EFEF7FFF7FFF00
2023-04-04T15:52:54.145632 081  I --- 32:142858 --:------ 32:142858 313F 009 007C1106B30F0107D0
2023-04-04T16:02:04.536367 081  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06487FFF07210619F000004150500000EFEF7FFF7FFF00
----->Here i send the command via the service call
2023-04-04T16:02:08.005279 000  I --- 18:070400 63:262142 --:------ 7FFF 023 001101874C9332CF32324631204933323A313236383138
2023-04-04T16:02:08.259358 000  I --- 18:070400 63:262142 --:------ 7FFF 023 001101874C9332CF32324631204933323A313236383138
2023-04-04T16:02:08.464960 000  I --- 18:070400 63:262142 --:------ 7FFF 023 001101874C9332CF32324631204933323A313236383138
2023-04-04T16:02:08.653302 000  I --- 32:126818 32:142858 --:------ 22F1 003 000707
----->No reply, just the machine ( 32:142858 ) sending its status once in a while
2023-04-04T16:07:04.737521 080  I 105 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
2023-04-04T16:12:04.942896 080  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06487FFF071D061EF000004150500000EFEF7FFF7FFF00
2023-04-04T16:22:05.327348 081  I 106 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
2023-04-04T16:22:05.421553 082  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF064F7FFF071D0629F000004150500000EFEF7FFF7FFF00
2023-04-04T16:22:55.357344 080  I --- 32:142858 --:------ 32:142858 313F 009 007C1224B30F0107D0
2023-04-04T16:52:06.556055 080  I 108 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
2023-04-04T16:52:06.662469 082  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06587FFF07210634F000004150500000EFEF7FFF7FFF00
2023-04-04T16:52:56.581852 081  I --- 32:142858 --:------ 32:142858 313F 009 007C1306B40F0107D0
2023-04-04T17:07:07.145669 082  I 109 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
2023-04-04T17:12:07.352147 083  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06717FFF07210650F000004150500000EFEF7FFF7FFF00
2023-04-04T17:22:07.735259 080  I 110 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
2023-04-04T17:22:57.768294 080  I --- 32:142858 --:------ 32:142858 313F 009 007C1424B40F0107D0

PeterHaban · April 5, 2023, 11:20am

I bought one of them recently, works very well and they now also offer a matching 3D printed case for a couple of £.

tomkooij · April 6, 2023, 1:18pm

You need to “activate” the device first by called fake_device

This is for my remote 29:162275, change to your remote id

service: ramses_cc.fake_device
data:
  device_id: "29:162275"
  create_device: true
  start_binding: true

For some reason this does not always work without “start_binding: true”. I just don’t know.
But at least you can see it in packet.log now. Also check logs for failures.

This is probably a bug @zxdavb:
I have 29:162275 in my known_list and configured.
After a restart of HA, the remote.29_162275 entity becomes unavailable. Only after faking it again or sending a command with another dongle (faking it with another device) it become “active” and usable.

So check the entity remote.29_162275 it should no longer be unavailable
Once that exists, do:

service: remote.send_command
data:
  command: high
target:
  entity_id: remote.29_162275

And it will show up in your packet.log

sciorty · April 6, 2023, 1:38pm

Thanks for the suggestion. I just tried the fake_device service, it seems to worked since i see this message in the logs:

The device id already exists: 32:126818

Unfortunately, this did not seem to be the problem. In fact, i was already able to see the “faked” remote command on the logs, as i can now, but they do not seem to affect the machine (since it does not reply and does not change the speed):

2023-04-06T14:38:49.349995 081  I 035 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
2023-04-06T14:43:49.547633 080  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF05FD7FFF06CD05CDF000004150500000EFEF7FFF7FFF00
2023-04-06T14:53:49.893279 080  I 036 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
2023-04-06T14:53:49.991310 082  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF05FF7FFF06CB05D9F000004150500000EFEF7FFF7FFF00
2023-04-06T14:54:39.916586 080  I --- 32:142858 --:------ 32:142858 313F 009 007C010812110107D0
2023-04-06T15:03:50.297385 081  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06087FFF06CB05E8F000004150500000EFEF7FFF7FFF00
2023-04-06T15:08:50.469867 080  I 037 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
2023-04-06T15:13:50.675066 080  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF060D7FFF06CF05E9F000004150500000EFEF7FFF7FFF00
2023-04-06T15:23:51.030293 080  I 038 32:142858 --:------ 32:142858 31D9 017 002A020020202020202020202020202008
2023-04-06T15:23:51.132766 082  I --- 32:142858 --:------ 32:142858 31DA 030 00EF007FFFEFEF06027FFF06CF05D9F000004150500000EFEF7FFF7FFF00
2023-04-06T15:24:41.052924 080  I --- 32:142858 --:------ 32:142858 313F 009 007C032612110107D0
-----> Here i send the command via the service call
2023-04-06T15:27:12.209466 000  I --- 18:070400 63:262142 --:------ 7FFF 023 0011018756BFF01B32324631204933323A313236383138
2023-04-06T15:27:12.467264 000  I --- 18:070400 63:262142 --:------ 7FFF 023 0011018756BFF01B32324631204933323A313236383138
2023-04-06T15:27:12.667981 000  I --- 18:070400 63:262142 --:------ 7FFF 023 0011018756BFF01B32324631204933323A313236383138
2023-04-06T15:27:12.856872 000  I --- 32:126818 32:142858 --:------ 22F1 003 000707

tomkooij · April 6, 2023, 1:41pm

Ok, I missed the 22F1 command in your logs.

Did you bind the faked remote to the machine?

(Most device start in “binding mode” after a power cycle. Just restart the device and use the start_binding: true option.)

sciorty · April 6, 2023, 1:48pm

Oh so you mean that i should launch the fake_device service that you suggested just after a power cycle of the machine? If yes, shouldn’t i revert the fake_device that i already had or something? Anyway i’ll try that asap

tomkooij · April 6, 2023, 1:49pm

Yes that it. Usually your machine will flash status lights or something to show it’s in “binding” mode. (Read the manual, look for connecting a new remote)

When binding is succesful this is usually also shown on the machine with lot’s of flashing lights.

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.