Need advice on best method to decode/transmit signal from generic remote.

[L Y]

I have a very simple 433Mhz remote controlling a retractable patio awning.

3 commands "UP" "DOWN" "STOP"

Generic Chinese remote. No brand, markings or FCC ID. 

I have  RTL_433 running on a RTL-SDR dongle + OpenMQTTGateway running on a hacked Sonoff RFBridge. 

Since the remote signals aren't decoded on existing protocols ( SRFB : nothing decoded/no raw signal captured., Pilight : nothing decoded/no raw signal captured, RTL_433 : nothing decoded), I already analyzed the 3 buttons (cu8,ook files attached) and confirmed the suggested flex decoder works for all 3 buttons:

however, I don't really care about receiving the signals, I want to transmit them so I can get rid of the remote and control the awning via Home Assistant.

I generally use my Sonoff RFBridge to transmit by using one of the standard methods:

https://docs.openmqttgateway.com/use/rf.html#rf-with-sonoff-rf-bridge

Is there a way to use the flex decoded data and convert it to something usable with the Sonoff bridge, either raw:

ex:

mosquitto_pub -t home/OpenMQTTGateway/commands/MQTTtoSRFB/Raw -m '{"raw":"267A013603B6140551"}'

or parameters:

ex:

mosquitto_pub -t home/OpenMQTTGateway/commands/MQTTtoSRFB/Tlow_315/Thigh_845/Tsyn_9123 -m '{"value":"33151562","delay":"9123","val_Thigh":"845","val_Tlow":"315"}'

Using the Sonoff bridge would be my preferred method as I wouldn't have to deploy a new device, but if I have no other choice I am open to other options.

OpenMQTTGateway now supports RTL_433 transmision with a CC1101 module but haven't tested it and not sure about transmitting flex decoded signals.

Also found this blog covering other options:

https://medium.com/@shreyasubale/reverse-engineering-a-wireless-doorbell-and-performing-a-replay-attack-part1-23d59d57ce82

Looking for advice on the best approach, 

thanks for this great project and support!

Cheers.

[Christian Z.]

We don't have a general RfRaw output, but -A on your sample files should show a RfRaw code if possible.

Otherwise use the data (60f0...) as value, sync as delay, long as val_Thigh, and short as val_Tlow. Just again record samples from that to see if maybe bits are flipped or such.

[ylaviolette]

Thanks for the feedback. Will do some testing and report back. 

On Tue, Oct 29, 2024, 5:01 a.m. Christian Z. <chri...@zuckschwerdt.org> wrote:

We don't have a general RfRaw output, but -A on your sample files should show a RfRaw code if possible.

Otherwise use the data (60f0...) as value, sync as delay, long as val_Thigh, and short as val_Tlow. Just again record samples from that to see if maybe bits are flipped or such.

--
You received this message because you are subscribed to the Google Groups "rtl_433" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtl_433+u...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/rtl_433/3992dced-c5e9-4e4b-bc72-b427dacd2cd6n%40googlegroups.com.

[Dave Edenfield]

Did you check for the FCC ID inside or printed on the board?

Get Outlook for Android

---

From: rtl...@googlegroups.com <rtl...@googlegroups.com> on behalf of L Y <ylavi...@gmail.com>
Sent: Monday, October 28, 2024 11:08:47 PM
To: rtl_433 <rtl...@googlegroups.com>
Subject: [rtl_433] Need advice on best method to decode/transmit signal from generic remote.

 

--
You received this message because you are subscribed to the Google Groups "rtl_433" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtl_433+u...@googlegroups.com.

To view this discussion, visit https://groups.google.com/d/msgid/rtl_433/9b46260d-f059-4feb-b77b-0e610c676492n%40googlegroups.com.

[ylaviolette]

Thanks for the suggestion. 

I could, but not sure how it would help as I already have the "receive" tools with the flex decoder. It is just three static codes and I need to figure out a way to "transmit" these codes. Ideally with the Sonoff RF bridge but I will be looking at alternatives if it doesn't work. I did some quick testing with the Sonoff bridge but for some reason the signals are not captured by the RTL-SDR dongle. I have a good antenna so I suspect my MQTT "send" command has incorrect syntax. I need to test further this weekend. The link I posted in my OP has some good ideas or I could use a BroadLink pro and just have it "learn" the codes. But again, my preference goes to something I can make sense of at the core/protocol level (vs "recording" and "replaying" some unreliable/noisy signal)

[L Y]

no FCC-ID

[Yann L]

Good afternon, winter is over and I'm back to solving this one.

Since I am using Pilight, OMG only offers 2 options to send RF commands:

