Advanced bridge commands sniffing/bucket #11

zd3sf · 2024-09-12T02:05:26Z

Advanced commands that Portisch firmware uses (advanced sniffing , stop advanced sniffing, bucket transmit, bucket sniffing) are not available for OB38S003. It would be great if they can be implemented because they work well with ESPhome RF bridge component

Bridge: Sonoff RF bridge 2.2 (white)
RF chip: main_rcswitch_OB38S003.hex (Jul 02)
ESP: esphome 2024.8.3

zd3sf · 2024-09-12T11:32:12Z

Specifically commands 0xB0 and 0xB1 are very important for variable timing protocol. It would be greatly appreciated! And I can donate an RF bridge if you want!

mightymos · 2024-09-15T20:25:53Z

It is unlikely that I would work on this, mainly because it's uncertain how successful the effort would be.
I was able to get a fork of Portisch to compile using the SDCC compiler for the original EFM8BB1 (black sonoff case):
https://github.com/mightymos/SonOfPortisch
Porting over to the OBS38S003 would be possible but would require more abstraction in the code.

But even for the port I had to remove support for protocols/features so that code and ram memory were not over capacity.
And the compiler does not give much information when it goes over capacity and so it makes development difficult.

Possibly more to the point I really still do not understand how the bucket sniffing works.
I did learn more about different microcontroller architectures and compilers but the rcswitch decoding is much more straightforward to understand (i.e. basically just measuring and comparing timings using hardware capture module).

For decoding truly unknown radio protocols, people seem to prefer other projects:
https://github.com/merbanan/rtl_433
https://github.com/NorthernMan54/rtl_433_ESP

The cost of that hardware or a USB RTL SDR is probably comparable.

mightymos · 2024-09-15T20:34:54Z

You can also use the pass through firmware or hardware hack bypass along with ESPHome which supports raw decoding.
However, I can't be sure how well it works but it appears to be available:
https://esphome.io/components/remote_receiver.html

zd3sf · 2024-09-15T22:14:44Z

Thank you for your effort in the development. The difficulties of developing firmware are understandable. I have tried the passthrough mode first and I was able to capture some raw data, but none of which was complete or useful as the signal was drowned in raw dumps. No matter the settings, the output was just drowned in a insane amount of data, none of which can be attributed to any of my devices. I am still trying to understand how the parameters below can be tweaked, but hours passed and no luck, and I reverted to rcswitch.hex firmware.

tolerance: 60% filter: 10us idle: 5ms

If there is renewed interest in pursuing bucket sniffing, please let me know. For now, i'd really like to thank you again for your efforts.

mightymos · 2024-10-21T16:09:10Z

I'm still running into issues with the Portisch port, but am looking into it again.
I am able to get output using standard decoding and sniffing.

I am not sure that the sniffing output is correct/useful because I think it's reporting 4 buckets, but there should only be 3.
However, can you decode this 0xB1 result with the tool and tell me the result?

AA B1 04 01 9A 03 8E 00 FA 27 D8 38 18 19 29 28 19 28 19 28 19 29 29 28 18 19 28 18 18 18 18 19 28 19 28 18 55

mightymos · 2024-11-09T07:39:26Z

I now support Portisch on this release for both white and black box Sonoffs.
Sniffing support by command 0xB1 is also included:
https://github.com/mightymos/RF-Bridge-OB38S003/releases/tag/v0.4.1

I do not know if the sniffing output is correct or helpful however at this time.

zd3sf · 2024-11-09T16:59:11Z

I am very sorry I missed your comment. This is the tool that I use to convert "receive" to "send" commands 0xB1 and 0xB0
https://bbconv.hrbl.pl/

And glad to hear the you were successful. I will flash this right now and report back!

mightymos · 2024-11-09T17:43:30Z

The sniffing is not correctly returning all the serial data because the buffer is not large enough.
I need to probably share the transmit and receive buffer for uart as I think Portisch was doing.

In any case, I temporarily put in a hack and got this sniffing data from my door sensor:
{"RfRaw":{"Data":"AA B1 03 0138 03B7 277C 28181909081908190819090908181908181818181908190818 55"}}

I got this output from the tool:
AA B0 21 03 08 0138 03B7 277C 28181909081908190819090908181908181818181908190818 55

I guess the idea is to just paste that back as a transmit command, which I did on my other unit.
I was able to successfully receive that 0xB0 transmitted data on my development setup:
RESULT = {"Time":"2024-11-09T18:40:28","RfReceived":{"Sync":9921,"Low":289,"High":930,"Data":"35720A","RfKey":"None"}}

The data is correct for my door sensor.

But let me figure out the buffer issue, otherwise you'll never receive valid sniffing data (i.e. the uart buffer will overwrite itself).

zd3sf · 2024-11-09T18:29:02Z

Ok I flashed the portisch to the OBS38S003 tried a couple of things:

0xA5/0xA8 commands: The bridge would send/receive one transmission then becomes unresponsive. I either had to reboot or start advanced sniffing (0xA6) then stop sniffing(0xA7). But same thing one code and then unresponsive.
Bucket sniffing (0xB1): as soon as sniffing is started, this code is recieved: Received RFBridge Bucket: AA B1 05 029E 1812 00C6 0142 1DD4 C090A3A3 55, whether a button is pushed or not, then the bridge stops receiving signals.

Question, is the rcswtich firmware in this release different that that of Jul,2nd?

https://github.com/Portisch/RF-Bridge-EFM8BB1/wiki/Commands

mightymos · 2024-11-09T19:51:20Z

Ok, I'm checking into the buffers.
rcswitch firmware is different now also.

mightymos · 2024-11-17T07:25:49Z

Sorry for the previous confusion, please try the attached portisch for OB38S003 with 0xB0 and 0xB1 support.

main_portisch_OB38S003.zip

the-mentor · 2024-11-17T10:24:05Z

what is the advantage of using the portisch firmware over the pass-through one ?

zd3sf · 2024-11-17T13:54:42Z

@mightymos Trying the main_portisch_OB38S003.zip resulted in the same 2 problems in the post above.

mightymos · 2024-11-17T21:15:02Z

@mightymos Trying the main_portisch_OB38S003.zip resulted in the same 2 problems in the post above.

This is what I receive on Sonoff with OB38S003 from -
sniffing an open of my door sensor (i.e., 0xB1 command and last data byte should be 0x0A for open),
then standard decoding of close (i.e., 0xA7 command and last data byte should be 0x0E),
then finally transmitting with 0xB0 command converted from sniffed data using that web tool.

