433 relay challenge

[ade]

Well, it's a challenge for me anyway!

Scenario is that I have gates which trigger via a basic (and old) 433Mhz keyfob. For years now I've been running a Rpi Zero and sending (via sendiq, which I found from the RPiTX project here https://github.com/F5OEO/rpitx) a capture of the code from the remote so that I can open the gate using Python, i.e. Rpi can be used to send the 433 code to the gates via a Python script, allowing programmatic operation. This means I can do stuff like trigger the gate from my phone when out, etc.

So far, so good. Now, however, I need a way of running a button on the inside of the gate to send the same signal, so the gates can be opened from inside - long story involving a climbing postman. The option of having the pro gate installer putting a second key panel on the inside is costly, so I have been trying to make it work in a DIY fashion. Currently I've rigged a wifi button (https://mystrom.ch/wifi-button/) which triggers an IFTTT webhook, which in turn tells the Pi to run the Python to send the 433 to open the gate. 

Hopefully still with me. 

If not, there's a full write up here from the time I did it.

Problem with the wi-fi button is it takes around 10 seconds after the press for the button to wake up, join the wifi network and trigger the command to run the python to open the gate..also the Mystrom button is in a rigged water resistant housing on the gate post which doesn't look like it's going to last.

I CANNOT find an outside, learning 433Mhz button or all this would be done and dusted.

So, next option (unless anyone knows of a suitable button) - I could use a generic (non-learning, fixed code TX 433 Mhz code panel for outdoor use like this one, listen for it's code when it gets activated, then run the python to transmit the gate code.

So I'd need to listen for the code from the panel, trigger the python to open the gate when it's received, then keep on listening.

Hopefully you see my challenge..

Any and all ideas from the lovely community very gratefully recieved.

Thanks.

Ade 

[Greg Troxel]

I did not 100% follow, but if you can run power to where you want the
button, esphome is pretty easy to deal with and can do mqtt.

There are probably also buttons that just send something rtl_433 can
decode, or you could make one with a non-ESP microcontroller and a
RFM69, which could have low enough sleep current to work on battery.
See Low Power Labs.

[ade]

Thanks for the response - I appreciate it. I will try to clarify, as I realise from your comments that I missed some salient points.

Short challenge statement is: I need to listen for one 433mhz code and use it's presence when detected to trigger the transmission of a different 433Mhz code.

I can't get power to the outdoor button, so it needs to be battery powered (the current wi-fi button is rechargeable).

I can find suitable outdoor 433mhz buttons and keypads but they all come with a pre-determined TX code. I need one which will learn the gate code from an existing transmitter (like programmable key fobs) - and it's that which I just can't find to buy anywhere - an outdoor 433mhz button or keypad which can learn from / clone an existing remote (in this case one of the gate remotes).

So, my alternative idea was to buy one of the outdoor suitable buttons with a fixed code, listen for that code being tx'd on the pi, then re-transmit the correct code to open the gate (the function already running on the Pi with no problems), which I'm also struggling to make work reliably (I think a memory consumption problem with a continual loop listening for the code from the outdoor button on the Pi is making it flaky). I'll probably move on to using an Arduino or RP2040 to do the listening, if I can work that out, then use it to raise a pin on the Pi GPIO (via a little patch cable between the two) once it detects the code from the new, fixed, outdoor button or keypad. I can then use some Python on the Pi to check periodically for the GPIO pin being pulled up and then trigger the 433 gate transmit code from the Pi to open the gate, as usual.

The Pi, in this case, is effectively acting as a gateway.

I'm running Home Assistant, and have mqtt pub/sub running for other stuff, and could perhaps solve the RPi resource problem by moving continual listening loops to a pub/sub somehow - thanks for raising that idea :-) I'll need to give that some thought but It doesn't solve the problem entirely.

Essentially if I can find a programmable outdoor 433mhz button or keypad all of this goes away... :-)

Thanks again,

[Christian Z.]

Not sure if it helps, but it might clarify things:

rtl_433 can listen to any doorbell-style sender easily. It's mostly a EV1527 signal, a fixed code of 24 bits and 1 sync bit. There are examples in the conf folder.

Basically grab the signal, analyze it, write (or modify) a flex decoder conf file.

There is even an output module to toggle a RPi pin available in rtl_433 already:

  `-F trigger` puts a `1` to the given file, can be used to e.g. on a Raspberyy Pi flash the LED.

Also you might want to offload the sending to some hardware module like the CC1101 or similar -- but that requires some soldering and code to set things up.

Another idea: if the new button you'll get is a package with some receiver (a gong usually): perhaps hack that receiver as binary input to the RPi?

[ade]

Thanks very much Christian.

Totally follow about capture and replay - that's how I'm opening the gate with the Pi now (I captured the original gate remote and replay the tx using the Pi GPIO Pin method with a small cable as an antenna). Problem is the continuous listening for the outdoor button (different fixed 433 code) so I can use it to trigger the Pi to tx the existing 433 code to open the gate. I'm now investigating whether the gate controller can be programmed to listen to more than one code, which it may be able to (it's very old). If it can then problem solved - I can code the outside button to the gate controller directly. I'll update if that works...

Thanks again

Ade 

[Christian Z.]

I need to say, Pi GPIO pin with a short cable is a terrible thing. Very inaccurate, noisy, and might take too much spectrum. Use at least one of those ultra cheap 1-bit senders (sold in pairs with a Superheterodyne receiver).

[ade]

Yeah I have a little FS1000A board waiting to go - as with everything else I just need to find a couple of hrs to sort it out. You know how "prototypes" end up as permanent solutions? I'll get to it this weekend I reckon, you're right, needs sorting. Luckily I'm in the middle of nowhere.

Ade