Support for security +1.0 GDO

[vaidehi-joshi]

Following up on this in a new issue since we are using the D1 Mini now.

To summarize,

1. We are using the D1Mini ESP8266MOD
2. We have a security 1+ GDO (purple learn button)
3. We are using 2x 2n7000n Transistors
4. Obstruction sensor is working
5. We used native ratgdo and flashed ratgdo v2.26, Security + 2.0 (secplus 1.0 alpha)
6. Logs show Wall panel detected and when I try to open the door, it says Door is not moving

Any help greatly appreciated! 😞

[sanjay900]

Are there any more logs than that? I presume this is after setting the control protocol to security 1+ correct?

[Kaldek]

Unfortunately I haven't looked into what the code tries to do for these types of openers. What I recommend is done is a review of the C++ code for these openers to see what the TX GPIO tries to do when a door toggle is pressed. Once it's clear what the code is trying to do, I would use a two-channel oscilloscope monitoring the GPIO pin (MOSFET gate pin), and the drain of the MOSFET (red wire).

The GPIO pin should be LOW unless commanded, and the drain of the MOSFET should be HIGH unless commanded. The two channels should be monitored during testing, triggering probably on the rise of the GPIO pin.

[sanjay900]

Reading the code it does seem like it is just using it as a serial line, much like security+ 2.0

[Kaldek]

Reading the code it does seem like it is just using it as a serial line, much like security+ 2.0

Hmmm, in that case I would definitely bust out the oscilloscope.

[sanjay900]

One thing i did note is that it is at a lower baud rate. @vaidehi-joshi Does the door move if you try to open and close it from mqtt? and do you get updates if you open the door via other means, or is both receiving and transmitting broken?

[Kaldek]

One thing i did note is that it is at a lower baud rate.

Just in case anyone is concerned by that, a lower baud rate would - if anything - be helpful as the switching speeds of the MOSFET are lower. As speeds increase, switch timing becomes important, and then critical. For lower baud rates, there's more "wiggle room".

[rohinrohin]

One thing i did note is that it is at a lower baud rate.

@vaidehi-joshi Does the door move if you try to open and close it from mqtt?

and do you get updates if you open the door via other means, or is both receiving and transmitting broken?

door doesn't move if we try to open/close from MQTT. The only thing that works is the obstruction sensor. Both RX and TX is brocken.

Is there any other combination of ESPs (32/8266/..) has been tested for a Security 1+ device?

And @Kaldek - we unfortunately do not have an oscilloscope. Could buy one if you have a good affordable recommendation.

[Kaldek]

And @Kaldek - we unfortunately do not have an oscilloscope. Could buy one if you have a good affordable recommendation.

Hantek 2D72 - cheap, portable, dual channel and is also a multimeter.

[sanjay900]

One thing i did note is that it is at a lower baud rate. @vaidehi-joshi Does the door move if you try to open and close it from mqtt? and do you get updates if you open the door via other means, or is both receiving and transmitting broken?

door doesn't move if we try to open/close from MQTT. The only thing that works is the obstruction sensor. Both RX and TX is brocken.

Is there any other combination of ESPs (32/8266/..) has been tested for a Security 1+ device?

And @Kaldek - we unfortunately do not have an oscilloscope. Could buy one if you have a good affordable recommendation.

Also what wiring schematic did you follow?

[tronikos]

Does it work in emulation mode without the wall panel? You will see in the logs "No wall panel detected. Switching to emulation mode."

Which wall panel do you have? Apparently it doesn't work with 78LM and maybe others and this is the reason there is no ESPHome port yet for security+ 1.0. See https://github.com/ratgdo/esphome-ratgdo/issues/70 and https://github.com/PaulWieland/ratgdo/issues/101.

Can you rename the issue? The use of D1 mini has nothing to do with this issue. It's the security+ 1.0 that is not supported well yet.

I also have security+ 1.0 and I'm waiting for this to be resolved before I order the transistors just in case we need different ones to make it work.

[tronikos]

What's the reason you used v2.26 which is meant for v2 boards instead of the latest v2.51 which is meant for v2.5 boards? The schematics in this repo are based on v2.5. The TX pin changed between the 2 board revisions (from D4 to D1). So make sure you use the correct firmware and the correct pins.

[Kaldek]

What's the reason you used v2.26 which is meant for v2 boards instead of the latest v2.51 which is meant for v2.5 boards? The schematics in this repo are based on v2.5. The TX pin changed between the 2 board revisions (from D4 to D1). So make sure you use the correct firmware and the correct pins.

2.51 wasn't available last week. It must have been added in the last day or so! @rohinrohin do you want to try that as your basis for testing going forward?

[rohinrohin]

Will do a quick test with this firmware today. Thanks!

Just to clarify, I shall use the exact same pin out as in the schematic here and flash the latest firmware right? Ratgdo v2.51

[pizzaboy192]

Is there a 2.51 ESPhome firmware? the lastest I can flash is 2.50 which lacks the option to set it into security 1 mode.

[rohinrohin]

Is there a 2.51 ESPhome firmware? the lastest I can flash is 2.50 which lacks the option to set it into security 1 mode.

No I think ESPHome still doesn't support Security 1+, this is native ratgdo.