1- Using a known protocol: Protocol is unknown for this remote.

2- Using a raw signal

Since I managed to decode the 3 signals with RTL-433 (above), I have access to the RTL-433 raw data:

```

Downloads\rtl_433-win-x64-23.11> .\rtl_433 -w OOK:- UP.cu8 rtl_433 version 23.11 branch at 202311281352 inputs file rtl_tcp RTL-SDR SoapySDR ;pulse data ;version 1 ;timescale 1us ;created 2024-11-01 09:07:22 [Input] Test mode active. Reading samples from file: UP.cu8 ;received 2024-11-01 09:07:22 ;ook 285 pulses ;freq1 433850688 ;centerfreq 433920000 Hz ;samplerate 250000 Hz ;sampledepth 8 bits ;range 42.1 dB ;rssi -0.1 dB ;snr 33.6 dB ;noise -33.7 dB 4876 548 584 176 204 556 208 552 584 176 584 176 580 180 584 172 584 180 208 548 212 552 208 556 204 552 580 184 576 180 580 172 588 180 208 552 204 556 204 552 588 180 200 556 204 552 588 172 584 180 208 552 204 560 576 184 580 176 584 176 204 556 580 176 208 556 208 552 208 556 200 556 204 556 204 556 204 556 580 176 208 560 204 556 576 180 208 556 576 180 584 176 580 176 588 172 208 560 204 552 204 560 200 556 580 180 208 552 204 552 208 552 208 560 4852 552 580 180 204 560 200 560 576 180 580 180 580 176 584 176 584 180 204 560 200 556 204 556 204 556 580 176 584 176 584 180 580 180 208 556 200 556 204 556 580 180 204 556 204 552 584 180 580 180 204 560 200 556 580 180 580 176 584 176 208 552 584 180 204 556 204 564 196 556 204 556 204 552 208 552 208 556 576 180 208 564 196 560 576 184 200 560 576 176 584 176 584 180 580 180 200 560 204 556 204 556 204 552 584 180 204 552 204 560 204 560 200 560 4852 552 580 180 204 556 204 556 580 180 576 180 580 184 576 184 580 180 204 556 204 552 208 552 208 560 576 180 576 184 580 176 580 180 208 556 204 556 204 552 584 180 200 560 200 560 576 180 580 184 204 556 204 556 580 180 580 176 584 180 204 552 584 176 208 556 204 556 204 556 204 552 208 556 204 560 200 552 580 180 204 560 204 556 580 180 200 556 580 184 580 180 576 184 576 180 204 560 204 556 204 556 204 552 580 184 200 560 204 552 204 564 196 556 4856 556 580 176 204 560 200 556 580 180 580 180 580 180 580 180 580 184 204 556 200 560 200 560 200 560 576 180 580 184 576 176 584 184 200 560 204 556 204 556 576 184 200 556 204 556 580 184 572 184 208 556 204 556 580 176 580 188 576 176 204 556 580 184 200 560 200 556 208 556 200 560 204 556 200 556 204 564 572 180 204 560 204 560 572 188 196 556 580 184 576 184 580 176 580 176 208 560 200 560 200 560 200 564 572 184 204 556 200 560 200 556 204 556 4860 552 576 184 200 560 200 560 576 176 584 180 580 176 584 180 580 180 204 556 204 560 200 560 200 560 576 180 580 184 576 180 580 184 204 556 200 560 200 556 580 180 204 556 204 556 580 180 580 184 200 560 204 560 572 180 580 184 580 176 204 552 584 180 204 560 200 564 196 560 200 560 200 556 204 556 204 556 580 180 204 560 204 560 576 180 200 560 580 176 580 184 576 180 580 180 204 556 208 560 196 560 200 564 576 184 196 556 204 564 196 556 204 48764 ;end

```

Could you provide assistance on how to go from the above to the Pilight pulse train string format?   ( Using a raw signal )

IE:

You can transmit raw signal data by using the "raw" protocol. This uses the Pilight pulse train string format. One such example string, representing a transmission for Nexus protocol weather stations, looks like this: c:03020202010102020102010101010101010202020201020102020202020101010201010202;p:500,1000,2000,4000;r:12@. This string represents pulses and gaps directly.

Each number in the list after p: that ends with ; stands for pulse and gap lengths in microseconds (µs). In this example, we have a list containing lengths of 500µs, 1000µs, 2000µs, and 4000µs.

