-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Raw Messages - RTL_433_ESP discussion #1
Comments
Hey cgmckeever,
Apologies, I wrote out a response but never sent it... see below. It's possible I didn't understand exactly what you setup is, but hopefully this info will help anyway.
Appreciate the detailed background. I'm just learning along the way here, too. Didn't realize you could compare repos like that in github, for example - very cool.
Regarding your questions,
1. The intent of the Bridge device (an ESP device, not a Raspberry Pi) is to receive sensor messages and transmit them onto the Helium LoRaWAN network. Once there, a LoRaWAN Network Server (I'm using the meteoscientific.com ChirpStack LNS) decodes the message and makes it available via various integrations (http, mqtt) to consumers like home assistant.
The decoder.js function decode(hexString)is not run on the Bridge, but later on the LNS so that that can provide the plain text decoded data to the user.
The Bridge just keeps the data in hex format. It receives the sensor messages using RTL_433_ESP, and then retransmits them using LoRaWAN using LMIC_node. The hex format keeps the LoRaWAN packet sizes small.
It makes sense to use RadioLib to retransmit the data (instead of LMIC like I do), but I'm not familiar enough with RadioLib to help with that aspect. (LMIC is exclusively LoRaWAN, which is not what you want.)
2. For you to use rtl_433 (on Raspberry Pi), the button message you want to retransmit would have to be from one of the devices it supports
Is your device on that list? If it is, you should be able to get a read-out similar to what you get with RC-Switch. (to make things easier, you could test with rtl_433, which you can install on a raspberry pi or any linux machine)
Once you confirm that rlt_433 and RTL_433_ESP can read the message, you could modify that sensor's decoder function in [rtl_433_ESP/src/rtl_433/devices at main · NorthernMan54/rtl_433_ESP (github.com)](https://github.com/NorthernMan54/rtl_433_ESP/tree/main/src/rtl_433/devices).
However, it sounds like you are trying to retransmit an RC remote control signal, and I don't think rlt_433 will decode those. Also rtl_433 and RTL_433_ESP code only receives, it doesn't retransmit.
It sounds like you are on Raspberry Pi, so I think what makes most sense it to receive and decode using RC-Switch like you are now, convert the binary "100000101100100011001000" data to hex, and then figure out how to retransmit using RadioLib.
Let me know if this helps at all.
Cheers,
Dirk
…On Sunday, June 2nd, 2024 at 1:53 PM, cgmckeever ***@***.***> wrote:
***@***.***(https://github.com/dirkbeer), thanks for the updates [through the other issue](NorthernMan54/rtl_433_ESP#104 (comment)) .. Taking you up on your offer - moving it here to reduce noise ;)
Background
Let me preface, all this is brute force and learning along the way.
I was originally using [RC-Switch](https://github.com/sui77/rc-switch) to get decoded button messages. The decoded messages look like
Decimal: 8571080 (24Bit)
Binary: 100000101100100011001000
Tri-State: not applicable
PulseLength: 321 microseconds
Protocol: 1
I could then rf-transmit those back out via RC-Switch to relay/replay/etc
At the same time, I was using RTL_433_ESP to capture IOT device messages and relay them via a HTTP request to my home automation setup.
[Working code](https://github.com/cgmckeever/arduino-sketch/tree/master/esp-rf/cc1101/relay/v1)
Problem
With the previous change to RTL_433_ESP moving the RF driver from [SmartRC](https://github.com/LSatan/SmartRC-CC1101-Driver-Lib) to RadioLib there is a conflict with how all these pieces work.
Hope
- I would like to figure out if its possible to use RTL_433_esp to decode the same way RC-switch does, flagging RTL_ANALYZER at build gives me some results, but I cant see any correlation between the two reports. [Detail conversation of the two decodes](sui77/rc-switch#512)
- Would like to use RTL_433_ESP (via RadioLib) to do the rf-transmit
I know Im talking out my ass here.
Questions
- In your [RTL_433_ESP fork](NorthernMan54/rtl_433_ESP@main...dirkbeer:rtl_433_ESP:master), you do a bytes_to_hex_string but then it looks like you decode it function decode(hexString) back to a data format similar to what RTL provides -- wondering what is going on here? Im probably missing the obvious
const data = {
model: 'Fineoffset-WH45',
id: id.toString(16),
battery_ok: batteryOk.toFixed(1),
temperature_C: tempC.toFixed(1),
humidity: humidity,
pm2_5_ug_m3: pm25.toFixed(1),
pm10_ug_m3: pm10.toFixed(1),
co2_ppm: co2,
ext_power: extPower,
mic: 'CRC',
- Any thoughts on using the hexstring to accomplish what Im trying to do? Literally dont know what/how to use it.
Really appreciate any ideas you might have
—
Reply to this email directly, [view it on GitHub](#1), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ABRAV5HRRRZQ6RL6ADZFJPTZFOA3VAVCNFSM6AAAAABIVLOGRSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGMZDSOBVHE2TCNA).
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@dirkbeer, thanks for the updates through the other issue .. Taking you up on your offer - moving it here to reduce noise ;)
Background
Let me preface, all this is brute force and learning along the way.
I was originally using RC-Switch to get decoded button messages. The decoded messages look like
I could then rf-transmit those back out via RC-Switch to relay/replay/etc
At the same time, I was using RTL_433_ESP to capture IOT device messages and relay them via a HTTP request to my home automation setup.
Working code
Problem
With the previous change to RTL_433_ESP moving the RF driver from SmartRC to RadioLib there is a conflict with how all these pieces work.
Hope
RTL_ANALYZER
at build gives me some results, but I cant see any correlation between the two reports. Detail conversation of the two decodesI know Im talking out my ass here.
Questions
bytes_to_hex_string
but then it looks like you decode itfunction decode(hexString)
back to a data format similar to what RTL provides -- wondering what is going on here? Im probably missing the obviousReally appreciate any ideas you might have
The text was updated successfully, but these errors were encountered: