If you make hardware mods and switch to ESPhome can you still switch back to tasmota? Or do the hardware mods not allow this?
I don’t think you can. You can switch to openmqttgateway after the mod. I use my rf bridges with openmqttgateway.
How exactly did you do that? I can see nothing about Sonoff RF Bridge on the ESPHome website.
I’m using my RF Bridge with OMG and wonder if there are any benefits of switching to ESPHome (have some Wemos D1 mini with ESPHome as remote sensors and hoping to convert my Sonoff Basic to ESPHome, too).
I am trying this python script but fail to provide the needed JSON to Python Dict transformation. In my setup the “payload” is always transfered as string to the python script:
My automation:
- id: 'rf_demux'
alias: demux result
description: 'decode the RF Bridfe /result messages'
trigger:
- platform: mqtt
topic: sonoff/stat/RESULT
action:
- service: python_script.demux_result
data_template:
payload: '{{ trigger.payload_json }}'
Because m is a string in the python script any operation with dictionaries fails:
m= data.get('payload')
for k in m.keys():
logger.info("Received keys = %s", k)
All parameter values are passed as strings. Normally the solution would be to convert the string using python’s json.loads but that is unavailable in python_script. To make it available, you would need to import json but python_script does not allow importing modules.
Someone else encountered the same hurdle and there was no solution to convert the string to a dict:
Thanks for this negative answer which at least saves me hours of useless efforts… actually I would have tried exactly that. 
With Python scripts its even worse: you cannot do simple slicing like a[:4]. It appears to be a naked installation without even the basic modules. I am surprised as one argument for me to try HomeAssisstant was the underlying Python framework.
Interesting though: when I trigger my python script service from the developer tools my script indeed receives a proper dict tested with some dummy json. Its only from the automation trigger where the template ‘’{{trigger.payload_json}}’ is transferred as string.
Thank you for sharing this. I like the second method a lot. I cleaned up the Python script a bit and thought I’d share with you all:
entities = {
'5AE488': ['sonoff_remote_btn_1', 'ON', 'false'],
'5A848C': ['sonoff_remote_btn_2', 'ON', 'false'],
}
payload = data.get('payload')
if payload in entities:
try:
topic, state, retain = entities[payload]
except ValueError:
topic = 'unknown'
state = payload
retain = 'false'
logger.warning(
'<rfbridge_demux> Received invalid RF command: {0}'.format(payload)
)
service_data = {
'topic': 'home/{0}'.format(topic),
'payload': '{0}'.format(state),
'qos': 0,
'retain': '{0}'.format(retain),
}
hass.services.call('mqtt', 'publish', service_data, False)
# Remove these last lines if you don't want to fill your log everytime your
# bridge catches a signal that you're not working with.
else:
logger.warning(
'<rfbridge_demux> Received unregistered RF command: {0}'.format(payload)
)
One of these days I’m actually going to get round to changing to use this Python script rather than ‘strategy 1’ which I use now.
Is it possible to have the Python script write unknown codes to file of my choosing rather than the HA log?
Didn’t you ask this same question about 3 weeks ago? I answered it in post #114, showing how to modify the python_script to use the File Notification sensor you’ve already created to store unknown codes to a file.
1 Like
Embarrassingly, almost.
I asked how to log only if a boolean was on but you also provided a way to write to a file.
Doubly embarrassingly I even have the amended script ready to use in my python_scripts folder for when I make the change.
Sorry, and thanks.
I’m using the original script in node red. What does this one do different? I tried pasting this one and got a bunch of errors in node red.
It’s really not that different from the original one, except that it will log events with payloads that are not registered in entities dictionary. Are those the errors you’re seeing?
The script I shared is just a bit cleaner and “pythonic”, but at the end of the day it’ll do the same.
Hi Guys,
THIS IS A WARNING MESSAGE for anyone wanting to play with ESPHome on RF Bridge.
I was tempted by you. I spent two days reconfiguring my RF Bridges:
First, I used Demux script with my Tasmota based bridge - it works great thanks for this thread…
but later…
I was tempted to run ESPHome on my second RF Bridge - I wanted better response and range as suggested.
- I did hardware hack to RF Bridge (it’s easy - the most difficult task is to solder a wire to tiny leg no. 10 of the chip (Hint: I managed to do properly is by covering/securing the other legs with duct-tape)
- I flashed device with ESPHome 1.14.3 with single door sensor (sending on/off signals so two binary sensors are needed in ESPHome YAML for the single sensor). Worked brilliantly and much faster than TASMOTA.
- I managed to teach the ESPHome to send/transmit quite complicated RF signal for my HomeCinema Screen - required RAW code dump from the other bridge (the one with Tasmota and Portish firmeware), but EPSHome RF Bridge worked like charm!
- I managed to do single(!) clean-and-nice automation that will translate every sensor defined in ESP Home to related MQTT signal - without any need for change to automation if you add or remove some sensors from ESPHome. (I can share it you want)
Then… I added all my door/window sensors and RF buttons/remotes (24 binary sensors in total) and… landed into the problem:
This is ESPHome issue. Home Assistant disconnects repeatably from RF Bridge making it unusable. It happens when you have around 10 sensors defined (or more) - the sensors exposed by ESP Home are blinking from unavailable to available, the log is full of “connect” and “disconnect” events on both sides.
Warning: This issue definitely repeatable if you define many sensors (~10+) in ESPHome on Sonoff RF Bridge.
Summarizing, for now, I stay with Tasmota flashed Bridge (with Portish firmware) and Demux solution. it’s great anyway. I’m going to monitor the status of bug/fix on EPSHome page in the meantime.
5 Likes
thanks for the warning.
my ESPHome node disconnects quite often but I thought it’s a connectivity issue. need to check it using another esphome device to make more definitive conclusion.
This is definitely not due to connectivity issues, but ESPHome API issues. The ESP device stays online (accessible from another computer via ESPPortal), but it HA connects and disconnects immediately. Then HA re-tries connection again after some period of time and again connecting and disconnecting immediately.
I guess… just after connection large number of binary_sensors on ESP side is trying to send their current state to HA via API and some breaking “conflict” emerges causing HA to disconnect. It can be seen in HA log that it sees corrupted API responses. I can see if the number of sensors is lower (below 10) the problem disappears. It looks like multi-thread synchronization problem or something (random), which is more likely to happen if larger number threads are concurrently running (bigger probability of conflict if many competing resources are doing their job)
Anyway… I’ll stay for some time with Tasmota and Demux strategy. I’ll give aother try to ESPHome version when fix is provided.
I received a Sonoff RF Bridge yesterday, flashed it and began playing around with a couple of buttons. I ended up writing a little Appdaemon script to handle automatically creating all the sensors and updating them. I came across this topic which covers similar approaches so I figured if anyone here is using Appdaemon, this may be a viable approach for you too.
It’s set up to allow for momentary buttons and other generic binary_sensors like motion sensors and contact sensors. It currently doesn’t retain the states of those sensors, but that would be an easy feature to add.
Anyway, it’s available here : https://github.com/rando-calrissian/rf2mqtt
1 Like
with what?
Latest Tasmota.