Each number after c: and ended by ; represents a code that references the p: list by index. In this example, the first 4 numbers after c: are 0, 3, 0, and 2, which reference p:[0] = 500, p:[3] = 4000, p:[0] = 500, and p:[2] = 2000, respectively. In the language of digital radio transceiving, the most basic unit is usually a pulse and gap pair; in other words, 0s and 1s are represented by a pulse followed by a gap (lack of pulse) and the time lengths of these pulses and gaps. Different protocols have different pulse lengths and gap lengths representing 0, and a different one representing 1. Because of this pulse-gap nature, the codes in c: must be taken as pairs; the first number in a pair represents the length of the pulse, and the second number the subsequent gap. In this example, the first pair, 03, represents a pulse of 500µs followed by a gap of 4000µs. The next pair, 02, represents a pulse of 500µs followed by a gap of 2000µs.

The number after r: represents how many times the message in the string is to be repeated. The r: block is optional. The default number of repeats if r: is not specified is 10. Greater than about 100 repeats will cause a crash due to memory usage. If this example were written without specifying repeats, it would look like this: {"raw":"c:03020202010102020102010101010101010202020201020102020202020101010201010202;p:500,1000,2000,4000@"}

The entire string must end in a @. Each block must end in a ;, but if it is the last block in the string, the @ replaces the ;. Since the r: block is optional, this last block could be either p: or r:.

The JSON for the MQTT message to home/OpenMQTTGateway/commands/MQTTtoPilight should specify the pulse train string as the value for the "raw" key: {"raw":"c:03020202010102020102010101010101010202020201020102020202020101010201010202;p:500,1000,2000,4000;r:12@"}.

e.g. mosquitto_pub -t "home/OpenMQTTGateway/commands/MQTTtoPilight" -m '{"raw":"c:03020202010102020102010101010101010202020201020102020202020101010201010202;p:500,1000,2000,4000;r:12@"}'

Unfortunately I couldn't get support from the OMG forum: link

With your guidance, I should hopefully be able to test and decode all 3 signals.

Thank you!

[Yann L]

Just for future reference and to close the loop on this one:

Ended up purchasing the Broadlink RM4 Pro and learned the RF commands from the remote.

The Broadlink can then send back the RF commands via Home Assistant