00:00:00.002 HDW: ESP8285N08
00:00:00.054 CFG: Loaded from flash at F8, Count 388
00:00:00.059 SER: Set to 8N1 19200 bit/s
00:00:00.061 QPC: Count 1
00:00:00.071 SER: Set to 8N1 19200 bit/s
00:00:00.075 Project tasmota - Tasmota_NoSpeaker Version 14.1.0(release-tasmota)-2_7_6(2024-06-03T11:53:14)
00:00:01.001 WIF: Connecting to AP1 Tribble Channel 9 BSSId A2:68:EC:94:90:75 in mode 11n as tasmota-723C46-7238...
00:00:03.511 WIF: Connected
00:00:03.763 HTP: Web server active on tasmota-723C46-7238 with IP address 192.168.10.135
21:47:58.509 RSL: INFO1 = {"Info1":{"Module":"Sonoff Bridge","Version":"14.1.0(release-tasmota)","FallbackTopic":"cmnd/DVES_723C46_fb/","GroupTopic":"cmnd/tasmotas/"}}
21:47:58.511 RSL: INFO2 = {"Info2":{"WebServerMode":"Admin","Hostname":"tasmota-723C46-7238","IPAddress":"192.168.10.135"}}
21:47:58.513 RSL: INFO3 = {"Info3":{"RestartReason":"Power On","BootCount":359}}
21:47:59.358 QPC: Reset
21:48:02.225 RSL: STATE = {"Time":"2024-11-17T21:48:02","Uptime":"0T00:00:10","UptimeSec":10,"Heap":27,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":27,"MqttCount":0,"Wifi":{"AP":1,"SSId":"Tribble","BSSId":"A2:68:EC:94:90:75","Channel":9,"Mode":"11n","RSSI":100,"Signal":-50,"LinkCount":1,"Downtime":"0T00:00:05"}}
21:53:02.228 RSL: STATE = {"Time":"2024-11-17T21:53:02","Uptime":"0T00:05:10","UptimeSec":310,"Heap":25,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":0,"Wifi":{"AP":1,"SSId":"Tribble","BSSId":"A2:68:EC:94:90:75","Channel":9,"Mode":"11n","RSSI":98,"Signal":-51,"LinkCount":1,"Downtime":"0T00:00:05"}}
21:53:37.054 CMD: rfraw AA B1 55
21:53:37.059 RSL: RESULT = {"RfRaw":"ON"}
21:53:37.125 RSL: RESULT = {"Time":"2024-11-17T21:53:37","RfRaw":{"Data":"AAA055"}}
21:53:41.308 RSL: RESULT = {"Time":"2024-11-17T21:53:41","RfRaw":{"Data":"AA B1 03 0138 03B5 2773 28181909081908190819090908181908181818181908190818 55"}}
21:53:41.436 RSL: RESULT = {"Time":"2024-11-17T21:53:41","RfRaw":{"Data":"AA B1 03 013B 03B2 2770 28181909081908190819090908181908181818181908190818 55"}}
21:53:41.563 RSL: RESULT = {"Time":"2024-11-17T21:53:41","RfRaw":{"Data":"AA B1 03 0139 03B4 277B 28181909081908190819090908181908181818181908190818 55"}}
21:53:41.691 RSL: RESULT = {"Time":"2024-11-17T21:53:41","RfRaw":{"Data":"AA B1 03 0138 03B4 2779 28181909081908190819090908181908181818181908190818 55"}}
21:53:41.819 RSL: RESULT = {"Time":"2024-11-17T21:53:41","RfRaw":{"Data":"AA B1 03 0138 03B5 2772 28181909081908190819090908181908181818181908190818 55"}}
21:53:55.598 CMD: rfraw AA A7 55
21:53:55.604 RSL: RESULT = {"RfRaw":"ON"}
21:53:55.662 RSL: RESULT = {"Time":"2024-11-17T21:53:55","RfRaw":{"Data":"AAA055"}}
21:54:22.644 RSL: RESULT = {"Time":"2024-11-17T21:54:22","RfRaw":{"Data":"AAA42772012F03B535720E55"}}
21:54:22.685 RSL: RESULT = {"Time":"2024-11-17T21:54:22","RfRaw":{"Data":"AAA4276D012F03B535720E55"}}
21:54:22.730 RSL: RESULT = {"Time":"2024-11-17T21:54:22","RfRaw":{"Data":"AAA4276A013203B735720E55"}}
21:54:22.771 RSL: RESULT = {"Time":"2024-11-17T21:54:22","RfRaw":{"Data":"AAA42761013003B735720E55"}}
21:54:22.857 RSL: RESULT = {"Time":"2024-11-17T21:54:22","RfRaw":{"Data":"AAA42776012F03B535720E55"}}
21:54:23.137 RSL: RESULT = {"Time":"2024-11-17T21:54:23","RfRaw":{"Data":"AAA42788012F03B835720E55"}}
21:54:23.144 RSL: RESULT = {"Time":"2024-11-17T21:54:23","RfRaw":{"Data":"AAA42766013203B735720E55"}}
21:54:23.283 RSL: RESULT = {"Time":"2024-11-17T21:54:23","RfRaw":{"Data":"AAA42772012C03B735720E55"}}
21:54:23.326 RSL: RESULT = {"Time":"2024-11-17T21:54:23","RfRaw":{"Data":"AAA4276A012C03B535720E55"}}
21:55:32.090 CMD: rfraw AA B0 21 03 08 0138 03B5 2773 28181909081908190819090908181908181818181908190818 55
21:55:32.097 RSL: RESULT = {"RfRaw":"ON"}
21:55:32.533 RSL: RESULT = {"Time":"2024-11-17T21:55:32","RfRaw":{"Data":"AAA055"}}

This is what I receive on my Sonoff with EFM8BB1 running original Portisch:

00:00:00.001 HDW: ESP8285N08
00:00:00.050 CFG: Loaded from flash at F9, Count 217
00:00:00.055 SER: Set to 8N1 19200 bit/s
00:00:00.056 QPC: Count 1
00:00:00.068 SER: Set to 8N1 19200 bit/s
00:00:00.073 Project tasmota - Tasmota_R2v1.0 Version 14.1.0(release-sensors)-2_7_6(2024-06-03T11:53:12)
00:00:01.001 WIF: Connecting to AP1 Tribble Channel 9 BSSId A2:68:EC:94:90:75 in mode 11n as tasmota-4339CA-6602...
00:00:03.523 WIF: Connected
00:00:03.778 HTP: Web server active on tasmota-4339CA-6602 with IP address 192.168.10.131
21:48:57.510 RSL: INFO1 = {"Info1":{"Module":"Sonoff Bridge","Version":"14.1.0(release-sensors)","FallbackTopic":"cmnd/DVES_4339CA_fb/","GroupTopic":"cmnd/tasmotas/"}}
21:48:57.512 RSL: INFO2 = {"Info2":{"WebServerMode":"Admin","Hostname":"tasmota-4339CA-6602","IPAddress":"192.168.10.131"}}
21:48:57.513 RSL: INFO3 = {"Info3":{"RestartReason":"Power On","BootCount":117}}
21:48:58.339 QPC: Reset
21:49:01.238 RSL: STATE = {"Time":"2024-11-17T21:49:01","Uptime":"0T00:00:10","UptimeSec":10,"Heap":22,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":0,"Wifi":{"AP":1,"SSId":"Tribble","BSSId":"A2:68:EC:94:90:75","Channel":9,"Mode":"11n","RSSI":100,"Signal":-29,"LinkCount":1,"Downtime":"0T00:00:05"}}
21:53:41.158 RSL: RESULT = {"Time":"2024-11-17T21:53:41","RfReceived":{"Sync":10270,"Low":340,"High":1010,"Data":"35720A","RfKey":"None"}}
21:54:01.272 RSL: STATE = {"Time":"2024-11-17T21:54:01","Uptime":"0T00:05:10","UptimeSec":310,"Heap":21,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":0,"Wifi":{"AP":1,"SSId":"Tribble","BSSId":"A2:68:EC:94:90:75","Channel":9,"Mode":"11n","RSSI":100,"Signal":-28,"LinkCount":1,"Downtime":"0T00:00:05"}}
21:54:22.651 RSL: RESULT = {"Time":"2024-11-17T21:54:22","RfReceived":{"Sync":10280,"Low":330,"High":1000,"Data":"35720E","RfKey":"None"}}
21:55:32.222 RSL: RESULT = {"Time":"2024-11-17T21:55:32","RfReceived":{"Sync":10350,"Low":400,"High":1040,"Data":"35720A","RfKey":"None"}}

These are the transmission commands I have been testing with on rcswitch and portisch (the examples are in the comments of rcswitch.c file):

 * (timings identical to protocol 1)
 * RfRaw AA A5 2A 62 01 5E 04 1A A5 5A A5 55
 * by protocol (protocol 1)
 * FIXME: should be 0x00 for protocol 1 as in portisch?
 * RfRaw AA A8 04 00 A5 5A A5 55

It might help if we could infer what the protocol is for your device.
Do you know anything about the device you're trying to sniff/replay like a model number?
Or what radio chip is inside the remote?

mightymos · 2024-11-17T21:19:33Z

what is the advantage of using the portisch firmware over the pass-through one ?

Portisch supports a sniffing mode for unknown radio protocols that essentially allows replaying a previously captured sniffing.
The sniffing mode is 0xB1 command and the complementary replay is 0xB0 command.

You observe the sniffing output and then convert to a 0xB0 command using this tool apparently:
https://bbconv.hrbl.pl/

I do not know yet how well the sniffing mode on original portisch (or my port) works with real devices.
The only device I have is a door sensor that uses the simplest protocol (i.e., the standard protocol discussed on the portisch wiki with just three timing buckets and with 24 bit data only). There are more complicated protocols that use more timing buckets and up to 40 data bits apparently.

zd3sf · 2024-11-17T23:11:21Z

This is the device that I am trying to control. The chip says 3002221 3AK C42EA. The post has more details but essentially:

payload_open: "AA B0 4A 03 14 026C 010E 1374 F00110011010100101101001010101011001011001010110101010011010010101101010101010100110101010101010101010101001100101100110100101100102 55"
payload_close: "AA B0 4A 03 14 026C 010E 1374 F00110011010100101101001010101011001011001010110101010011010010101101010101010100110101010101010101001101010100101011010101001100102 55"
payload_stop: "AA B0 4A 03 14 0276 0110 1374 F00110011010100101101001010101011001011001010110101010011010010101101010101010100110101010101010101010011010100101100101101001100102 55"

This is not the issue though. The issue is that the bridge freezes after one command (send or receive). Example

RCswitch firmware

Send (LED strip)

[16:59:30][D][switch:012]: 'Stove range light' Turning ON.
[16:59:30][D][rf_bridge:150]: Sending code: sync=0x2F08 low=0x04A4 high=0x0162 code=0x00C301
[16:59:31][D][rf_bridge:037]: Action OK

Receive (door sensor, my sensor sends the transmission 15 times)

[17:02:49][I][rf_bridge:057]: Received RFBridge Code: sync=0x24C9 low=0x0387 high=0x011E code=0x52C89E
[17:02:49][I][rf_bridge:057]: Received RFBridge Code: sync=0x24CD low=0x0385 high=0x0129 code=0x52C89E
[17:02:49][I][rf_bridge:057]: Received RFBridge Code: sync=0x24CD low=0x03A6 high=0x0118 code=0x52C89E
[17:02:50][I][rf_bridge:057]: Received RFBridge Code: sync=0x24CD low=0x0387 high=0x0129 code=0x52C89E
[17:02:50][I][rf_bridge:057]: Received RFBridge Code: sync=0x24C7 low=0x0385 high=0x012A code=0x52C89E
[17:02:50][I][rf_bridge:057]: Received RFBridge Code: sync=0x24CC low=0x037E high=0x0133 code=0x52C89E
[17:02:50][I][rf_bridge:057]: Received RFBridge Code: sync=0x24D0 low=0x0376 high=0x012A code=0x52C81E
[17:02:50][I][rf_bridge:057]: Received RFBridge Code: sync=0x24CF low=0x0385 high=0x0127 code=0x52C89E
[17:02:50][I][rf_bridge:057]: Received RFBridge Code: sync=0x24C9 low=0x0397 high=0x0123 code=0x52C89E
[17:02:50][I][rf_bridge:057]: Received RFBridge Code: sync=0x24CC low=0x0387 high=0x0129 code=0x52C89E
[17:02:50][I][rf_bridge:057]: Received RFBridge Code: sync=0x24CF low=0x0385 high=0x0129 code=0x52C89E
[17:02:50][I][rf_bridge:057]: Received RFBridge Code: sync=0x24CC low=0x0385 high=0x012D code=0x52C89E
[17:02:50][I][rf_bridge:057]: Received RFBridge Code: sync=0x24CF low=0x0384 high=0x012D code=0x52C89E
[17:02:51][I][rf_bridge:057]: Received RFBridge Code: sync=0x24CA low=0x0385 high=0x012F code=0x52C89E
[17:02:51][I][rf_bridge:057]: Received RFBridge Code: sync=0x24CA low=0x037F high=0x0127 code=0x52C89E

Portisch firmware

Send (LED strip)

[16:59:30][D][switch:012]: 'Stove range light' Turning ON.
[16:59:30][D][rf_bridge:150]: Sending code: sync=0x2F08 low=0x04A4 high=0x0162 code=0x00C301

No confirmation okay.
Receive (door sensor, my sensor sends the transmission 15 times but only one is captured then the bridge freezes)

[17:02:49][I][rf_bridge:057]: Received RFBridge Code: sync=0x24C9 low=0x0387 high=0x011E code=0x52C89E

and with bit bucket sniffing: it sniffs one code (with no buttons pressed) when sniffing is turned on and it freezes

ESPhome 2024.10 YAML:

esphome:
  name: sonoff-rf-bridge
  friendly_name: Sonoff RF Bridge

esp8266:
  board: esp01_1m

# Enable logging
logger:
  baud_rate: 0

# Enable Home Assistant API
api:
  encryption:
    key: "************************"

  services:
    - service: send_rf_code
      variables:
        sync: int
        low: int
        high: int
        code: int
      then:
        - rf_bridge.send_code:
            sync: !lambda 'return sync;'
            low: !lambda 'return low;'
            high: !lambda 'return high;'
            code: !lambda 'return code;'
    - service: send_rf_code_raw
      variables:
        raw: string
      then:
        - rf_bridge.send_raw:
            raw: !lambda 'return raw;'
    - service: learn
      then:
        - rf_bridge.learn


rf_bridge:
  on_code_received:
    then:
      #- homeassistant.event:
      #    event: esphome.rf_code_received
      #    data:
      #      sync: !lambda 'return format_hex(data.sync);'
      #      low: !lambda 'return format_hex(data.low);'
      #      high: !lambda 'return format_hex(data.high);'
      #      code: !lambda 'return format_hex(data.code);'
      - homeassistant.event:
          event: esphome.rf_code_received
          data:
            sync: !lambda 'return int(data.sync);'
            low: !lambda 'return int(data.low);'
            high: !lambda 'return int(data.high);'
            code: !lambda 'return int(data.code);'
  
  on_advanced_code_received:
    then:
      - homeassistant.event:
          event: esphome.rf_advanced_code_received
          data:
            length: !lambda 'return format_hex(data.length);'
            protocol: !lambda 'return format_hex(data.protocol);'
            code: !lambda 'return data.code;'



wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

 
uart:
  tx_pin: 1
  rx_pin: 3
  baud_rate: 19200



button:

  - platform: template
    name: Advanced sniffing start
    id: asstart
    on_press:
      then:
        - rf_bridge.start_advanced_sniffing

  - platform: template
    name: Advanced sniffing stop
    id: ASStop
    on_press:
      then:
        - rf_bridge.stop_advanced_sniffing    

  - platform: template
    name: Bucket sniffing start
    id: BSstart
    on_press:
      then:
        - rf_bridge.start_bucket_sniffing 


            


switch:
  - platform: template
    id: range
    name: "Stove range light"
    optimistic: true
    turn_on_action: 
      - rf_bridge.send_code:
          sync: 0x2F08
          low: 0x04A4
          high: 0x0162
          code: 0x00C301    
    turn_off_action: 
      - rf_bridge.send_code:
          sync: 0x2F23
          low: 0x04A1
          high: 0x0163
          code: 0x00C303

mightymos · 2024-11-18T06:09:53Z

Ok @zd3sf I am looking into the freezing issue.
I had a bug in rcswitch that was switching sync, low, and high byte order (assuming standard protocols).
I was also outputting a debug byte in portisch which might have been confusing esphome.

It is possible they are correct but I think the low and high timings in your script are reversed as a result.

In addition to a door sensor, I now have an outdoor light with remote that I have been able to control using 0xA5 commands.
But your output is very helpful.

Could we focus on just the LED strips for now because I assume they are the simplest protocol as compared with the AC123 remote?

I am assuming the LED strip has several buttons on an included remote, are you able to see that just a single data byte changes when different buttons are pressed?
Can you just send 0xA5 commands to try to control the LED strip now?

Here is the new release:
https://github.com/mightymos/RF-Bridge-OB38S003/releases/tag/v0.4.3

zd3sf · 2024-11-18T14:00:12Z

Thank you very much!! That explains why every time the RCswitch is flashed, I have to sniff the codes and re-program the button for the LED strip in ESPHome.

0.4.3-Portisch: Freezing issue persists.
0.4.3-RCswitch LED strip output: (buttons pushed 3 times)

ON button

[07:53:14][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F4C low=0x0186 high=0x0492 code=0x00C301
[07:53:14][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F43 low=0x0186 high=0x0492 code=0x00C301
[07:53:15][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F44 low=0x0186 high=0x0492 code=0x00C301

OFF button

[07:53:53][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F1A low=0x0184 high=0x048C code=0x00C303
[07:53:53][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F3E low=0x0186 high=0x0492 code=0x00C303
[07:53:54][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F23 low=0x0185 high=0x048F code=0x00C303

Brightness increase

[07:54:18][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F44 low=0x0186 high=0x0492 code=0x00C306
[07:54:18][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F41 low=0x0186 high=0x0492 code=0x00C306
[07:54:19][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F3B low=0x0186 high=0x0492 code=0x00C306

Brightness decrease

[07:55:13][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F38 low=0x0185 high=0x048F code=0x00C306
[07:55:13][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F38 low=0x0185 high=0x048F code=0x00C306
[07:55:14][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F34 low=0x0185 high=0x048F code=0x00C306

Sleep

[07:55:49][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F32 low=0x0185 high=0x048F code=0x00C309
[07:55:49][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F3E low=0x0186 high=0x0492 code=0x00C309
[07:55:50][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F34 low=0x0185 high=0x048F code=0x00C309

Timer clear

[07:56:16][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F40 low=0x0186 high=0x0492 code=0x00C30D
[07:56:17][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F46 low=0x0186 high=0x0492 code=0x00C30D
[07:56:17][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F34 low=0x0185 high=0x048F code=0x00C30D

Timer 30m

[07:56:40][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F3B low=0x0186 high=0x0492 code=0x00C30E
[07:56:40][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F26 low=0x0185 high=0x048F code=0x00C30E
[07:56:41][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F41 low=0x0186 high=0x0492 code=0x00C30E

Timer 1h

[07:57:10][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F43 low=0x0186 high=0x0492 code=0x00C30F
[07:57:10][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F40 low=0x0186 high=0x0492 code=0x00C30F
[07:57:11][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F49 low=0x0186 high=0x0492 code=0x00C30F

mightymos · 2024-11-18T15:39:05Z

Ok @zd3sf most of those codes look reasonable and are possibly correctly decoded because they just change by one bit.

The increase and decrease brightness codes are the same, which does not make sense, is that the true decoding or a typo?

Are you able to control the LED strip using those codes with the bridge or no?

zd3sf · 2024-11-18T15:58:38Z

I noticed the brightness codes, I was in a hurry and didn't check. I can confirm that I can turn the strip ON/OFF with the bridge. I don't use the other functions in home assistant so I didn't program them in. My guess they would work too. I can confirm that the door/window sensors work fine with the latest RCSwtich firmware. On Monday, November 18, 2024 at 09:39:28 AM CST, Jonathan Armstrong ***@***.***> wrote: Ok @zd3sf most of those codes look reasonable and are possibly correctly decoded because they just change by one bit. The increase and decrease brightness codes are the same, which does not make sense, is that the true decoding or a typo? Are you able to control the LED strip using those codes with the bridge or no? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

mightymos · 2024-11-20T07:42:32Z

@zd3sf I think I fixed the problems with 0xB0 and 0xB1 commands.
However, can you first confirm if transmitting with 0xA5 command is working or not with portisch (to turn on/off led strip)?

As best I can tell it operates similarly to rcswitch and does return an ACK on completion (e.g. AA A0 55).

main_portisch_OB38S003.zip

zd3sf · 2024-11-20T14:00:50Z

For the LED strip, transmitting with 0xA5 worked great! no problem, no freezing. There's still a problem receiving and freezing after receiving on command. The only way to 'unfreeze' is to either send another command (beep, start sniffing, stop sniffing, transmit 0xA5). In the log below, I pushed every button multiple times but it freezes after the first received message.

[07:49:43][W][component:237]: Component api took a long time for an operation (286 ms).
[07:49:45][D][api.connection:1446]: Home Assistant 2024.11.2 (192.168.1.110): Connected successfully
[07:49:55][I][rf_bridge:057]: Received RFBridge Code: sync=0x2F5E low=0x016B high=0x0486 code=0x00C303
[07:50:05][D][sensor:093]: 'Sonoff RF Bridge Uptime': Sending state 50.87700 s with 0 decimals of accuracy
[07:50:14][I][safe_mode:041]: Boot seems successful; resetting boot loop counter
[07:50:35][D][button:010]: 'Beep' Pressed.
[07:50:35][D][rf_bridge:224]: Beeping for 100 ms
[07:50:35][D][rf_bridge:037]: Action OK
[07:50:38][I][rf_bridge:057]: Received RFBridge Code: sync=0x2E66 low=0x0166 high=0x0484 code=0x00C303
***it froze***
[07:50:45][D][button:010]: 'Bucket sniffing start' Pressed.
[07:50:45][I][rf_bridge:209]: Raw Bucket Sniffing on
[07:50:46][D][rf_bridge:037]: Action OK
[07:50:48][I][rf_bridge:104]: Received RFBridge Bucket: AA B1 03 0169 04AA 2F38 28181818181818181909081818181909081818181818190908 55
[07:50:48][I][rf_bridge:104]: Received RFBridge Bucket: AA B1 03 0168 04A8 04AD 281818 55
***it froze***
[07:50:59][D][button:010]: 'Bucket sniffing start' Pressed.
[07:50:59][I][rf_bridge:209]: Raw Bucket Sniffing on
[07:50:59][D][rf_bridge:037]: Action OK
[07:51:01][I][rf_bridge:104]: Received RFBridge Bucket: AA B1 03 0166 04AA 2F58 28181818181818181909081818181909081818181818190908 55
[07:51:01][I][rf_bridge:104]: Received RFBridge Bucket: AA B1 03 0168 04A7 04AE 281818 55
***it froze***
[07:51:05][D][sensor:093]: 'Sonoff RF Bridge Uptime': Sending state 110.87600 s with 0 decimals of accuracy
[07:51:11][D][button:010]: 'Advanced sniffing start' Pressed.
[07:51:11][I][rf_bridge:193]: Advanced Sniffing on
[07:51:11][D][rf_bridge:037]: Action OK
[07:51:18][D][button:010]: 'Advanced sniffing stop' Pressed.
[07:51:18][I][rf_bridge:201]: Advanced Sniffing off
[07:51:18][D][rf_bridge:037]: Action OK
[07:51:21][I][rf_bridge:057]: Received RFBridge Code: sync=0x2E74 low=0x0163 high=0x047E code=0x00C303
***it froze***
[07:51:47][D][switch:012]: 'Stove range light' Turning ON.
[07:51:47][D][rf_bridge:150]: Sending code: sync=0x2F4C low=0x0186 high=0x0492 code=0x00C301
[07:51:47][D][switch:055]: 'Stove range light': Sending state ON
[07:51:48][D][rf_bridge:037]: Action OK
[07:51:55][D][switch:016]: 'Stove range light' Turning OFF.
[07:51:55][D][rf_bridge:150]: Sending code: sync=0x2F1A low=0x0184 high=0x048C code=0x00C303
[07:51:55][D][switch:055]: 'Stove range light': Sending state OFF
[07:51:56][D][rf_bridge:037]: Action OK
***No freezing***

mightymos · 2024-11-21T00:42:06Z

I think I might have to try flashing esphome to reproduce. Can you post your yaml here as a git gist link or inline?

EDIT: If it's similar to the yaml posted previously then no problem, I'll use that copy for now.

zd3sf · 2024-11-21T04:43:03Z

Sorry stuck at work tonight. The yaml above should have the right indentation. I removed the OTA component but the rest should be functional. Let me know If it doesn't work, I'll post a proper link

mightymos · 2024-11-21T07:46:43Z

Basically what was happening is that esphome sends an ACK back to the microcontroller after finished a command.
Now that behavior is re-enabled in the state machine, so I think decoding and sniffing work now.

I do not think Tasmota sends ACKs so I had not encountered the issue previously.

I think I somehow broke simple transmission again, I need to look at everything again.
I am also confused by the ACK logic but again can look at it fresh later.

You might want to check out my uploaded yaml, or at least add the "debug:" under your uart section so you can see raw bytes to understand what I'm talking about. And possibly enable status led.

You can try this latest file but again I need to look at source code again.
I did notice another buffer overflow type behavior once while sniffing and esphome page warns against this on original portisch.
So it seems unfortunately once I fix my bugs, portisch bugs might still remain to be fixed :-).

EDIT: OK, well maybe transmitting remains working. I'm able to receive codes with original portisch using stove range toggle. I guess use will reveal more problems or not.

main_portisch_OB38S003.zip

zd3sf · 2024-11-22T02:35:19Z

Okay this thing actually works!!

It only freezes after bucket sniffing is on for 1 minute. Must unplug power to unfreeze it (rebooting the ESP8266 doesn't help). Once it freezes Receive/Transmit (RfRaw 0xA5/0xA8) doesn't work. But if bucket sniffing is not started, it keeps working fine.

So I started bucket sniffing, collected all the codes for the AC123-01 (blinds), rebooted, converted everything to B0, and the bridge works sending B0 and receiving/sending 0xA4 | 0xA5 for the LED strip. so I now can control both the strip (standard) and the blinds(B0), recieve door alarms(standard)..... it doesn't freeze. As you mentioned the freezing after 1 minute bucket sniffing could be due to Portisch overflow.

using this tool https://jonajona.nl/convertB1.html

Blinds codes
Stop:

[18:54:50][I][rf_bridge:104]: Received RFBridge Bucket: AA B1 04 1386 023E 0112 139C 38192A192A1A1A19292A192A1A19292929292A1A1A1A1A192A19292A1A192A192A1A1A1A1A1A1A1A192A1A1A1A1A1A1A1A1A1A192A1A1A1929292A19292929292929 55
[18:54:51][I][rf_bridge:104]: Received RFBridge Bucket: AA B1 04 138A 0241 010E 1392 38192A192A1A1A19292A192A1A19292929292A1A1A1A1A192A19292A1A192A192A1A1A1A1A1A1A1A192A1A1A1A1A1A1A1A1A1A192A1A1A1929292A19292929292929 55
B0: AAB08F0408137502490111139F38192A192A1A1A19292A192A1A19292929292A1A1A1A1A192A19292A1A192A192A1A1A1A1A1A1A1A192A1A1A1A1A1A1A1A1A1A192A1A1A1929292A192929292929295538192A192A1A1A19292A192A1A19292929292A1A1A1A1A192A19292A1A192A192A1A1A1A1A1A1A1A192A1A1A1A1A1A1A1A1A1A192A1A1A1929292A1929292929292955

Up:

[18:55:09][I][rf_bridge:104]: Received RFBridge Bucket: AA B1 04 1377 0244 0111 139B 38192A192A1A1A19292A192A1A19292929292A1A1A1A1A192A19292A1A192A192A1A1A1A1A1A1A1A192A1A1A1A1A1A1A1A1A1A1A1A192A1929292A192A1A19292929 55
[18:55:28][I][rf_bridge:104]: Received RFBridge Bucket: AA B1 02 4301 1113 933B282A192A1A1A19292A192A1A19292929292A1A1A1A1A192A19292A1A192A1938191A1A1A1A1A1A192A1A1A1A1A1A1A1A1A1A1A1A192A1929292A192A1A19292A1A 55
B0: AAB04C0408137702440111139B38192A192A1A1A19292A192A1A19292929292A1A1A1A1A192A19292A1A192A192A1A1A1A1A1A1A1A192A1A1A1A1A1A1A1A1A1A1A1A192A1929292A192A1A1929292955

Down:

Received RFBridge Bucket: AA B1 04 137E 0249 010E 139C 38192A192A1A1A19292A192A1A19292929292A1A1A1A1A192A19292A1A192A192A1A1A1A1A1A1A1A192A1A1A1A1A1A1A1A1A192A1A1A1A192929292A192929292929 55
Received RFBridge Bucket: AA B1 04 1378 0249 010F 139E 38192A192A1A1A19292A192A1A19292929292A1A1A1A1A192A19292A1A192A19381A1A1A1A1A1A1A192A1A1A1A1A1A1A1A1A192A1A1A1A192929292A192929292A29 55
Received RFBridge Bucket: AA B1 02 4601 0F13 963D282A192A1A1A19292A192A1A19292929292A1A1A1A1A192A19292A1A192A1938191A1A1A1A1A1A192A1A1A1A1A1A1A1A1A1A192A1A1A1929292A19292929292A1A 55
B0: AAB04C0408137E0249010E139C38192A192A1A1A19292A192A1A19292929292A1A1A1A1A192A19292A1A192A192A1A1A1A1A1A1A1A192A1A1A1A1A1A1A1A1A192A1A1A1A192929292A19292929292955

zd3sf · 2024-11-22T03:14:16Z

ESPhome YAML for the blinds:

cover:
  - platform: time_based
    name: "Living room blinds"
    open_action:
      - rf_bridge.send_raw: 
          raw: 'AAB04C0408137702440111139B38192A192A1A1A19292A192A1A19292929292A1A1A1A1A192A19292A1A192A192A1A1A1A1A1A1A1A192A1A1A1A1A1A1A1A1A1A1A1A192A1929292A192A1A1929292955'
    open_duration: 26.26s
    close_action:
      - rf_bridge.send_raw: 
          raw: 'AAB04C0408137E0249010E139C38192A192A1A1A19292A192A1A19292929292A1A1A1A1A192A19292A1A192A192A1A1A1A1A1A1A1A192A1A1A1A1A1A1A1A1A192A1A1A1A192929292A19292929292955'
    close_duration: 25.99s
    stop_action:
      - rf_bridge.send_raw: 
          raw: 'AAB08F0408137502490111139F38192A192A1A1A19292A192A1A19292929292A1A1A1A1A192A19292A1A192A192A1A1A1A1A1A1A1A192A1A1A1A1A1A1A1A1A1A192A1A1A1929292A192929292929295538192A192A1A1A19292A192A1A19292929292A1A1A1A1A192A19292A1A192A192A1A1A1A1A1A1A1A192A1A1A1A1A1A1A1A1A1A192A1A1A1929292A1929292929292955'
    has_built_in_endstop: true

mightymos · 2024-11-22T08:42:08Z

That's very good.
I realized briefly I was doing something silly yesterday.
When one of my boards is erased it can leave the transmit pin in a floating or high state so that jamming interferes with other boards.

I may have to use one of my boards to simulate sending a long byte sequence in order to eventually investigate freezing.
I will try to remember to include the additional examples in the YAML.

Hopefully going forward I will primarily be making bug fixes and can test out myself but having help with real devices has been very useful. But I may try to add back in the learning mode.

One thing that I have not tried much is the advanced decoding with 0xA6 so anyway just FYI.
Although there is only enough memory to have one protocol included anyway...

Is that B1 to B0 conversion tool different than the bbconv tool or just shows bytes versus json format?

Can you test out the latest release?
https://github.com/mightymos/RF-Bridge-OB38S003/releases/tag/v0.4.4

zd3sf · 2024-11-23T01:18:05Z

Amazing! The Portisch firmware can control both the strip (standard) and the blinds (B0), receive door alarms(standard) successfully! Bucket sniffing does not freeze anymore, its been on for 5 minutes.

Note that the orange LED for the radio chip is also working correctly in this version. In the previous ones, it used to get stuck on after a transmit/receive. Now it only turns on during the actual transmit/receive time.

If you're okay with it, we should pull request the documentation page for ESPhome to advertise this firmware. I also want to buy you a coffee if you have a link!

mightymos · 2024-11-23T05:57:59Z

Amazing! The Portisch firmware can control both the strip (standard) and the blinds (B0), receive door alarms(standard) successfully! Bucket sniffing does not freeze anymore, its been on for 5 minutes.

Note that the orange LED for the radio chip is also working correctly in this version. In the previous ones, it used to get stuck on after a transmit/receive. Now it only turns on during the actual transmit/receive time.

If you're okay with it, we should pull request the documentation page for ESPhome to advertise this firmware. I also want to buy you a coffee if you have a link!

Well that's good to hear, sounds like several successes.
If you want to open a pull request I can help contribute to it or let me know otherwise.

You could buy a coffee, but really no worries either way given that your time to test devices was valuable:
https://ko-fi.com/jonathanarmstrong

zd3sf · 2024-11-24T01:59:13Z

The link is weird. I see the page, but no where to do a onetime coffee.

I noticed a strange thing, after 24 hours, the latest portisch firmware stopped receiving codes from window sensors. It can still send to the LED strip and to the blinds (bit buckets). I started advanced sniffing then stopped it, then it started receiving codes again. I don't have logs but I'll keep you posted if it happens again.

mightymos · 2024-11-24T02:12:12Z

The link is weird. I see the page, but no where to do a onetime coffee.

I noticed a strange thing, after 24 hours, the latest portisch firmware stopped receiving codes from window sensors. It can still send to the LED strip and to the blinds (bit buckets). I started advanced sniffing then stopped it, then it started receiving codes again. I don't have logs but I'll keep you posted if it happens again.

Ok, I think I needed to click through more settings. If you go back to ko-fi again I think it will work.

Absolutely do try to report strange things, it will help users in the future if bugs are ironed out now.
I will try to setup a more permanent testing setup so I can monitor longer term as well.

otsoni · 2024-11-26T15:38:48Z

I am mainly bucket sniffing on my board and I think that it have stopped receiving buckets after multiple hours. I think it's not exactly 24 hours, but I am not sure. Today I got it back sniffing buckets with sending B1 again, but I will test it more in following days and let you know if it happens again. I think that one time it did the same thing and I tried to beep the board but it kept beeping too long and I just shut the board (didn't want to listen the beep too long) and I can test it too if it happens again.

zd3sf · 2024-11-26T15:46:23Z

For me, bucket sniffing stops after an hour which could be from original Portisch overflow. The bug where the bridge stops receiving 0xA4 standard (but kept transmitting 0xA5 and B0) hasn't happened since.

mightymos · 2024-11-26T21:48:58Z

I had tried replaying the 0xB0 codes to simulate a remote talking to blinds using two bridges but I was not able to receive.
I am sure I can make it work for testing eventually with just an advanced transmit command.

I can also just leave my bridge in sniffing mode overnight and see what happens.

I know this does not fix the bug, but in the short term would it help if I added a command to reset the microcontroller?

Both microcontrollers support reset by firmware.
I will need to double check the reset behavior, for example to confirm that registers or memory initialize to similar values as on power up reset (or not).

So for example you might send a new command like this to reset processor:
AA FE 55

I might also possibly consider forcing a reset in the code if a buffer attempts to write past the buffer length.
Right now, in one place that I recall it just refuses to write more bytes to the buffer but otherwise fails silently.
The only issue with resetting on an error is then it would be necessary to log the reset somehow.

But anyway, if you can manually cause a reset it would at least remove the need to unplug and replug power?

mightymos · 2024-11-27T03:01:57Z

This version should allow forcing microcontroller reset with:
AA FE 55

I will look into the bug stuff as soon as I can test.

main_portisch_OB38S003.zip

zd3sf · 2024-11-27T03:06:32Z

Naive question, How would I send the reset command?

mightymos · 2024-11-27T03:11:54Z

Naive question, How would I send the reset command?

It looks like from your yaml there is rf_bridge.send_raw, so you just do that with raw: 'AAFE55'
You should see the red led startup blink if it is successful.

otsoni · 2024-11-27T17:46:06Z

I am using the same firmware as earlier and it seems that something is causing some kind of overflow or something. After activating B1 I can read maybe 5 (not exactly five every time) codes or so and after that it stops. I can activate it again with B1 and it works again for maybe next five. It seems that if I call beep for 100ms it beeps so long that watchdog resets the chip. It doesn't matter if I have called B1 again or not, beeping will take too long for watchdog. But after boot, if it has not got that overflow (or whatever this is) beep is working normally.

Is there some idea where this might be happening? Can it be stack overflow? I think stack overflow would mess the registers r0 etc, but I don't know if those are used for the beep delay. Or is it just some array overflow or something? I can try to get some extra data if I know what to get and if this keeps happening again.

otsoni · 2024-11-27T18:08:03Z

I have two boards that I think they have the same firmware version, but I don't actually remember what I flashed to those boards yesterday. I have been building and flashing firmwares so it might be that they are not the same version, because the other is reading B1 codes fine and the other is doing that what I wrote in previous message.

zd3sf · 2024-11-27T18:16:55Z

I'm on the latest official release, the bridge beeps for 100ms as expected. Let me know what you find out about the 2 bridges

otsoni · 2024-11-27T18:45:07Z

I was away for 30 minutes and the other board is kinda doing the same thing now. It seems that activating the B1 and receiving 64 bit nexa signal is doing something there. The other board is not stopping the sniffing as soon as the other board, but it seems that even receiving the first code is messing something there as beeping after receiving just one code is causing the long beep and watchdog reset. I will try the official build next to test if it is just my build.

otsoni · 2024-11-27T19:14:56Z

It is doing the same thing with official build 0.4.4. I try to create example yaml for esphome so that you could send the same codes and try to replicate the error.

otsoni · 2024-11-27T19:27:37Z

Here is my example yaml. Nexa code sned_code can be used to send nexa code. Maybe other codes cause the same thing to happen too

esphome:
  name: sonoff-rf-bridge-dev-2
  friendly_name: Sonoff RF Bridge DEV 2

esp8266:
  board: esp01_1m

# Enable logging
logger:
  baud_rate: 0

ota:
  - platform: esphome
    password: "password"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Sonoff-Rf-Bridge-Dev"
    password: "password"

captive_portal:
 
uart:
  tx_pin: 1
  rx_pin: 3
  baud_rate: 19200

# Enable Home Assistant API
api:
  encryption:
    key: "key"
  
  services:
  #Code can be sent as int or as a hex. I've chosen integer. Most people use hex.
    - service: send_rf_code
      variables:
        sync: int
        low: int
        high: int
        code: int
      then:
        - rf_bridge.send_code:
            sync: !lambda 'return sync;'
            low: !lambda 'return low;'
            high: !lambda 'return high;'
            code: !lambda 'return code;'
    - service: send_rf_code_raw
      variables:
        raw: string
      then:
        - rf_bridge.send_raw:
            raw: !lambda 'return raw;'
    - service: learn
      then:
        - rf_bridge.learn

rf_bridge:
#code can also be recieved (sniffed) as hex or as integer or both. Dealer's choice!
  on_code_received:
    then:
      - homeassistant.event:
          event: esphome.rf_code_received
          data:
            sync: !lambda 'return format_hex(data.sync);'
            low: !lambda 'return format_hex(data.low);'
            high: !lambda 'return format_hex(data.high);'
            code: !lambda 'return format_hex(data.code);'
            
      - homeassistant.event:
          event: esphome.rf_code_received
          data:
            sync: !lambda 'return int(data.sync);'
            low: !lambda 'return int(data.low);'
            high: !lambda 'return int(data.high);'
            code: !lambda 'return int(data.code);'
  
  on_advanced_code_received: #Portisch only, doesnt do anything on RCswitch firmware
    then:
      - homeassistant.event:
          event: esphome.rf_advanced_code_received
          data:
            length: !lambda 'return format_hex(data.length);'
            protocol: !lambda 'return format_hex(data.protocol);'
            code: !lambda 'return data.code;'

button:
  # Restart the ESP
  - platform: restart
    name: "Restart"
  
  - platform: template
    name: Advanced sniffing start
    id: AS_start
    on_press:
      then:
        - rf_bridge.start_advanced_sniffing

  - platform: template
    name: Advanced sniffing stop
    id: AS_stop
    on_press:
      then:
        - rf_bridge.stop_advanced_sniffing    

  - platform: template
    name: Bucket sniffing start
    id: BS_start
    on_press:
      then:
        - rf_bridge.start_bucket_sniffing 


  - platform: template
    name: Beep
    id: Beep
    on_press:
      then:
        - rf_bridge.beep:
            duration: 100

  - platform: template
    name: Nexa code send_code
    id: Nexa_send
    on_press:
      then:
        - rf_bridge.send_raw: 
            raw: 'AAB04C040800CA0A510502278A38180828082828082808280808280828280828080828280828082808082828080828082808282808280828080828082828082808082808280828082808280828082855'

# Sensors for ESP version and WIFI information
text_sensor:
  # ESPHome version
  - platform: version
    hide_timestamp: true
    name: "ESPHome Version"
  # IP address and connected SSID
  - platform: wifi_info
    ip_address:
      name: "IP Address"
      icon: mdi:wifi
    ssid:
      name: "Connected SSID"
      icon: mdi:wifi-strength-2
sensor:
  # WiFi signal
  - platform: wifi_signal
    name: "WiFi Signal"
    update_interval: 120s
  - platform: uptime
    name: Sonoff RF Bridge Uptime
binary_sensor:
  - platform: status
    name: Sonoff RF Bridge Status

light:
  - platform: status_led
    name: "Status LED"
    pin: 
      number: GPIO13
      inverted: true

zd3sf · 2024-11-27T22:30:33Z

@otsoni I think we should move this to its own separate thread. I have had bucket sniffing B1 on for 30 minutes and its still going, after a while the beeping changed in duration and pitch just like you said. So, bucket sniffing messes with beeping through an overflow or somethign. I can send raw your Nexa_send code with no problems.

@mightymos I tried the new firmware, when its reset, the orange LED turns on for 1 second and the log shows :

[16:25:06][D][rf_bridge:217]: Sending Raw Code: AAFE55

I assume that worked?

we can add this the example YAML

button:
  - platform: template
    name: "restart radio"
    id: mcu_reset
    on_press:
      then:
      - rf_bridge.send_raw: 
          raw: 'AAFE55'

mightymos · 2024-11-28T18:55:25Z

@otsoni I think we should move this to its own separate thread. I have had bucket sniffing B1 on for 30 minutes and its still going, after a while the beeping changed in duration and pitch just like you said. So, bucket sniffing messes with beeping through an overflow or somethign. I can send raw your Nexa_send code with no problems.

@mightymos I tried the new firmware, when its reset, the orange LED turns on for 1 second and the log shows :
[16:25:06][D][rf_bridge:217]: Sending Raw Code: AAFE55
I assume that worked?

we can add this the example YAML
button:
  - platform: template
    name: "restart radio"
    id: mcu_reset
    on_press:
      then:
      - rf_bridge.send_raw: 
          raw: 'AAFE55'       

Yes, the startup blink should be a good indicator that microcontroller reset.
I am running one of the bridges with esphome exclusively now, so will try to reproduce freezes/problems.

If you submit anymore pull requests for yaml you should use secrets.yaml file:
https://esphome.io/guides/faq.html

.gitignore should ignore that file name for file tracking but you could also confirm prior to submission.
And change any keys that have been published.

I will close this issue for now since Portisch port has been implemented.
But please open a new issue to track "freezing" or any other issues.

mightymos added the enhancement New feature or request label Sep 12, 2024

mightymos self-assigned this Nov 9, 2024

mightymos closed this as completed Nov 9, 2024

mightymos reopened this Nov 9, 2024

This was referenced Nov 23, 2024

A few questions #13

Closed

Support user supplied protocol timings from host for receive decoding #14

Open

mightymos closed this as completed Nov 28, 2024

Advanced bridge commands sniffing/bucket #11

Advanced bridge commands sniffing/bucket #11

Comments

zd3sf commented Sep 12, 2024

zd3sf commented Sep 12, 2024

mightymos commented Sep 15, 2024

mightymos commented Sep 15, 2024

zd3sf commented Sep 15, 2024

mightymos commented Oct 21, 2024

mightymos commented Nov 9, 2024

zd3sf commented Nov 9, 2024

mightymos commented Nov 9, 2024

zd3sf commented Nov 9, 2024

mightymos commented Nov 9, 2024

mightymos commented Nov 17, 2024

the-mentor commented Nov 17, 2024

zd3sf commented Nov 17, 2024

mightymos commented Nov 17, 2024

mightymos commented Nov 17, 2024 • edited Loading

zd3sf commented Nov 17, 2024 • edited Loading

RCswitch firmware

Portisch firmware

ESPhome 2024.10 YAML:

mightymos commented Nov 18, 2024

zd3sf commented Nov 18, 2024 • edited Loading

mightymos commented Nov 18, 2024

zd3sf commented Nov 18, 2024 via email

mightymos commented Nov 20, 2024

zd3sf commented Nov 20, 2024

mightymos commented Nov 21, 2024 • edited Loading

zd3sf commented Nov 21, 2024 via email

mightymos commented Nov 21, 2024 • edited Loading

zd3sf commented Nov 22, 2024 • edited Loading

zd3sf commented Nov 22, 2024

mightymos commented Nov 22, 2024

zd3sf commented Nov 23, 2024

mightymos commented Nov 23, 2024

zd3sf commented Nov 24, 2024

mightymos commented Nov 24, 2024

otsoni commented Nov 26, 2024

zd3sf commented Nov 26, 2024

mightymos commented Nov 26, 2024

mightymos commented Nov 27, 2024

zd3sf commented Nov 27, 2024 via email

mightymos commented Nov 27, 2024 • edited Loading

otsoni commented Nov 27, 2024

otsoni commented Nov 27, 2024

zd3sf commented Nov 27, 2024

otsoni commented Nov 27, 2024

otsoni commented Nov 27, 2024

otsoni commented Nov 27, 2024

zd3sf commented Nov 27, 2024 • edited Loading

mightymos commented Nov 28, 2024

mightymos commented Nov 17, 2024 •

edited

Loading

zd3sf commented Nov 17, 2024 •

edited

Loading

zd3sf commented Nov 18, 2024 •

edited

Loading

mightymos commented Nov 21, 2024 •

edited

Loading

mightymos commented Nov 21, 2024 •

edited

Loading

zd3sf commented Nov 22, 2024 •

edited

Loading

mightymos commented Nov 27, 2024 •

edited

Loading

zd3sf commented Nov 27, 2024 •

edited

Loading