[pizzaboy192]

No I think ESPHome still doesn't support Security 1+, this is native ratgdo.

Thanks! I have my ratratgdo running the 2.51 Security+1.0 firmware, on power up it will trigger a door open or close event but then fail to respond. It was cold and late last night when I wired it up so I'll investigate today or tonight what I may have done wrong.

[rlowens]

Is there a 2.51 ESPhome firmware?

Technically, the ESPhome firmware is really just versioned by the date of compilation. The latest update on the esphome-ratgdo firmware was 16 hours ago (adding a timeout for Security+ 2.0 motion detectors so they can trigger more often than the light turning off). https://github.com/ratgdo/esphome-ratgdo

the lastest I can flash is 2.50 which lacks the option to set it into security 1 mode.

No, the "2.50" you are referring to here is ratgdo HARDWARE version 2.5, not firmware version. There is no version number for the esphome-ratgdo firmware as far as I can tell, just compile date.

No I think ESPHome still doesn't support Security 1+, this is native ratgdo.

You are correct that esphome-ratgdo doesn't support Sercurity+ 1.0 yet (they are still ironing out the Security+ 1.0 support before adding it). And since it was split out as a separate project the correct name is "mqtt-ratgdo" https://github.com/ratgdo/mqtt-ratgdo

There is also the (in-process) https://github.com/ratgdo/homekit-ratgdo firmware.

[pizzaboy192]

Turns out, just like there's some weird combinations of "Security 2.0" openers where the door pads are controlled by 1.0, my "Security +" opener uses Security+ for RF communication, but accepts dry contact input on the opener itself. Good job Liftmaster.

[sanjay900]

Turns out, just like there's some weird combinations of "Security 2.0" openers where the door pads are controlled by 1.0, my "Security +" opener uses Security+ for RF communication, but accepts dry contact input on the opener itself. Good job Liftmaster.

There are security 2+ openers that have a serial line and a dry contact line, the serial line you connect ratgdo to ends up being green on those units, and the dry contact line is just that, it's simply just dry contact

[Kaldek]

@vaidehi-joshi any updates on your progress here?

[godmar]

I too have a purple learning button and (I believe) an LM78 wall button. I was going to wire up rat-ratgdo and try this, but what I read in these threads concerns me a little bit (though time permitting over the holidays, perhaps I'll try to help. And I do have an oscilloscope I could put to use ;-)).

My questions include:

• what is emulation mode?
• what is the significance of the wall terminal? Does ratgdo somehow need to sniff traffic between the opener and panel? I will say that I won't start the project if there's a risk of losing the ability to open the garage door with the wall panel.
• how do "dumb" panel like the LM78 actually work? They seem to be able to reliably switch the garage door from what I can see. (and related, why don't we just tap into them and side-step the whole security protocol)
• what is the significance of the choice of MOSFET? There seem to be two different schematics, some with 2n7000n and some where one of the transistors is replaced by a AO3400A, and I think I found one post where an entirely different type was discussed.
• even in Wieland's version of hardware+software support for 1.0 seems to be partial (not supported for ESPhome, partially supported for the MQTT version). The way I understand it, MQTT is the messaging protocol from the MCU to a server, whereas the difficulties with the Security+ 1.0 protocol results from understanding the signal level protocol, which should be the same for the ESP Home/Home Assistant version. Perhaps it's just a matter of porting it.

[sanjay900]

Yeah, he plans on porting it once the support is fully working for the mqtt version, since there are still a few cases where it isn't working yet

[Kaldek]

My questions include:

Most of these questions are valid for Paul Wieland but not this repo. The only question I can provide any response to is about the choice of MOSFET, and it relies on the historical context of this repo.

We had no boards to test with, only images. Paul Wieland refuses to provide the schematic, so we had to reverse engineer what we could. We worked out after a couple of days that the part marked "XOYL" is an AO3400A MOSFET. I personally had no access to any N-channel MOSFETs other than some 2n7000 units (since they are so common). I tried it, and it worked, so I had some basic Fritzing-based diagrams using the 2n7000.

And that's when the community entered the fray, which caused us to constantly update and change recommendations, and then change them back again after debate, or discovery that the recommendations don't work at all. It leads to lag in the documentation, or sometimes I forget that there is a reference to the older recommended part. It's made worse by the fact that some of the folks who come here just want to knock up a home made through-hole prototype and be done with it, whereas other folks are keen to generate schematics and gerber files for SMD based board designs.

I'm pressed for time, so if anyone wants to do an attempt at complete tidy-up of the structure of the repo regarding an area for through-hole enthusiasts and a separate one for SMD enthusiasts, I'll happily act as the reviewer of a Pull Request and merge it as long as it's not insane or dismissive of differing opinions on preferred board design.

[sonapsent]

I set up the basic ESP8266 board with 2n7000 MOSFETs on a security +1.0 (purple) craftsman opener and it is working fine using the standard MQTT version of RATGDO. Paul has a compatibility chart on his web site that mentions on note 4 that there are two methods to detect door status on sec1.0, I happen to be using the 888LM wall panel which is needed for the first method.

[Kaldek]

Closing due to issue not related to this repo, and lack of updates.