Now I have the Broadlink Base64 codes 

      "UP": "ssBAAhigBgCbERMGBxEHEhIHEQcRBxIHEgYGEgYTBRMGEhIGEwYSBhIGBxIGEgcREgcGEwUTEQcRCAUTBhISBhMGEgYGEhIHBRMGEgcRBxEIEQcSBhISBwYSBhITBgUTEgYTBhIGEgYGEgYTBhIHERMFBxIHEgYSBhOaExIGBRMHERIHEgYSBxEIEAgFEwYSBhMFExIGEgYTBhIGBhIGEwUTEgYHEQcSEgYSBwYTBRMRBxIGEwYFExIGBhMFEwYSBhIGEwcRBxETBgYSBxIRBwYTEQcSBhMGEgYGEgYSBhMGEhIGBhMGEgcRBxGbExIHBRMFExIGEgcSBhIGEgcGEgYTBhIGExEHEQcSBhMGBhIGEgYTEgYGEgYTEgYSBgcRBxISBhIHEQgFExEHBhIGEwUTBRMGEwUTBRMSBgYTBhISBgcSEgYSBxEHEQgFEwYSBhMFExIGBhIGEwUTBhKbExIGBhMFExIGEgYSBxIGEgYGEwYSBxEHERMGEgcRBxEIBRMGEgYSEgcFEwYSEwYSBgYSBhMSBhIGEgYHEhIHBhIGEgYTBhIGEgYTBRMSBgYTBRMSBgYSEgcSBhIGEgYHEwYSBhMFExEHBRMGEgYTBRObExEHBhIGExEHEgYSBhIHEgYGEgYTBRMGEhIGEgcSBhIGBxIGEwUTEQcGEwYSEgYSBwUTBhISBhMGEgYGEhIGBxIHEQcRBxMGEgYSBhMRBwUTBhITBgUTEgYSBxIGEgYGEgcSBhIHERMHBRMFEwYSBgAF3A==",
      "STOP": "scBAAmadBgCbExIGBhIGExIGEgYSBxIGEgcGEwUTBRMGEhMGEgYSBhIHBRMFEwYTEgYGEgcREwcRBwYSBhMRBxIGEgYGExIGBhIGEwUTBhIHERMGBhIHEgYTBhIRBxMFBhMGEhIGBhMFEwYSBhIIERIGBxEHEwYSBhKaExIHBhIGEhIGEggRBxEHEQgFEwUTBhIGExIGEgYSBxIGBxEHEQcSEgYHEgYSEgcSBgYSBhMSBhIGEwYFExIGBhMGEgcRBxEHExEHBhIGEgcSBhITBRMGBhIGEhMGBhIHEQcRCBEHEhIGBhMGEgYSBhObEhIGBhMGEhIHEQcSBhIGEgcFEwYSBhMFExIHEgUTBhIGBxIGEwYSEQcGEwUTEgYSBwUTBhITBRMGEgYHERMFBxIHEgYSBhMGEhIGBhIGEwYSBhITBhIGBhIHEhIGBxEHEgYTBhIGEhIHBhIGEgYTBRObExEHBhIGEhMGEgYSBhMGEgYGEgYTBhIHERMFEwYSBxEHBhMGEgYSEwUGEwYSEwUTBgYSBhITBhIGEgYHEhIHBhIGEgYTBhIGEhMGBRMGEgYTBRMSBhIHBhIHERIHBhIGEwYSBhIGExIGBhIGEwUTBhKbExIGBhMFExIGEgcSBhIGEgcGEgYSBxIGEhIHEQcRCBIGBRMGEwUTEgYGEgYSEwYSBgcRBxISBxEHEQgFExIGBhMFEwYSBhIGExIGBhIGEwYSBxESBhMHBhIGEhIHBhIGEgYSBhMGEhMFBhMGEgcRBwAF3A==",
      "DOWN": "scBAApKeBgCcEhIHBhIGEhIGEwYSBhIGEwYGEgYSBxIGEhIGEgYTBxEHBhIGEwUTEgYGEwUTEgYSBwUTBRMSBhMGEgYHERIHBhIHEgYSBhMFEwYSEwUGEwYSBhITBhIGBhIGEwYSBxEHEQcSBxIGEhIHBhIGEgYSBxKbEhIHBhMFExEHEQgRBxIGEgYGEwUTBRMGEhIHEgYSBhIHBhIGEwYTEQcFEwYSEgcSBgYSBhMSBhIGEgYGExIGBxEHEgYSBxIGEgYTEQcGEgYTBRMSBhIHBRMFEwYSBhMFEwcRBxIGEhIHBhMFEwUTBhKaExIHBhIGEhIHEQgRBxEHEQgFEwUTBhIGExIGEgYSBxIGBhIHEQcSEgYHEgYTEQcRBwYTBRMSBhIGEwYFExIGBhMFEwYSBhMGEgcREgYHEwUTBhISBxEHBRMGEwUTBRMGEgYTBRMGEhIHBhIGEgcRBxOaExIGBRMGEhIHEgYSBhIHEQgFEwYTBRMFExIGEgcSBhIGBhMFEwUTEgYGEwYSEgYSBwYTBRMRCBEHEQcGEhIHBRMFEwYTBRMFEwYTEgYGEgcRBxISBxEHBhMFEwUTBhIGEwUTBhIGExIGBhIGEwYSBhKbExIGBhMFExIGEgYSBxIGEgYHEgYSBhMGEhEIEQcSBhIHBRMFEwYSEwYFEwYSEgcSBgcRBxISBhIHEQcGExEHBhIGEwUTBRMGEwUTEgYGEgYTBRMSBhIHBhIGEwYSBhMFEwYSBhMFExIGBhMFEwUTBgAF3A=="

Out of curiosity I've tried to convert the Broadlink Base64 codes to Pilight pulse train (Thanks ChatGPT) just to see if I could finally get the Sonoff bridge to work...

mosquitto_pub -t "home/OpenMQTTGateway/commands/MQTTtoPilight" -m '{"raw":"c:201011000001111000011101100110001011111110110100001111011111011000001111000011101100110001011111110110100001111011111011000001111000011101100110001011111110110100001111011111011000001111000011101100110001011111110110100001111011111011000001111000011101100110001011111110110100001111011103;p:393,1134,9877,13574;r:5@"}'

https://chatgpt.com/share/68391ae1-e438-800f-be55-fe62145eda18

But this fails as well.

Anyways, the Broadlink RM4-Pro works well, case closed for me, but if anyone has other hints or ideas for the Sonoff RF Bridge, feel free to reach out.

Cheers.

[Christian Z.]

Your ChatGPT advice is going in the right direction but wrong at multiple points.

E.g. Pulse units are 32,84 µs not 0.241 µs -- that would be excessive resolution, right?

And e.g. pulse values are one byte usually. If the length would exceed one byte only then it is stored as two bytes, and with a leading 0.

In the end your pilight codes are wrong and fail.

[Christian Z.]

The pulse viewer https://triq.org/pdv3/ has a Broadlink RM code decoder ("+" Button, Broadlink RM data)

[Yann L]

Thank you for the pointer (result below), but unfortunately I still haven't figured out a reliable way to get from the raw RF data to OMG Pilight pulse train.