New device - iVac Pro remote control

[gcormier]

Pretty basic device using OOK.

FCC : YCH-IVACPRO 433MHz https://www.ivacswitch.com/wp-content/uploads/2024/06/iVAC-Remote-User-Guide-ENG-FR-SP-14789-004-warning.pdf

First 2 dip switches are "System Address" Next 3 dip switches are a "Tool Address"

https://github.com/gcormier/rtl_433_tests/tree/ivacpro

Are these enough captures to figure out what's going on?

[ProfBoc75]

Hi @gcormier

First, missing the file g001 and g003, were in your readme file but not uploaded, could help to confirm my assumption regarding system address.

My findings:

• Modulation OOK_PWM, s=420, l=856, r=2000
• Repeated message of 13 bits.

Data Layout:

Bit position 1234 5678 1234 5678
             IIII IISS CTTT P000

• I:{6} Possible ID
• S:{2} Possible System Address, reverse and invert (S2 S1), to be confirmed with more samples, this is my assumption from Tool Address approach.
• C:{1} Command, invert, 0 = On, 1 = OFF
• T:{3} Tool Address, reverse and invert (S5 S4 S3)
• P:{1} Parity of previous bits
• 0:{3} Always zeros as message is 13 bits

From this you can create a configuration file to decode the signal, but parity (like CRC/CHECKSUM) is not handle by conf/flex decoder.

Try this:

rtl_433 -X 'n=iVacPro,m=OOK_PWM,s=420,l=856,r=2000,bits=13,unique,get=id:@0:{6}:%d,get=CMD:@8:{1}:[0:ON 1:OFF],get=SYSTEM_ADDRESS:@6:{2}:[0:D_11 1:B_10 2:C_01 3:A_00],get=TOOL_ADDRESS:@9:{3}:[0:7_111 1:6_011 2:5_101 3:4_001 4:3_110 5:2_010 6:1_100 7:8_000],get=Parity:@12:{1}:%d'

In result you have the system address letter follow by the dip position S1 S2, the tool address number follow by the dip position S3 S4 S5, the CMD ON/OFF, the sensor ID.

[gcormier]

Awesome, thanks! I've added the 2 missing files (oops!) - I'm heading out for the day but I'll give it a shot later!

I've also got the hex firmware extracted, so I can run it in Ghidra and see if it's possible to figure out the checksum formula.

[ProfBoc75]

Hi @gcormier

Thanks to your 2 missing files, which confirmed my assumption, I can share a little update:

rtl_433 -X 'n=iVacPro,m=OOK_PWM,s=420,l=856,r=2000,bits=13,unique,get=id:@0:{6}:%d,get=CMD:@8:{1}:[0:ON 1:OFF],get=SYSTEM_ADDRESS:@6:{2}:[0:D_11 1:C_01 2:B_10 3:A_00],get=TOOL_ADDRESS:@9:{3}:[0:7_111 1:6_011 2:5_101 3:4_001 4:3_110 5:2_010 6:1_100 7:8_000],get=Parity:@12:{1}:%d'

If you want to replay your cu8 file, just add name at the end of the above command.

Notice that the checksum formula is one bit parity ( 0 or 1) of the 12 first bits. I show the bit parity value from the above command, the third bit of the message, but it's not verified. A decoder is needed for that.

Edit: I also notice that the message is repeated 24 times, for a total duration of 3.052 seconds and because the gap between messages is too high, 127 ms, rtl_433 can't remove duplicated values with the flex option unique.

[gcormier]

Thanks so much! Since it can be decoded with a flex decoder, is there something I can do to contribute to rtl_433 to recognize this device? Or does it just remain as a known device using a flex decoder?

[ProfBoc75]

@gcormier

Thanks so much! Since it can be decoded with a flex decoder, is there something I can do to contribute to rtl_433 to recognize this device? Or does it just remain as a known device using a flex decoder?

You or me can create a conf file based on the flex decoder and pull a request to add it to rtl_433.

If you don't know how to proceed, you have samples in conf folder, and it's mostly based on the flex options.