rfraw 177 (B1 command) mode seems to stop after some time...

[bleuos1613]

Hello. First ..thanks for this excellent Work. I whole new world for my domotics ;-). (my RTL SDR with rtl_433 not being sensible enough to catch some of my sensor signals...)

I'm using this firmware for sniffing 433MHz signals. Wanting to keep it as much generic as possible, i activated rfraw 177 mode to sniff the environment and send all packed through MQTT channel to a node-red flow where i do the decoding that fits my needs. It works well..

Nevertheless after some time 1 or 2 hours, this delay seems to change, I don't see any more the raw data on the Tasmota console. When i resend the rfraw 177 command on the console, the flow resume and i get new messages.

What can explain such a behavior of the firmware ? Regards. Olivier

[thermseekr]

Hello,

Can’t help you on the rf177 command, but allow me to ask: are you using the correct antenna? It’s usual that the SDR receivers come with a short antenna more suitable for the 900MHz range. Thought it can also receive 433MHz signals, the performance is very low. I had a similar problem at my install and replacing the antenna for one more suitable for 433MHz the signals started to come in much stronger.

Regards Tales

Enviado do meu iPhone

Em 16 de ago de 2020, à(s) 06:19, bleuos1613 notifications@github.com escreveu:

 Hello. First ..thanks for this excellent Work. I whole new world for my domotics ;-). (my RTL SDR with rtl_433 not being sensible enough to catch some of my sensor signals...)

I'm using this firmware for sniffing 433MHz signals. Wanting to keep it as much generic as possible, i activated rfraw 177 mode to sniff the environment and send all packed through MQTT channel to a node-red flow where i do the decoding that fits my needs. It works well..

Nevertheless after some time 1 or 2 hours, this delay seems to change, I don't see any more the raw data on the Tasmota console. When i resend the rfraw 177 command on the console, the flow resume and i get new messages.

What can explain such a behavior of the firmware ? Regards. Olivier

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[bleuos1613]

Thanks Tales for feedback on RTL-SDR antenna, I will check it with nanoVNA ;-) for my antenna optimal frequency vswr range. I'm thinking the dedicated 433MHz receiver chip will nevertheless show better sensitivity (TBC maybe..). That discussion would nevertheless be "off topic" somehow ;-). Olivier

[halfbakery]

The bucket sniffer code contains two buffer overflow errors, which could eventually overwrite the active command and terminates the sniffing. Here's a patched version: https://github.com/halfbakery/RF-Bridge-EFM8BB1/commit/97155e1cf77c4687c53d4e3c6dedac1821e8f8bd

[bkbartk]

@halfbakery thank you for the fix, this one seems to be the most stable I have found till now. I have the feeling that still sometimes, a button press gets missed. so I tried the complete rebaked_sniffer. but for some reason the rawdata for the same button is different all the time. I'm I doing something wrong here?

Edit, this branch actually is perfect. Found out that my button is faulty and did not always transmit.

[JoergSmartHome]

Same Problem! I've activated the RfRaw 177 mode via the console and after some hours I do not receive raw data anymore! It seems that the mode will be switched to another one!?

To active RfRaw 177 after a reboot, I've set the following rule: Rule1: ON System#Boot DO RfRaw 177 ENDON

After I figured out that the mode gets lost, I've tried to set an addional rule which sets the mode every 30 minutes: Rule2: ON Clock#Time=All,**:30 DO RfRaw 177 ENDON

But this doesn't solve the problem! :-(

If I enter RfRaw 177 again (via console) or after rebooting the RF Bridge (than Rule1 will be triggered) everything is fine and I do receive the data again: 16:03:14.993 MQT: tasmota/sonoff/rfbridge/tele/RESULT = {"Time":"2021-05-17T16:03:14","RfRaw":{"Data":"AA B1 03 015E 03B6 26FC 01010101010101100110011001100110010101100110010102 55"}}

I wonder how to process data in RAW mode if it does not remain stably configured?

[bkbartk]

The fix halfbackery suggests actually works great. but there still is an issue which I found for the byron doorbell So I tried to fix it and it's available here https://github.com/bkbartk/RF-Bridge-EFM8BB1/releases/tag/v1 code is still far from perfect but this one works for me. also after all toggle/switch command enter ";RfRaw 177;" again like this ` payload_available: "Online" payload_not_available: "Offline" payload_off: "AA B0 21 03 08 02F8 0104 1F18 ssssssssssssssssssss 55;RfRaw 177" payload_on: "AA B0 21 03 08 02F8 0104 1F18 ssssssssssssssss 55;RfRaw 177"

