Remote control not working correctly
Opened this issue · 20 comments
Describe the bug
Just installed the new add-on module including the CC1101 module.
I already had the RFT-N AUTO (part 04-00161) remote control unit which was working fine directly with the Itho box.
After successfully added the add-on in the Itho box I connected the remote.
The remote is connected but at each action the led is blinking red corresponding with the error "Error Communication". But the box is working. And also in de RF debug windows I can see the commands received. So it looks like there is no correct communication back to the remote that will result in a green led blink.
The second thing is that the RF reception is very bad. The remote need to be close to the box before it is receiving the signal.
How can this be solved?
To Reproduce
n/a
Expected behaviour
The RFT-N AUTO remote is not working correct. So it is not possible to use it.
Screenshots
Device information
17497 I: I2C init: Safe guard enabled
17337 I: I2C init: QueryStatus
16927 I: I2C init: QueryStatusFormat - items:12
16678 I: I2C init: QueryDevicetype - fw:27 hw:27
16436 I: Hostname: nrg-itho-dbe8
16190 I: mDNS: started
15983 I: Webserver: started
15800 I: Setup: init of CC1101 RF module successful
13788 I: WiFi: connection successful
13630 I: Timezone: Europe/Amsterdam, specifier CET-1CEST,M3.5.0,M10.5.0/3
6741 E: Unable to set wifi disconnect
4292 I: I2C sniffer capable hardware: yes
3779 I: HW rev: 2, FW ver.: 2.6.0
Debug logging
Please provide debug logging from the debug page if possible:
RF debug Level 3:
5-11-2023 15:27:43: H:1C _I P0:-- P1:-- 95,E1,73 94,7A,4C --,--,-- 22F3 03:00,03,04 (cmd:unknown)
5-11-2023 15:27:43: H:1C _I P0:-- P1:-- 95,E1,73 94,7A,44 --,--,-- 22F1 03:00,03,04 (cmd:medium)
5-11-2023 15:27:43: H:1C _I P0:-- P1:-- 95,E1,73 94,7A,4C --,--,-- 22F1 03:00,03,04 (cmd:medium)
5-11-2023 15:27:33: H:1A _I P0:1E P1:-- 94,7A,4C --,--,-- 94,7A,4C 31D9 11:00,06,3F,00,20,20,20,20,22,20,20,20,20,20,20,20,00 (cmd:unknown)
5-11-2023 15:27:33: H:1C _I P0:-- P1:-- 95,E1,73 94,7A,4C --,--,-- 22F3 03:00,00,0A (cmd:timer1)
5-11-2023 15:27:33: H:1C _I P0:-- P1:-- 95,E1,73 94,7A,4C --,--,-- 22F3 03:00,00,0A (cmd:timer1)
5-11-2023 15:27:33: H:1C _I P0:-- P1:-- 95,E1,73 9C,7A,4E --,--,-- 22F3 03:00,00,0A (cmd:timer1)
5-11-2023 15:27:24: H:1C _I P0:-- P1:-- 95,E1,73 94,7A,4C --,--,-- 22F1 03:00,02,04 (cmd:low)
5-11-2023 15:27:23: H:1C _I P0:-- P1:-- 95,E1,73 94,7A,4C --,--,-- 22F1 03:00,02,04 (cmd:low)
5-11-2023 15:27:23: H:1C _I P0:-- P1:-- 95,E1,73 94,7A,4C --,--,-- 22F1 03:00,02,04 (cmd:low)
5-11-2023 15:27:23: H:1A _I P0:1D P1:-- 94,7A,44 --,--,-- 94,7A,4C 31D9 11:00,06,AA,00,20,20,20,20,20,20,20,20,20,20,20,20,00 (cmd:unknown)
5-11-2023 15:27:13: H:1C _I P0:-- P1:-- 95,E1,73 94,7A,4C --,--,-- 22F1 03:00,04,04 (cmd:high)
5-11-2023 15:27:13: H:1C _I P0:-- P1:-- 95,E1,73 94,7A,4C --,--,-- 22F1 03:00,04,04 (cmd:high)
5-11-2023 15:27:13: H:1C _I P0:-- P1:-- 95,E1,73 94,7A,4C --,--,-- 22F1 03:00,04,04 (cmd:high)
5-11-2023 15:26:58: H:1E _I P0:22 P1:-- 95,E1,73 94,3A,4C --,--,-- F203 00: (cmd:unknown)
Desktop (please complete the following information):
n/a
Smartphone (please complete the following information):
n/a
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.
@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
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?
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?
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.
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.
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)
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.
> 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.
> 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.
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?
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.
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
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
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
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!
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.
Although not supported yet, I think this might be relevant when including this functionality, so maybe keep it open until implemented?
good point, lets keep it open
Small update. I'm getting somewhere.
I'm now able to successfully join an itho auto-n remote bidirectional. Had to do with ID's not being copied in the correct places.
Now working on bidirectional support for the CO2 en RV remotes and ability to send fan status to these remotes.