Remote control not working correctly about ithowifi HOT 19 OPEN

I do not have the Auto N remotes. What I did try is copying the rft co2 address and send these commands (so my integration and remote have the same address). The remote doesn't seem to like that and cause communication errors. What I did experience while implementing the remote is that the the unit does check the Ramses II sequence counter.

I would be interested to try to get this working, perhaps I can help. Do you have a collection of RF logs, preferably evofw3 gateway logs?

Your module uses the green cc101 for which I have had a lot of reception issues. It seems that these modules come with an inaccurate crystal. For it to work I needed to put the remote within 1m range of the HRU unit itself. Perhaps it is a reception issue?

from ithowifi.

I’m not very technical in this kind of stuff. But if you want me to test something or to log anything please let me know.

from ithowifi.

> I know about the bad modules, thanks! I've tested a lot of them and finally settled on a supplier with good boards. 4x times as expensive but very reliable.

I recently bought the add-on including the RF module soldered on it.

The reception is very bad. The Itho is placed on the second floor and the remote only works on the first floor and never on the ground floor.

In that case, please feel free to return the add-on. I'll replace it with another module.

from ithowifi.

A short version (only showing messages to/from 37:*) of the join itself with another RFT-N Auto remote:

080  I --- 37:019136 --:------ 37:019136 042F 009 00FF1B141800115970
077  I --- 37:019136 --:------ 37:019136 3120 007 0070B00000E5FF
072  I --- 37:019136 --:------ 37:019136 10E0 038 000001001B391B01FEFFFFFFFFFF040B07E54356452D52460000000000000000000000000000
070  I --- 37:019136 --:------ 37:019136 31DA 030 0000407FFFEFEF7FFF7FFF7FFF7FFFF800EF1800000000EFEF7FFF7FFF00
072  I --- 37:019136 --:------ 37:019136 12C8 003 000040
067  I 001 37:019136 --:------ 37:019136 31D9 017 00063D0020202020202020202020202000
056  I --- 37:198626 --:------ 37:198626 1FC9 018 0022F89707E20110E09707E2001FC99707E2
067  W --- 37:019136 37:198626 --:------ 1FC9 012 0031D9944AC00031DA944AC0
056  I --- 37:198626 37:019136 --:------ 1FC9 001 00
057  I --- 37:198626 --:------ 37:198626 1060 003 00FF01
056  I --- 37:198626 --:------ 37:198626 1060 003 00FF01
056  I --- 37:198626 --:------ 37:198626 1060 003 00FF01
066  I --- 37:019136 --:------ 37:019136 10E0 038 000001001B391B01FEFFFFFFFFFF040B07E54356452D52460000000000000000000000000000
069  I 002 37:019136 --:------ 37:019136 31D9 017 0006750020202020202020202020202000
067  I 003 37:019136 --:------ 37:019136 31D9 017 0006C80020202020202020202020202000
067  I 004 37:019136 --:------ 37:019136 31D9 017 00067F0020202020202020202020202000
055  I --- 37:198626 37:019136 --:------ 22F1 003 000304
067  I --- 37:019136 37:198626 --:------ 31DA 030 0000407FFF36EF7FFF7FFF7FFF7FFFF800EF187F000000EFEF7FFF7FFF00
068  I 005 37:019136 --:------ 37:019136 31D9 017 00063D0020202020202020202020202000

from ithowifi.

056 I --- 37:198626 37:019136 --:------ 1FC9 001 00

This one is interesting! Did not appear in my logs... This could be the missing link to implementing the full handshake!
And it is a sign that the incomming message buffer is probably being overwritten when receiving multiple messages with short intervals

from ithowifi.

Bidirectional join is not supported yet. I'm trying to implement it, I can mimic the messages being send from the remote and itho but up until now the remote is not accepting my 'fake' itho cve response. I'll need to dive in deeper in the RF communication to see what the differences are.
Until then the Auto N RFT remote only works in legacy mode.

from ithowifi.

@arjenhiemstra I got remote pairing working for my custom Itho HA integration. The 'virtual' Itho RFT AUTO (536-0150) remote address is randomly generated and it can be successfully paired to the unit.

Take a look at:
https://github.com/GraceGRD/pyIthoRFT/blob/b59e91a62d5af69f1ef793f4593c7aab5a6b6721/IthoRFT/remote.py#L526
https://github.com/GraceGRD/pyIthoRFT/blob/b59e91a62d5af69f1ef793f4593c7aab5a6b6721/IthoRFT/remote.py#L197