• platform: mqtt` becaus else after sending a command always mode 0 is selected again.

[halfbakery]

My idea is to use the EFM8BB1 as a receiver and let the decoding to the rtl_433 project. The rtl_433 project could decode a lot of complex protocols. I have a stalled PR: https://github.com/merbanan/rtl_433/pull/1491

I hope I'll have some time in the near future to work on this project.

[JoergSmartHome]

@bkbartk @halfbakery: Thank you guys for your help and the fix!

I've installed the version from https://github.com/bkbartk/RF-Bridge-EFM8BB1/releases/tag/v1 yesterday morning and the RfRaw 177 mode still works!

For me it works great because I'm just listening to the codes of my remote controls (ELRO and ChiliTec Pilota Casa) via MQTT and not sending any codes to RF devices.

[Steve2017]

I have @halfbakery's file installed on my Sonoff Bridge and it seems to work pretty well - but I was still having the issue of rfraw 177 turning itself off.

I was getting this in the console:

MQT: stat/RFBridge1/RESULT = {"RfRaw":"ON"}
MQT: stat/RFBridge1/RESULT = {"RfRaw":"OFF"}

I have the rule suggested with the rtl_433 add-on: Rule1 on system#boot do RfRaw 177 endon

I wondered if this might help - it should retrigger rfraw 177 every hour when the Sonoff Bridge checks the NTP server:

Rule2 on Time#Set do RfRaw 177 endon
Rule2 1

[bkbartk]

you shouldn't need to do this every hour. however you need to do this after every command you send. so if you send a switch command to turn on/off the lights you need to enable rfraw 177 afterwards. using HA you can do something like this payload_on: "AA B0 21 03 08 02F8 0104 1F18 ssssssssssssssss 55;RfRaw 177"

[Steve2017]

you shouldn't need to do this every hour. however you need to do this after every command you send. so if you send a switch command to turn on/off the lights you need to enable rfraw 177 afterwards. using HA you can do something like this payload_on: "AA B0 21 03 08 02F8 0104 1F18 ssssssssssssssss 55;RfRaw 177"

That's useful thanks because I do use the RF Bridge to control fans. So I would need to add that to the end of every one of my rf commands? Something like: rfraw AA B0 21 03 08 00FA 0348 2184 28190819090819090819090909081908190818190818190818 55; rfraw 0; rfraw 177

(a backlog command precedes that.)

EDIT: Luckily all my RF commands are done via scripts - so all I had to do was add that to the relevant scripts and all commands and automations now turn RFRAW 177 back on.

[dharvind]

you shouldn't need to do this every hour. however you need to do this after every command you send. so if you send a switch command to turn on/off the lights you need to enable rfraw 177 afterwards. using HA you can do something like this payload_on: "AA B0 21 03 08 02F8 0104 1F18 ssssssssssssssss 55;RfRaw 177"

Hi @bkbartk , I successfully flashed the bkbartk/RF-Bridge-EFM8BB1 firmware on a Sonoff Bridge running Tasmota 12.0.2.2. As with the older portisch firmware, rfraw 177 does not seem to work as described in the wikis/guides. Would you be able to advise on it? Here is the behaviour: Flash tasmota latest - 12.0.2.2 (tried with older 8.4.0, 9.5.0, 10.1.0 but same result) and set module to sonoff bridge - flash success Cut the 2 connections, connect the pins and flash portisch firmware - flash success Run rfraw 0 + rfraw 177 -> getting ack message AAA055, press button on remote but nothing appearing when pressing (tested with multiple remotes) There are some messages however that appear in an adhoc manner (not when immediately pressing the buttons) but they are much shorter than the ones shown in the wiki:

11:39:17.675 CMD: rfraw 0
11:39:17.679 RSL: RESULT = {"RfRaw":"OFF"}
11:39:23.035 CMD: rfraw 177
11:39:23.039 RSL: RESULT = {"RfRaw":"ON"}
11:39:23.353 RSL: RESULT = {"Time":"2022-07-02T11:39:23","RfRaw":{"Data":"AAA055"}}
11:40:21.503 RSL: RESULT = {"Time":"2022-07-02T11:40:21","RfRaw":{"Data":"AA B1 04 0082 0316 00FA 0190 381A1A 55"}}
11:42:48.470 RSL: RESULT = {"Time":"2022-07-02T11:42:48","RfRaw":{"Data":"AA B1 06 0154 0244 04EC 113A 00AA 033E 581A083C 55"}}
11:43:14.448 RSL: RESULT = {"Time":"2022-07-02T11:43:14","RfRaw":{"Data":"AA B1 03 00A0 030C 04D8 281819 55"}}
11:44:09.072 RSL: RESULT = {"Time":"2022-07-02T11:44:09","RfRaw":{"Data":"AA B1 03 0136 02F8 0302 281818 55"}} //these are not while pressing the remote control buttons, not sure what it is...
11:44:39.036 CMD: rfraw 0
11:44:39.041 RSL: RESULT = {"RfRaw":"OFF"}

The test commands are returning good result as suggested in the wiki:

11:44:42.075 CMD: rfraw AAFF55
11:44:42.080 RSL: RESULT = {"RfRaw":"ON"}
11:44:42.154 RSL: RESULT = {"Time":"2022-07-02T11:44:42","RfRaw":{"Data":"AA0355"}}
11:44:42.159 RSL: RESULT = {"Time":"2022-07-02T11:44:42","RfRaw":{"Data":"AAA055"}}
11:44:53.451 CMD: rfraw 0
11:44:53.456 RSL: RESULT = {"RfRaw":"OFF"}
11:45:00.007 CMD: rfraw AAA155
11:45:00.012 RSL: RESULT = {"RfRaw":"ON"}
11:45:00.106 RSL: RESULT = {"Time":"2022-07-02T11:45:00","RfRaw":{"Data":"AAA055"}}
11:45:31.136 RSL: RESULT = {"Time":"2022-07-02T11:45:31","RfRaw":{"Data":"AAA255"}}
11:46:55.966 CMD: rfraw 0
11:46:55.971 RSL: RESULT = {"RfRaw":"OFF"}

[bkbartk]

data can be shorter

08:29:44.327 MQT: tele/tasmota_EDEBDA/RESULT = {"Time":"2022-07-04T08:29:44","RfRaw":{"Data":"AA B1 04 0082 0230 0140 02BC 38081A08 55"}} 08:30:00.327 MQT: tele/tasmota_EDEBDA/RESULT = {"Time":"2022-07-04T08:30:00","RfRaw":{"Data":"AA B1 05 0082 06AE 00F0 0348 0316 48181A3A 55"}} 08:30:13.318 MQT: tele/tasmota_EDEBDA/RESULT = {"Time":"2022-07-04T08:30:13","RfRaw":{"Data":"AA B1 04 00BE 014A 0064 02F8 38180A 55"}} 08:30:51.645 MQT: tele/tasmota_EDEBDA/RESULT = {"Time":"2022-07-04T08:30:51","RfRaw":{"Data":"AA B1 03 00AA 0802 087A 281818 55"}}

you probably register some button presses from other devices in the neighbourhood far away so the signal gets broken. I don't know why it won't work with your devices. I know there are some changes in the 433 spectrum, most cheap devices are using 433.98mhz. while more expensive once are using a different ranch. And I'm not sure if the portisch firmware catches both. You can check the frequency of your remote.

[dharvind]

Thanks @bkbartk. This one is 433 - see the photo: But I also tried other remotes, and one of them works with broadlink rm4 mini (which i'm still unable to integrate with my system). In the flashing guide of the sonoff bridge, there is the part where a cut needs to be made on the board - wondering if I did this wrong. But if it was wrong, the flash itself would have failed right?

[bkbartk]

I don't know, Apply this modification only if you intend to use USB for powering the device during flash process or if you want to use GPIO4 or GPIO5 for other purposes with the RF Bridge.

but I used the pinheader to power the device during flashing

I actually think you did everything right as you get results, but there are some strange things in portisch.

Before I went for the sonoff bridge, I actually treid this approach https://ehoco.nl/verzenden-en-ontvangen-433mhz-op-raspberry-pi/ I can't find the EN article, But I know it's out there and this is a translation. That actually had a better result based on receiving and transmitting when protyping. Only I could get it to work is production as my soldering skills are a little poor. But you could try if that makes any difference for you.