See the above Mqtt configuration.
Hi All.
Iâm currently holding this device in hands and iâm kinda disappointed.
First of all, even via Mi Home it is very unresponsive. Sometimes i am getting push notifications / sometimes not. I can assume that it is because of Chinese cloud.
From other side, i faced another issue:
433 signals are not being sent every time. Only 2 of 3-4 are being caught by RF Bridge. Others are just ignored. Am i the only one who experience this issues or itâs a common problem?
Hi @gorenuru. I too had these issues but found a way to resolve them.
To figure out why this happens you have to understand the power saving tactics most wifi doorbells use in order to run on batteries for a prolonged amount of time.
This is what I make of it: in idle state the device is not connected to wifi in order to conserve energy. Therefore, if someone presses the doorbell, the device has to use RF to be able to send out a ring signal immediately, and only then it activates wifi to transfer the image it captured. When the wifi connection is established, which can take some time and last a while, all doorbell rings are relayed over wifi, not RF, until the wifi connection is dropped (to conserve energy) and then itâs back on RF again.
My workaround to expose both ring types to HA involves a xiaomi smart (zigbee) plug that is used as a kind of input boolean that is controlled by the Mi Home app. In the xiaomi app make an automation that turns on the smart plug whenever a ring is detected. This is to have HA detect âwifi ringsâ. The âRF ringsâ are detected through a binary sensor acting on the MQTT messages from the sonoff bridge. Ultimately, create an automation to have your home respond to both triggers/rings in whatever way you like. Donât forget to include automations that resets both the states of the plug and the binary sensor.
This is how iâve set it up:
configuration.yaml
binary_sensor:
- platform: mqtt
name: "Xiaomi Doorbell"
state_topic: "tele/sonoff/RESULT"
payload_on: "ACD805"
payload_off: "ACD805_off"
value_template: '{{ value_json.RfReceived.Data }}'
device_class: sound
qos: 1
automations.yaml
- alias: Doorbell bordes ring
initial_state: 'on'
trigger:
- platform: state
entity_id: switch.plug_158d000285xxxx
to: 'on'
- platform: state
entity_id: binary_sensor.xiaomi_doorbell
to: 'on'
condition:
- condition: or
conditions:
- condition: template
value_template: '{{ as_timestamp(now()) - as_timestamp(states.automation.doorbell_bordes_ring.attributes.last_triggered) | int > 7 }}'
- condition: template
value_template: '{% if states.automation.doorbell_bordes_ring.attributes.last_triggered == none %}True{% else %}False{% endif %}'
action:
- service: xiaomi_aqara.play_ringtone
data_template:
gw_mac: 7811DCB8xxxx
ringtone_id: 10
ringtone_vol: '{% if now().hour > 22 %}25{% elif now().hour > 20 %}50{% elif
now().hour < 7 %}50{% elif now().hour < 9 %}55{% else %}75{% endif %}'
- service: xiaomi_aqara.play_ringtone
data_template:
gw_mac: 7811DCDAxxxx
ringtone_id: 10
ringtone_vol: '{% if now().hour > 22 %}15{% elif now().hour > 20 %}40{% elif
now().hour < 7 %}40{% elif now().hour < 9 %}45{% else %}65{% endif %}'
- service: notify.notify
data:
message: "Er wordt aangebeld bij de voordeur"
- alias: Doorbell reset state RF
hide_entity: true
initial_state: 'on'
trigger:
- platform: state
entity_id: binary_sensor.xiaomi_doorbell
from: 'off'
to: 'on'
for:
seconds: 2
action:
- service: mqtt.publish
data:
topic: tele/sonoff/RESULT
payload: ACD805_off
- alias: Doorbell reset state plug
hide_entity: true
initial_state: 'on'
trigger:
- platform: state
entity_id: switch.plug_158d000285xxxx
from: 'off'
to: 'on'
for:
seconds: 2
action:
- service: switch.turn_off
entity_id: switch.plug_158d000285xxxx
- service: switch.turn_off
entity_id: switch.plug_158d000285xxxx
Probably not the prettiest solution and the dependency on the Mi Home app is a nuisance, but it works well for quite some time now.
4 Likes
Hoi Jeroen and thanks for your reply. What a brilliant idea! And i have one unused zigbee smart socket! Will definitely try.
One more question is about rf payload. i see that you use it as - is. Doesnât it change for you every time?
For me it is every time different with Tasmota.
What firmware are you using on Sonoff RF Bridge?
Nope, it doesnât change every time. Iâll check my Tasmota version later.
Fun fact regarding the Xiaomi zigbee smart plug: it acts as a zigbee repeater (on or off). I initially installed it to reach my mailbox in the front yard.
Yeah, i know about repeater capabilities.
I have 3 hubs and more then 100 Xiaomi smart devices 
Regarding rf code - i have Sonoff RF Bridge with Tasmota v6.6 and rf key is every time different.
Sonoff Bridge, same switch returns different data codes (Tasmota) here i found that people have the same issues with some Sonoff smart plugs. I am thinking of trying another sonoff firmware but disassembling it every time is annoying:)
The above setup is with Tasmota 6.5.0.13. No Portisch.
Hi Everyone!
I managed to find a reliable solution. (IMHO). Please read till the end before making any step. Maybe this is not something you are looking for.
First of all, the root cause of problem that i had (Sonoff RF Bridge is not reacting on every click and sending different messages every time) was that RF Bridge together with Tasmota and EFM8BB1 chip cannot decode Doorbellâs protocol properly.
The issue was not really related to itâs power management or something. I realised that by pairing doorbell with speaker that comes with it. That speaker was able to catch every click perfectly.
Small spoiler: i didnât find a way (yet) to decode it, but at least i found a way to receive signals on every click and i can still use them.
To fix this problem i had to flash Tasmota v 6.60 and Portish EFM8BB1 firmware (for RF module).
Steps on how to do that can be found here: https://github.com/arendst/Sonoff-Tasmota/wiki/Sonoff-RF-Bridge-433
Note #1: It only sounds scary. In fact, you donât have to cut 2 lines on the board if you are not powering RF Bridge with USB while flashing (5v) but instead use serial port (that gives 3v).
Note #2: Portish firmware releases are a bit messy. After some experiments i found that the latest one can be found here: https://github.com/Portisch/RF-Bridge-EFM8BB1/blob/af1bddb3d81c79d67063184219ec21f8249dffd0/Keil%208051%20v9.53%20-%20Release/RF-Bridge-EFM8BB1.hex
Note #3: Donât read sections that are not related to flashing process of Tasmota / Portish firmware. They describe how you can de-code caught codes to reproduce them (useful if you need to send this signal using RF Bridge, but we are interested in catching signals only, right?)
Note #4: After i installed Portish firmware, my bridge stoped seeing Xiaomi Doorbell messages as it used to see (but it see others on RAW mode as you will see later). I donât know if you can un-install Portish firmware, so be aware if you are just going to âplayâ with it.
After i did all those operations i went to RF Bridge console and switched RF module into âRawâ mode by running this command:
RfRaw 177
Then i clicked button on doorbell multiple times and got those codes:
Note #1. As you see, they are not decoded, but it is possible to extract unique device related part (at least, i was able to substring first 14 symbols and tested it during 3 days. First 14 symbols didnât change for me yet and didnât appear in any other bucket from other devices)
Note #2. Every click triggers multiple veeeery similar codes with a very small interval. This is not a big deal as i can throttle that later in HA.
Note #3. RfRaw 177 is considered to be âbucket fishingâ or âdebuggingâ mode and i found few mentions that people tried to use it as a main mode but their RF Bridge was dying after 3 - 4 hours. Only reboot helped. https://github.com/arendst/Sonoff-Tasmota/issues/5682#issuecomment-492638036
For me this is not the case as my bridge is already up for 3+ days. Maybe there was a bug in formware and they fixed it now?
To enable this mode âpermanentlyâ you have to execute following commands in RF Bridge console:
Rule1 ON System#Boot DO RfRaw 177 ENDON
Rule1 1
Next step was to define sensor in HA:
binary_sensor:
- platform: mqtt
name: "Xiaomi Doorbell"
state_topic: "tele/rfbridge/RESULT"
payload_on: "38181909090908"
off_delay: 3
value_template: '{{ value_json.RfRaw.Data.split(" ")[7][:14] }}'
device_class: sound
qos: 1
Note #1: See whatâs inside of âvalue_templateâ. I am actually extracting that long numbers sequence and extracting first 14 symbols from it. Then i match them in âpayload_onâ
Note #2: Latest home assistant allows you to define âoff_delayâ property (in seconds) so you donât have to care about additional automations.
Thatâs all, folks. It works perfectly for me. Unfortunately, i have to go to MiHome if iâd like to see photos / videos, but at least this lets me to play doorbell sound on my Mi Hubs + send push notifications.
BTW, response is almost instant.
Next steps: I ordered yet-another Sonoff RF Bridge and i am going to do a bit more investigation.
It is possible to decode raw signals without the use of on-board decoding chip (software method using rc_switch). This step requires some soldering as described here: https://github.com/xoseperez/espurna/wiki/Hardware-Itead-Sonoff-RF-Bridge---Direct-Hack
As a result - it will be possible to install ESPruna or ESPHome (my preference) on bridge. As far as i can judge from forums this method allows you do decode much more protocols + performance wise it is much faster.
Hope this will help someoneâŚ
1 Like
@gorenuru, there is no need to mod the Sonoff Bridge RF. I managed to get the RF ring using a simple MQTT code available on this thread.
# Xiaomi doorbell
- platform: mqtt
name: "Xiaomi Zero"
state_topic: "tele/RF_Bridge/RESULT"
payload_on: "41"
payload_off: "41_off"
value_template: '{{ value_json.RfReceived.Data[:2] }}'
device_class: light
qos: 1
It just needes to be adjusted by the first 2 char from the rolling code.
@ReDaLeRt i think you didnt read carefully what my problem was Riling code was one of them. Beside that bridge didnt catch all the signals. You ca try it yourself by trying to click the button on doorbell around 10 times in a row. you will notice that some of the clicks are ignored.
This doesnât happen to me on modified bridge.
And, off course, the last thing i want is to miss a call.
Beside that, 2 symbols is not unique enough if you have more then one device.
Anyone know any doorbell that integrates with HA without any cloud services?
1 Like
Ok, as i promised, i have some update.
Recently i received one more rf bridge and was able to hardware hack it.
Installed ESPHome and⌠It actually works well!
Catches all the messages that my doorbell sends.
Please note, that rolling messages problem still remains, but as with Tasmota, the beginning of code remains the same so you can identify your device.
For me this solution is better as it integrates much better with HA and i am a big fan of ESPHome.
If you are thinking if you should hardware hack + install ESPHOME on your bridge - my answer is do it!
This is a very powerful and easy to use solution.
You can remove the dependency on Mi Home app by using a ping binary sensor. Get the router to assign a static IP based on the doorbellâs Mac address and ping that instead. Another take on the âwifi ringâ. And ping should be much faster than the video transfer through Mi Home app.
It should work for multiple doorbells as well.
hello, it's been over 3 hours that I try to find the way in ESPhome to use only the first 9 bits of rc_switch_raw: but impossible, do you have a solution?
Hi, unfortunately not. I opened feature request on it, but no news so far.
If someone will find it - please share. This will be very helpful.
1 Like
I just found an alternative through mqtt:
Config esphome:
# Enable Home Assistant API
# api:
mqtt:
broker: 192.168.1.195
Result:
sonoff_rf_bridge/debug [D][remote.rc_switch:240]: Received RCSwitch Raw: protocol=1 data=â00111101010110101101101111111010â
config HA:
binary_sensor:
- platform: mqtt
name: "Xiaomi Doorbell"
state_topic: "sonoff_rf_bridge/debug"
payload_on: "'001111010"
off_delay: 3
value_template: '{{ value.split("=")[2][:10] }}'
device_class: sound
Oh nice so if you enable mqtt it will forward those messages to HA. Thanks! I will try it out. Sound like a reasonable solution. Beside that, this is exactly what i am doing with tasmota
1 Like
Ok, so i spend few hours today playing with Sonoff RF Bridge trying to forward messages to HA using MQTT.
To be fair i didnât like approach from @rmickael62 because he was parsing messages from all the debug logs that are forwarded from ESPHome to HA.
Itâs not structured enough IMHO.
I tried to use on_raw automation and use mqtt.publish like that:
remote_receiver:
pin: 4
dump: rc_switch
tolerance: 50
filter: 10us
idle: 4ms
on_raw:
then:
- mqtt.publish:
topic: tele/RF_Bridge/message
payload: !lambda |-
return esphome::to_string(x);
Unfortunately, once i add on_raw automation (even empty or the one that outputs âHello Worldâ into the console, my RF bridge stops working and blue light blinks like crazy. The only way to return it back to life is to disassemble, connect UART and re-flash.
After all, i went with @rmickael62 solution.
There are few things to note though:
- If you will not use some conditions, you will start seeing a lot of error messages because some of the logs cannot be split by â=â and as a result templating engine cannot get second element of split array.
- It is better to use [1:10] instead of [:10] then you will not have to match with the leading â symbol.
Here is my config:
- platform: mqtt
name: "Xiaomi Doorbell"
state_topic: "rfbridge/debug"
payload_on: "011000011"
off_delay: 3
value_template: >-
{% set parts = value.split("=") %}
{% if parts[2] -%}
{{parts[2][1:10]}}
{%- endif %}
device_class: sound
qos: 1
1 Like
Its another one of those products that is limited on purpose, so to use it to its advantage you have to buy a Mi Hub or whatever