I wasn’t saying that the sonoff used RCSwitch from the factory.
He was saying to load different firmware onto it (tasmota). I was explaining I would not really gain any functionality if I did that over using your gateway.
Now, I may be able to use my remotes with the sonoff factory software but then I think would lose the self comtained functionality that I want from my home automation. I don’t want to have to rely on the cloud.
Unless the factory sonoff doesn’t work that way and I misunderstand the way it works.
But a non-hacked sonoff switch needs the could ewelink app to work. so i assume the bridge would as well.
Bridge with tasmota doesn’t require an Internet connection. It doesn’t use the ewelink app at all. I’ve flashed 3 sonoff device (including the bridge) with tasmota software and I can now delete the ewelink app as they don’t use that anymore.
I know it doesn’t use it if you flash another firmware on it.
But if you flash another firmware then I think i’ll lose the functionality of it being able to read my remotes. especially if it uses the RCSwitch library to setup the remotes. And honestly i don’t even know if it will read the remotes with the factory firmware either, for that matter.
Do you know if that is the way tasmota reads remotes?
Some inputs
The sonoff rf bridge is composed of two microcontrollers :
1)one esp8285 for wifi/connectivity management
2)one microcontroller for RF decoding and signal emission, 2 communicate to one by setial connection
1 can be flashed with stock firmware, espurna tasmota or openmqttgateway but it will not change the supported protocols, as they are handled by 2.
2 doesn’t have a custom firmware developped in my knowledge.
At final Rcswitch is not used in sonoff rf bridge for the moment.
If your remote is supported by one of the firmware and not supported by others it could be implemented by others. If the stock firmware doesn’t see your remote i m afraid you will have to go another way or wait for someone to hack 2…
I may still have to go that way but I’ve got some other stuff I’m going to give a try before that.
I think i’m coming to the realization I’m spending way too much time and money just to get 2 or 3 remotes to show the proper status in HA. I’m not sure if it’s worth it or not. But for now I will try to utilize the stuff I’ve bought so as not to just throw the money away. I wish I knew that about the sonoff bridge before I invested in all the other stuff I did.
Like I’ve said before…I’m shocked that this has been so difficult to work out. It’s not like I’m using some kind of exotic remotes that are rare to find. The fan & remotes are made by one of the main manufacturers in the US and sold by every big box store that i know of here.
I now finaly got everything working… I flashed the ESP8266 with the RC switch and PubSub client library, connected the rec-pin of the simple 433 Mhz RC receiver to pin 12 of the esp8266 and this esp does sent a MQTT message to home assistant depending in the code he got from the wireless door senor. No bridge, no node mcu needed……compiled with arduino IDE
@jeremyowens Thank you so much for your postings 31 and following with clear indications. I will proceed shortly and follow your advice. There’s just this doubt presently: the EV1527 door sensor I am using seems to broadcast signal only on door open. However, your postings show pilight protocol ev1527 and control both open and close status. I wonder how could this be achieved? Maybe there are EV1527 door sensors that send open/close signals? I have read about door sensors sending open/close signals, but they are based on a different chip STC15W10x.
Please, kindly some clarification in regards to my doubt. I think it may be of help to other community users.
There are EV1527 sensors that send both open/closed signals, and some that only send when opened. Also, there are some, like mine, that send one code for open, another for closed, and yet a third for tamper/battery. The creator of the sensor would be the one that could tell you what code(s) the device sends (or doesn’t send).
I see. So, that’s it. My exposure to EV1527 sensors is limited to those that only send one code for open. I am greatly surprised to hear about that possibility for such sensors. Would you mind sharing the ones you’re using? I would certainly like to try those. Since my install is relying on 433MHz sensors, those would certainly be a very nice addition.
My advice would be to not buy ev1527 sensors , most other sensors give you on/off on the same ID which is much better imho. (I have 4 and will never buy any others )
See my posts in the other topic. D026 mentioned in the link to the Chinese store is the best option for 433mhz open door sensors and can be used with any of the 433mhz project implementation (Pilight, OpenMQTT, RFLink, etc). D026 is a product not a manufacturer brand (there are sensors from Kerui, Fuers, Secrui but they’re all the same and usually wholesale packaging comes without any manufacturer branding at all).
It sends four codes (open/close/tamper/low battery) and can be painted to match the color of the door/window so that it blends in the environment without issues on the range.
Generally speaking, there are two main disadvantages of D026 vs. the more high class Zigbee/Z-wave open door sensors:
security (this is inherent to most of 433mhz devices, as they send the codes without any encryption; although neither Zxxs are 100% secure, they’re better than no security at all); in most of the cases this would not represent an issue by itself (although an attacker would basically know when a door/window is closed and if there is movement in the house recorded by PIR sensors, he needs to be relatively close to the sensor - that is 15-20 m in usual house environment).
battery life (for doors that are being opened more than 10 times per day like the main entry doors battery on the D026 it’s not going to last more than 2-3 months; however, as it sends also low battery code it will plenty of warning in advance).
In regard of the security there might be some deterrent after all, as Home Assistant can be used to send fake noise on the 433mhz band (either simultaneous with the real device triggering or at specified times/random times during the day) so that it would take a significant amount of time for someone to identify real devices from fake ones. OpenMQTT for instance can also be used to emulate completely random 433mhz device codes. The absence of security would be a major security problem in the case of using 433mhz key fob remotes to arm and disarm house alarm, which most low cost 433mhz alarm systems implement; however, in most cases, for lightning and other smart home usage, 433mhz devices like sensor (open doors/windows, PIR, water leak, smoke) and wireless switches (wall mounted or handheld) should be fine.
After learning so many useful tips from this thread, I put together a few script to have all the 433MHz codes received by the raspberry Pi sent to an MQTT broker and usable in Home Assistant.
It’s like the MQTT gateway but without the need for an Arduino.
I use it to control the volume of my Chromecasts via 433 Mhz remotes
It uses mosquitto docker container. You need docker and a recent Raspbian
well, that’s great and stuff but I’m happy with my Wemos D1 mini running OMG - it’s small, doesn’t require any special PSU and it works very well. RPi3 is running my HA
Guys I have many motion sensors, which I would like to use apart from an easy to get RF codes for wall switches, so is it possible to use those motion sensors with hassio or still need walkarounds?
, most other sensors give you on/off on the same ID which is much better imho. (I have 4 and will never buy any others 
)