Tuya to Tasmota Garage Door Opener Sensor

Third party integrations
#1

Hello All,
I recently flashed my garage door opener with TuyaConvert. Works awesome for open and close… but I cannot figure out how to pair the wireless door sensor it came with for the life of me.
In Tuya you hit pair sensor, but as Tasmota users know, that’s not quite an option.
I have temporarily made a template in HA with a secondary door sensor to link the status together. Does anyone know how I can get it to pair or to know the status on the Tasmota side where it already knows the status so that I can use the sensor it came with and put my other sensor back where it goes?

Link to device https://www.amazon.com/dp/B072SFDKDH/ref=cm_sw_r_cp_apa_i_JTk.FbXE25YQT
Thanks in advance! Happy New Year all!

#2

I am going to bump this up as I am interested in exactly this on this exact Tuya Garage Door Opener as well. Have technical abilities and can help reverse engineer if needed with guidance. If Esphome is a better platform for this device rather than Tasmota, that would be fine as well.

1 Like
#3

Thanks for the bump!
Fun side project while we wait: WiFi/MQTT car presence sensor for garage door automation
I’m temporarily using a third party zigbee sensor instead of the stock one until a solution is found so I know the status, but when I pull into the driveway or turn on the car (ULEV) it opens “automagically” and when I leave or turn off the car it closes. No button. No voice. True automation.

2 Likes
#4

That is interesting, I’ll take a look at it. One of the household cars (a bimmer) has HA official integration that has a form of location/presence built-in, but it’s not particularly real-time, so doesn’t work well for automations to be triggered by its “presence” … so this is an interesting and more general approach.

To our problem: to get reverse engineering started, maybe I’ll buy an extra device (as I don’t want to interrupt the operations of current doors), open it up, and see if I can figure if there is a board signal that bounces when the remote door sensor trips on or off. But there is a good chance that doesn’t exist and the trip signal is actually incorporated in the data stream (I am guessing it’s 433MHz between sensor and opener), which would probably move the hacking to the complexity of software/protocol domain …

Which Zigbee sensor did you use as a workaround? The “standard” Aqara mini door/window sensor or something else? I am going to try to do that with the Aqara vibration sensor as it does seem to have accelerometer raw data available and accessible in the z2m integration and so should give me a raw tilt angle to use for position.

#5

Definitely use something with the vibration sensor if you have it available. I have a smartthings sensor that I use.
Some of what I have researched about tasmota ir blasters should apply here, but I’m too new to know how to do it, but the ir blaster has the capability of “listening” for the remote signal with the proper command. If it is anything like that, then after entering proper command (unknown) it should just simply be close the sensor, record the data, open the sensor, record again, but I could be way off. Only thing would be how to make it listen.

#6

So I got a new one in. A few pre-opening observations:

  • looks the same as my two original installed units from the outside, but doesn’t have the dangling external antenna; I am now worried that my two original ones and this new one are not based on the same networking/wifi module; this may increase reverse engineering effort to handle two variants
  • interestingly, there is no way to place this new device into the Tuya EZ Mode and it only ever works in AP Mode; I believe my original ones did work in EZ Mode (and only EZ Mode, since I remember what a royal pain it was to pair them on a mixed 2.4GHz/5GHz SSID); so the new one has no possibility for Tuya Convert OTA; this is another hint that there are at least two variants in the wild

Opening it up, preliminary observations on this “new one”:

  • communication with the contact sensor is clearly 433.92MHz-based as it has a 13.52127MHz oscillator onboard as well as a very pretty 433MHz-looking wound antenna
  • networking module is the famous TYWE3S which means it should be Tasmotizable; interestingly, only a few module pins are soldered to the board with the rest carefully isolated on the PCB (this may help with an hack/shortcut idea below)
  • there is an additional microcontroller (MCU) onboard, a 1T 8051 derivative (Nuvoton MS51FB9AE)
  • the two LEDs on the board both go to the 8051 MCU pins through current limiting resistors, including the green one that blinks whenever it receives a connect or disconnect from the contact sensor
  • the Rx/Tx signals from TYWE3S are also connected to the MCU
  • I think all of above means that it’s Tasmotizable and can use TinyMCU to deal with the 8051 protocol that likely contains the contact sensor communications

Shortcut hack idea:

  • since we’re probably soldering flashing wires anyway, it might be possible to run a wire from the MCU green LED driver pin (can pick it up on the resistor) to one of the non-soldered TYWE3S pins that is a GPIOx and just use that as the contact sensor trigger rather that try to reverse engineer the 8051 protocol

Anyway, I am actually not sure it’s worth proceeding because I now think there are two different designs of this product out there. I guess I have to open up one of my existing ones to have a quick look, but I don’t really feel like completely unwiring it from the garage.

#7

I know the feeling. I’m to the point that I do like knowing if the garage is moving anyway so my Smartthings sensor is actually probably a better idea.
Out of curiosity, what does your cover template look like? Did you include tilt? I’m having a hell of a time figuring it out lol.