Advanced bridge commands sniffing/bucket

[zd3sf]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

1) 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.

2) 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]

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

[mightymos]

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

main_portisch_OB38S003.zip

[the-mentor]

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

[zd3sf]

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

[mightymos]

@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]

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]

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]

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]

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]

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]

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]

@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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.