P118 (Itho) only supports their newer standard (RFT)

[ShadowJonathan]

P118 (currently in testing-D) communicates with Itho ventilation components, using a c1101 radio module powered through the GPIO pins.

However, this plugin only supports Itho's newer (RTF) communication method, for two Itho fans (545-5020: "CVE ECO-FAN 2E", and 545-5030: "CVE ECO-FAN 2P") there exists an extension module (536-0110) that runs on an older protocol.

Marketing for this is all over the place, but i'll call the older protocol RF, and the newer one RFT.

P118 only supports the newer standard, which all of the remotes have been tuned to since.

However, I'm making this issue to note that it does not support communication for the above fans and extension cards, and if possible, i'd wanna try to create code that would work with it.

At the very least though, I suggest changing documentation to highlight this.

Misc

Hardware: ESP8266 NodeMCU v2, with c1101 radio module

ESP Easy version: mega-20220616

cc @svollebregt, @jodur

[tonhuisman]

Please also take into account the work (refactoring, actually) I've started in PR #3889 ~4099~

I'm not sure if the Itho library used supports that RF protocol (didn't look into that yet).

Edit: Linked the wrong PR, corrected.

[ShadowJonathan]

It doesnt, RFT is a complete breakage from RF, im currently verifying the baud rate andsoforth as described here and here, to get some template of commands going.

[svollebregt]

As far as I know, it is not possible (or at least not straightforward) to support both protocols as they are quite different in how the physical communication is arranged (different RF schemes and settings in the CC1101). I know it has been tried before and if you can read Dutch you can find some information here: https://gathering.tweakers.net/forum/list_messages/1690945/0

[ShadowJonathan]

Following that topic, they're discussing its existence, but i havent seen any reverse engineering efforts at all.

[ShadowJonathan]

After some digging (and using the cc1101 rpi driver), I've figured out at least some basic parameters of the older RF protocol;

Carrier/base freq: 868.360 Deviation: 17.45khz Baud rate: 8.192 kBd Mod: FSK-2 Sync word: AAAB

Then the following payloads for the different commands:

One: 555555533354d5355554acad Two: 555555533354d5355552cd35 Three: 555555533354d535554ccab5

The remote has no preamble (other than the sync word), which makes it somewhat hit-or-miss to receive. Luckily, it sends three of the same commands with some spacing in between.

---

If you want to figure this out using the above driver, plus cc1101-python, then these are the following commands that worked for me;

Commands

``` python3 -m cc1101 tx /dev/cc1101.0.0 FSK_2 868.36 8.192 0.6 555555533354d5355554acad00000000 --sync_word AAAB --deviation 17.456055 python3 -m cc1101 tx /dev/cc1101.0.0 FSK_2 868.36 8.192 0.6 555555533354d5355552cd3500000000 --sync_word AAAB --deviation 17.456055 python3 -m cc1101 tx /dev/cc1101.0.0 FSK_2 868.36 8.192 0.6 555555533354d535554ccab500000000 --sync_word AAAB --deviation 17.456055 ```

Here's the cmd to receive commands from other remotes:

python3 -m cc1101 rx /dev/cc1101.0.0 FSK_2 868.36 8.192 AB 12 --out-format info --bandwidth 58 --deviation 17.456055 --max-lna-gain 6 --max-dvga-gain 6

Some note: For some reason, with my cc1101 driver (or my module) tuning directly to the channel doesn't seem to work, and only tuning a whole 100khz away seems to properly clear it (DC signal interference?)

[ShadowJonathan]

(Unfortunately, I don't have the means to pursue this anymore, so if anyone else is willing to pick this up, be my guest :3)