Hope this helps

from ithowifi.

Thanks @GraceGRD
The issue here is not sending the join signal, that has been implemented for a while for almost all remote type of itho.
The issue is the latest generation itho remotes (Auto N) are bi-directional. (And also the rft rv and rft co2 are bidirectional)

So the remote sends the bind message (1fc9), expects a 10e0 device ident. message back and probably also a fan status message (31d9). I can send all those messages with the correct id, message header etc. (In the rf log I cannot distinguish the original from the faked bi-directional handshake) but still the remote is reporting a communication error.
Were you able to solve that?

from ithowifi.

I do not have the Auto N remotes. What I did try is copying the rft co2 address and send these commands (so my integration and remote have the same address). The remote doesn't seem to like that and cause communication errors. What I did experience while implementing the remote is that the the unit does check the Ramses II sequence counter.

I would be interested to try to get this working, perhaps I can help. Do you have a collection of RF logs, preferably evofw3 gateway logs?

15-10-2023 15:27:31: H:18 RQ P0:-- P1:-- 96,E6,07 --,--,-- 96,E6,07 1FC9 12:00,22,F8,96,E6,07,01,10,E0,96,E6,07,00,1F,C9,96,00,00 (cmd:join)

15-10-2023 15:27:31: H:2C RQ P0:-- P1:-- 96,A4,3B 96,E6,07 --,--,-- 1FC9 0C:00,31,D9,96,A4,3B,00,31,DA,96,A4,3B (cmd:unknown)

15-10-2023 15:27:31: H:18 RQ P0:-- P1:-- 96,E6,07 --,--,-- 96,E6,07 1060 03:00,FF,01 (cmd:unknown)
15-10-2023 15:27:31: H:18 RQ P0:-- P1:-- 96,E6,07 --,--,-- 96,E6,07 1060 03:00,FF,01 (cmd:unknown)
15-10-2023 15:27:31: H:18 RQ P0:-- P1:-- 96,E6,07 --,--,-- 96,E6,07 1060 03:00,FF,01 (cmd:unknown)

15-10-2023 15:27:32: H:18 RQ P0:-- P1:-- 96,A4,3B --,--,-- 96,A4,3B 10E0 26:00,00,01,00,1B,31,19,01,FE,FF,FF,FF,FF,FF,0E,05,07,E2,43,56,45,2D,52,46,00,00,00,00,00,00,00,00,00,00,00,00,00,00 (cmd:unknown)

Here is a full handshake. The logging is a bit different from evofw3 but in general is almost the same info and format
All numbers are in hex. H:xx = ramses header byte, P0: and P1 are the params (-- if not present). Rest is the same I believe.

So what we see is:
1- join from Auto N -> Itho
2- Join reply from itho -> Auto N
3- Battery status from Auto N -> broadcast
4- Device info from itho -> broadcast
after this there is also a 31d9 message but I do not have it from that handshake.
Here is one from an earlier log:
28-9-2023 23:52:38: _W 2 96,A4,3B --,--,-- 96,A4,3B 31D9 17:00,06,C8,00,20,20,20,20,20,20,20,20,20,20,20,00,00 (cmd:unknown)

Your module uses the green cc101 for which I have had a lot of reception issues. It seems that these modules come with an inaccurate crystal. For it to work I needed to put the remote within 1m range of the HRU unit itself. Perhaps it is a reception issue?

I know about the bad modules, thanks! I've tested a lot of them and finally settled on a supplier with good boards. 4x times as expensive but very reliable.

from ithowifi.

Here is a full handshake. The logging is a bit different from evofw3 but in general is almost the same info and format
All numbers are in hex. H:xx = ramses header byte, P0: and P1 are the params (-- if not present). Rest is the same I believe.

Thanks, Address command and payload are clear. I still don't fully understand what H:, P0: and P1: means. I would still prefer an evofw3 log as it also displays the sequence number. A log of the pairing procedure + pushing all the buttons after pairing on-by-one with 1 minute in between and leaving it for 15minutes running after pairing should contain all the required information to get this to work.

What is weird in the log is that 1FC9 address is set to 37:000000, would expect this to be 37:189959 as well. Also, I would expect the pairing command to be " I" instead of "RQ" based on older remotes. Message 10E0 should confirm that the remote is paired however it seems to send the reply to itself...
H:18 RQ P0:-- P1:-- 96E607 --,--,-- 96E607 1FC9 12 00 22F8 96E607 (37:189959) 01 10E0 96E607 (37:189959) 00 1FC9 960000 (37:000000) (cmd:join)

from ithowifi.

All info is already in my logging:
Below the (probably well know) structure of ramses II messages:
<HEADER> <addr0> <addr1> <addr2> <param0> <param1> <OPCODE> <LENGTH> <PAYLOAD> <CHECKSUM>

H: in my logging == <HEADER>

In itho communication the sequence number is represented in <param0>, this is P0 in my message log. Meaning, in this case there seems to be no sequence number.

I'll try to make some new traces. I've been working on the logging and at some point switched some codes which could well explain the I instaed of RQ.

from ithowifi.

> I know about the bad modules, thanks! I've tested a lot of them and finally settled on a supplier with good boards. 4x times as expensive but very reliable.

I recently bought the add-on including the RF module soldered on it.
The reception is very bad. The Itho is placed on the second floor and the remote only works on the first floor and never on the ground floor.

from ithowifi.

I also have RFT- N AUTO remotes directly connected to my CVE and also have an evofw3 gateway, so let me know if I can help.

@GraceGRD would you like to see traces when connecting remote directly to Itho, or to the add-on?

from ithowifi.

I also have RFT- N AUTO remotes directly connected to my CVE and also have an evofw3 gateway, so let me know if I can help.

@GraceGRD would you like to see traces when connecting remote directly to Itho, or to the add-on?

Yes it would be great to see some evofw3 logs for the remote paired to the Itho unit.

A log of the pairing procedure + pushing all the buttons after pairing on-by-one with 1 minute in between and leaving it for 15minutes running after pairing should contain all the required information/communication.

from ithowifi.

Here's an evo3fw log with the steps you've requested. I also have an Evohome system and I didn't want to risk removing any messages that you needed, so it's also showing all Evohome messages.

Let me know if you need anything else.
evo3fw-capture.txt

from ithowifi.

A short version (only showing messages to/from 37:*) of the join itself with another RFT-N Auto remote:

080  I --- 37:019136 --:------ 37:019136 042F 009 00FF1B141800115970
077  I --- 37:019136 --:------ 37:019136 3120 007 0070B00000E5FF
072  I --- 37:019136 --:------ 37:019136 10E0 038 000001001B391B01FEFFFFFFFFFF040B07E54356452D52460000000000000000000000000000
070  I --- 37:019136 --:------ 37:019136 31DA 030 0000407FFFEFEF7FFF7FFF7FFF7FFFF800EF1800000000EFEF7FFF7FFF00
072  I --- 37:019136 --:------ 37:019136 12C8 003 000040
067  I 001 37:019136 --:------ 37:019136 31D9 017 00063D0020202020202020202020202000
056  I --- 37:198626 --:------ 37:198626 1FC9 018 0022F89707E20110E09707E2001FC99707E2
067  W --- 37:019136 37:198626 --:------ 1FC9 012 0031D9944AC00031DA944AC0
056  I --- 37:198626 37:019136 --:------ 1FC9 001 00
057  I --- 37:198626 --:------ 37:198626 1060 003 00FF01
056  I --- 37:198626 --:------ 37:198626 1060 003 00FF01
056  I --- 37:198626 --:------ 37:198626 1060 003 00FF01
066  I --- 37:019136 --:------ 37:019136 10E0 038 000001001B391B01FEFFFFFFFFFF040B07E54356452D52460000000000000000000000000000
069  I 002 37:019136 --:------ 37:019136 31D9 017 0006750020202020202020202020202000
067  I 003 37:019136 --:------ 37:019136 31D9 017 0006C80020202020202020202020202000
067  I 004 37:019136 --:------ 37:019136 31D9 017 00067F0020202020202020202020202000
055  I --- 37:198626 37:019136 --:------ 22F1 003 000304
067  I --- 37:019136 37:198626 --:------ 31DA 030 0000407FFF36EF7FFF7FFF7FFF7FFFF800EF187F000000EFEF7FFF7FFF00
068  I 005 37:019136 --:------ 37:019136 31D9 017 00063D0020202020202020202020202000

This is great @FrankvdAa, thanks a lot!

from ithowifi.

This issue can be closed because of the following answer: Bidirectional join is not supported yet.
Also the issue with bad reception of the radio signal is issued.

from ithowifi.

Although not supported yet, I think this might be relevant when including this functionality, so maybe keep it open until implemented?

from ithowifi.

good point, lets keep it open

from ithowifi.