Security 1.0+ wall button issues

[lukescott]

I have two Ratgdo's with two identical openers. They operate normally for the most part with a few exceptions. I have the purple learn button. I specifically have this board.

Issue 1, related to: https://github.com/PaulWieland/ratgdo/issues/240 (I can't add to this issue as issues on this repo in general are locked to contributors)

If I power cycle the Ratgdo the green LED on the button is solid. I believe at this point the "Light" button works as well. As soon as I open/close the garage door, the green LED flickers. At this point the "Light" button seemingly does not respond.

However I've noticed that if I interacted with the "Light" button at any point, after 60 seconds or so the light turns on, and will stay on, and keep turning itself on. Meaning if I turn it off with mqtt/HomeAssistant, the light will turn itself back on and stay on. The only way to keep the light off and have normal functionality is the power cycle the Ratgdo (where light turns itself off ~5 min after turning on when door opens/closes).

Even with the green LED flickering, the light behaves normally as long as I don't interact with the "Light" button.

Both openers are wired the same and I made sure to match the wiring diagram. I'm using older USB-A Apple iPhone charging bricks (the small ones).

Issue 2,

I periodically get random opened/closed status after several hours, very close together so I only noticed it because I got a HomeKit notification on my phone.

[PaulWieland]

Which wall panel do you have?

[lukescott]

They look like this:

The second one is functional, just the LED seems to be burned out. The first one normally has a solid green LED, but flickers after the door is opened/closed w/ the Ratgo powered on. Unplugging Ratgdo makes the light solid again.

[PaulWieland]

These wall panels are "dumb" in that they don't query or receive information. They only send commands. the light flickering is normal because ratgdo is polling the GDO on the serial line and that traffic causes the light to flicker.

This is all a consequence of the emulation mode ratgdo uses to get full bi directional communication with sec+ 1.0 openers. The same thing would happen if you hooked up an 889LM in parallel with this older style panel.

[lukescott]

@PaulWieland Do you know why the Light button would not work, or why the light will not turn off if someone presses the button? Is there an alternative wall panel I can get with the opener I have that works better?

[PaulWieland]

The dumb panel is sending an analog signal that will be ignored by the GDO if it is in digital/serial communication mode.

ratgdo should be able to control the light and lock functions. The 889LM will also do the job.

[lukescott]

@PaulWieland Ah gotcha. Any benefits in getting a 889LM? Other than motion sensing for light? With Ratgdo in emulation mode, can I completely disconnect the old dummy switch?

With the dry contact terminals, how would that work as a toggle with having separate open/close? Do I wire both open/close together?

[ngrusz1]

I know this issue has been closed, but I would like to echo a few additional bugs that were identified here and in https://github.com/PaulWieland/ratgdo/issues/240. I have a Liftmaster model 2265-267 gdo (it has a red learning button), and I have the same wall buttons pictured above. While the LED flickering is a little annoying, I don't have any real issues with it. However, I am also experiencing the issues noted below, which are more worrisome:

• The "light" button on the wall control does not work at all (it seemed to work intermittently at first, but not anymore, perhaps related to power cycling the ratgdo as noted by @lukescott ).
• The light on the gdo will turn itself on and will be unresponsive to the light button on the wall control. It will respond to commands via mqtt/HomeAssistant to turn off, but will immediately turn itself back on (again, as described above by @lukescott )
• I will get occasional random open/close messages even though, as far as I can tell, the door has not been activated. The timestamps on the messages are generally 1 second apart so it doesn't seem possible the door fully opened or closed within that time.
• Finally, and perhaps most importantly, I have noticed that with the ratgdo powered on, I will randomly lose the ability to use my traditional gdo remotes (similar to what is noted in https://github.com/PaulWieland/ratgdo/issues/240). That is, the Liftmaster button remote clipped to my car's sun visor will seemingly be unable to open or close the door, but mqtt/HomeAssistant will work fine. This is annoying for me, but 100% a dealbreaker for my wife :)

Are all of these issues related to emulation mode? Is this a bug, and perhaps something that could be fixed? Or can I replace my wall control with a new one that would resolve these issues (or to @lukescott 's point, does the LLM889 wall control work with Security+ 1.0)?

[lukescott]

@ngrusz1 The first two issues with the light are related to what @PaulWieland was describing. The panel is "dumb", meaning it works by bridging red and white together. I took apart the wall panel, and it looks like the Light and Lock function works the same way, but each has a different capacitor attached to it (so it sends a different voltage? I'm not an electrical engineer, so I'm guessing here).

From what I can gather emulation mode basically emulates a 889LM. Both the Ratgdo and the 889LM poll the garage door opener to get a status. @PaulWieland is that the correct assumption? (So yes the LLM889 does work, but the Ratgdo does everything the LLM889 can do. I disconnected my dumb panel and I can still control it with mqtt commands / HA).

What is happening with the "Light" button is as soon as you press it, it charges up the capacitor, and with the polling goes into a charge/discharge loop causing the light to turn on again. Again, this is an assumption. This is probably why the garage door does not just open/close by itself (it doesn't use a capacitor).

If you don't touch the Light button at all, it will stay off. You have to power cycle the Ratgdo to get it to stop polling and the panel will discharge.

@PaulWieland I understand that because you are polling on Red/White the dumb panel won't work properly. I know you suggested hooking up a door bell switch the the dry contacts. But I had another idea - Could you theoretically hook up the existing dumb panel to the dry contacts as well? With some code changes, could the dry contact read which button was pressed? (I'm guessing without any code changes all 3 buttons would cause the door to open). If this is a possibility, it could potentially fix the LED flickering issue as well since it would be on a different circuit.

I do get the occasional open/close messages as well, but it's after several hours. I'm also seeing "became unknown" and "became unavailable" messages, so it could just be because of that. I have to monitor it more.

[lukescott]

If it's possible to wire the dumb wall panel up directly to the Ratgdo, I can provide some detailed photos of the circuit and capacitors.

Here are the parts though:

Door Switch: No Capacitor LED: Resistor 1.6k Ohms 5% (Brown, Blue, Red, Gold) Light Switch: 1uF 50v (Leon; Orange) Lock Switch: 22uF 50v (Leon; Blue)

[ngrusz1]

@ngrusz1 The first two issues with the light are related to what @PaulWieland was describing. The panel is "dumb", meaning it works by bridging red and white together. I took apart the wall panel, and it looks like the Light and Lock function works the same way, but each has a different capacitor attached to it (so it sends a different voltage? I'm not an electrical engineer, so I'm guessing here).

From what I can gather emulation mode basically emulates a 889LM. Both the Ratgdo and the 889LM poll the garage door opener to get a status. @PaulWieland is that the correct assumption? (So yes the LLM889 does work, but the Ratgdo does everything the LLM889 can do. I disconnected my dumb panel and I can still control it with mqtt commands / HA).

What is happening with the "Light" button is as soon as you press it, it charges up the capacitor, and with the polling goes into a charge/discharge loop causing the light to turn on again. Again, this is an assumption. This is probably why the garage door does not just open/close by itself (it doesn't use a capacitor).

If you don't touch the Light button at all, it will stay off. You have to power cycle the Ratgdo to get it to stop polling and the panel will discharge.

This makes sense. If I were to replace my dumb wall control with an 889LM, I wonder if that would "fix" the issue with the light button not working -- either because the polling would no longer cause a problem, or because the ratgdo would not need to emulate an 889LM? The manual for the 889LM seems to imply that it should work with a Security+ 1.0 gdo (and that it is compatible with my model, the 2265).

Separately, however, do you suspect that any of this might be causing the issues with the standard wireless remotes? This is actually my larger concern. If I had to do without the light button on my wall control, and a little flickering of the wall control LED, that's ok. But the gdo randomly deciding to not respond to my regular remotes...that's a no-go.

[lukescott]

@ngrusz1 As far as I'm aware, the 1.0 style remotes signal is interpreted by the opener itself, not the wall panel. Do they work with the Ratgdo unplugged?

Perhaps the lock function is engaged. Unplug the Ratgdo, test the remote. If it doesn't work, press the lock button. Then test again. If it works, plug the Ratgo in and see if it works. If it does not, perhaps the opener is thinking the lock function is engaged? (Something to do with how the polling works?)

If the remotes do not work regardless of the Lock function, you might have to re-learn the remotes. I don't remember the exact procedure, but I think each time you go thru the process w/ the learn button it "forgets" all the remotes and you have to train it w/ each one right after the other with learning mode engaged (?).

If you get a 889LM you can get the 2.0 style remotes which are interpreted by the wall panel. I'm not sure if the 1.0 style remotes would work still. I imagine the 889LM would send the Lock signal to the opener as Chamberlain would consider the old style insecure. If Ratgdo is emulating the 889LM, it could be doing the same thing. Which if that's the case, you might have to open an issue for it?

I'm a bit weary in getting a 889LM just because some of the reviews I've read indicate it has at least in some instances opened the garage door on it's own randomly.

I personally don't use any of the remotes as I just open my garage door thru the HomeKit integration in Home Assistant. With an AppleTV I can open the garage door over the internet, and if I'm connected to local WiFI it works even if the internet is out. If I were to need a backup I would probably look into a Z-Wave/Zigbee remote. That's how much I distrust Chamberlain security (especially w/ myQ).

[ngrusz1]

Thanks for the suggestions!

@ngrusz1 As far as I'm aware, the 1.0 style remotes signal is interpreted by the opener itself, not the wall panel. Do they work with the Ratgdo unplugged?

Yes, the remotes seem to work fine (or at least, as well as they did before) when the ratgdo is unplugged. Since the issue only occurs intermittently, it's a little difficult to know exactly how often the problem happens, but I'll try to test a bit more.

Perhaps the lock function is engaged. Unplug the Ratgdo, test the remote. If it doesn't work, press the lock button. Then test again. If it works, plug the Ratgo in and see if it works. If it does not, perhaps the opener is thinking the lock function is engaged? (Something to do with how the polling works?)

This is an interesting theory, and seems reasonable given the manner in which the ratgdo polling can interfere with the wall control's light button. I'll try to test a few combinations of the lock button with the ratgdo. But now I wonder if the ratgdo polling can occasionally engage the lock button.

If the remotes do not work regardless of the Lock function, you might have to re-learn the remotes. I don't remember the exact procedure, but I think each time you go thru the process w/ the learn button it "forgets" all the remotes and you have to train it w/ each one right after the other with learning mode engaged (?).

I have the procedure somewhere. But as noted, unplugging the ratgdo appears to allow the remotes to work again without any re-learning necessary. If I recall correctly, the routine learning procedure simply adds another remote without changing any remotes that are currently known/linked. I believe there is another procedure that basically "clears" all known remotes, which would then require you to re-learn every remote individually.

If you get a 889LM you can get the 2.0 style remotes which are interpreted by the wall panel. I'm not sure if the 1.0 style remotes would work still. I imagine the 889LM would send the Lock signal to the opener as Chamberlain would consider the old style insecure.

That would definitely be a drawback to the 889LM, and something I could see Chamberlain doing. I would be happy to buy a relatively cheap 889LM if it would make my ratgdo work better, but if using the 889LM means I would also need to replace all of my 1.0 remotes with 2.0 remotes, that drives the cost up quite a bit. I will try to see if there's anyway to confirm the 889LM's behavior in this regard. > If Ratgdo is emulating the 889LM, it could be doing the same thing. Which if that's the case, you might have to open an issue for it? I really hope not, as this would presumably cause issues with anyone who wants to use a ratgdo with a 1.0 system. @PaulWieland , are you able to confirm if the 889LM emulation behaves this way? > I'm a bit weary in getting a 889LM just because some of the reviews I've read indicate it has at least in some instances opened the garage door on it's own randomly. also something to keep in my if I decide to get an 889LM, I suppose...

[ngrusz1]

I was able to do a little more testing and I'm becoming more convinced that there's something in the ratgdo that is triggering the lock feature in my gdo. When the ratgdo is disconnected (powered off) all of my traditional gdo remotes work fine. If I turn on the lock feature (via the wall control) the remotes will be locked out (pressing the buttons flashes the light but does not move the door). When I turn off the lock feature, the remotes will work again. I note that when the lock feature is turned on, the LED in the wall control flashes rapidly to indicate the lock is engaged.

When the ratgdo is connected (powered on and communication is established with wifi and my HA server), my traditional gdo remotes will work some of the time. I can still engage the lock feature via the wall control, but I note that 1) the rate at which the LED flashes is different, presumably because of both the polling from the ratgdo and the original flashing of lock feature itself, and 2) engaging and disengaging the lock feature would occasionally trigger a 'light on' or 'light off' message in my HA server, even though the physical state of the light did not appear to change. As previously described, at times my traditional gdo remotes will suddenly stop working -- pressing the door button on the remote does not work, regardless of distance or length of press. Pressing the button multiple times from different distances will eventually activate the door, but I think this is random. No messages are logged in my HA server during times where the remotes are not working; unfortunately I have not had an opportunity to connect my laptop to the ratgdo and wait for this issue to occur so I can see the actual device logs. I am also waiting for it to happen again to see if, when the issue occurs, the gdo light flashes in the same pattern as it does when the lock feature is engaged.

I can try to experiment a little more, but this intermittent issue occurs often enough that it does interfere with normal operation (we have encountered it more than once per day, whenever I have the ratgdo connected) as described in https://github.com/PaulWieland/ratgdo/issues/240. It seems plausible that the ratgdo's polling process (or the 889LM emulation process) is randomly engaging (and disengaging) the lock feature, which would prevent the remotes (and only the remotes) from working.

I am not sure if there are currently plans to investigate and/or correct this issue. I would be happy to open a new issue for this, but at the moment it looks like issue submission for the regular repo is disabled, and I'm not sure if I should open a new issue here (@PaulWieland please advise). Otherwise, this will probably be a dealbreaker for me.

[callitkarma67]

I was able to do a little more testing and I'm becoming more convinced that there's something in the ratgdo that is triggering the lock feature in my gdo. When the ratgdo is disconnected (powered off) all of my traditional gdo remotes work fine. If I turn on the lock feature (via the wall control) the remotes will be locked out (pressing the buttons flashes the light but does not move the door). When I turn off the lock feature, the remotes will work again. I note that when the lock feature is turned on, the LED in the wall control flashes rapidly to indicate the lock is engaged.

When the ratgdo is connected (powered on and communication is established with wifi and my HA server), my traditional gdo remotes will work some of the time. I can still engage the lock feature via the wall control, but I note that 1) the rate at which the LED flashes is different, presumably because of both the polling from the ratgdo and the original flashing of lock feature itself, and 2) engaging and disengaging the lock feature would occasionally trigger a 'light on' or 'light off' message in my HA server, even though the physical state of the light did not appear to change. As previously described, at times my traditional gdo remotes will suddenly stop working -- pressing the door button on the remote does not work, regardless of distance or length of press. Pressing the button multiple times from different distances will eventually activate the door, but I think this is random. No messages are logged in my HA server during times where the remotes are not working; unfortunately I have not had an opportunity to connect my laptop to the ratgdo and wait for this issue to occur so I can see the actual device logs. I am also waiting for it to happen again to see if, when the issue occurs, the gdo light flashes in the same pattern as it does when the lock feature is engaged.

I can try to experiment a little more, but this intermittent issue occurs often enough that it does interfere with normal operation (we have encountered it more than once per day, whenever I have the ratgdo connected) as described in https://github.com/PaulWieland/ratgdo/issues/240. It seems plausible that the ratgdo's polling process (or the 889LM emulation process) is randomly engaging (and disengaging) the lock feature, which would prevent the remotes (and only the remotes) from working.

I am not sure if there are currently plans to investigate and/or correct this issue. I would be happy to open a new issue for this, but at the moment it looks like issue submission for the regular repo is disabled, and I'm not sure if I should open a new issue here (@PaulWieland please advise). Otherwise, this will probably be a dealbreaker for me.

I think you are right about ratgdo doing something with the lock function. I found that I was able to control my light again using my "dumb" switch after hitting the lock button 1-3, but sometimes more than 3 times. I've also noticed that whenever I toggle the light on the wall switch, HA gets messages that the light turned on/off but also that the door opened/closed though it was just the light that was engaged. That might be a whole other issue though.

[ngrusz1]

I think you are right about ratgdo doing something with the lock function. I found that I was able to control my light again using my "dumb" switch after hitting the lock button 1-3, but sometimes more than 3 times. I've also noticed that whenever I toggle the light on the wall switch, HA gets messages that the light turned on/off but also that the door opened/closed though it was just the light that was engaged. That might be a whole other issue though.

It seems like there's more work needed for the Sec 1.0 emulation. Unfortunately I'm not sure if the developers are actively investigating this issue, although I have noticed an increase in related issues so perhaps they'll take a look soon.

[PaulWieland]

This is explained in the docs.

[joeshaw]

@PaulWieland Would polling the door status less frequently result in fewer wireless remote lockouts? The wireless remotes are currently too unreliable for me, and I would be willing to trade off timeliness of updates for better reliability.

[PaulWieland]

I'm going to issue a firmware update which will allow the "trigger open" terminal to be configured as a toggle instead of a trigger. You will then be able to wire the 78LM panel to the GND and Trigger Open terminals of ratgdo instead of the door opener itself.

Pressing the big white button will then tell ratgdo to to open or close the door via it's dry contact input. The lock and light buttons of the 78LM will not function, however ratgdo can already control the light and the lock control is coming soon.

[lukescott]

@PaulWieland Just out of curiosity, would it be possible for GND and Trigger Open to read what button was pressed? I've observed the other two buttons bridge White/Red the same way the big white button does, but Light/Lock use different types of capacitors:

Light Switch: 1uF 50v (Leon; Orange) Lock Switch: 22uF 50v (Leon; Blue)

Would it be possible to get a read on which one was pressed? Not sure if it's a different voltage or duration. (Sorry, don't know a whole lot about circuit design).

I've attached a couple photos of the internals (front/back):

[PaulWieland]

No they cannot. Also 78LM isn't powered when connected how I suggested above. It just becomes a door bell button. I still have to test this further to be sure it will work reliably since the circuitry of the 78LM could inadvertently pull the dry contact inputs low when we don't want it to.

[callitkarma67]

No they cannot. Also 78LM isn't powered when connected how I suggested above. It just becomes a door bell button. I still have to test this further to be sure it will work reliably since the circuitry of the 78LM could inadvertently pull the dry contact inputs low when we don't want it to.

Looking at @joeshaw's pictures, the command/trigger/open button sends a full short, which would read 0V. I figured I'd take a look to see if I could find an already written answer and found this... Hopefully it helps. The GDO has to know which button was pressed in someway, and it seems the capacitors do the trick via frequency.

https://diy.stackexchange.com/a/265094

I attempted to recreate the circuit in TinkerCad with a 9V as the power source, which does work as I believe it should, but I think it may just confuse as it is hard to follow, but I can link it if desired.

[JeffSteinbok]

I'm going to issue a firmware update which will allow the "trigger open" terminal to be configured as a toggle instead of a trigger. You will then be able to wire the 78LM panel to the GND and Trigger Open terminals of ratgdo instead of the door opener itself.

Pressing the big white button will then tell ratgdo to to open or close the door via it's dry contact input. The lock and light buttons of the 78LM will not function, however ratgdo can already control the light and the lock control is coming soon.

One concern here is that there are some keypads that are dumb and also have motion sensing for the light. Disabling that would be unfortunate.

Would the better solution be simply to send folks to the cheapest smart panel?

[mattinx]

I assume from the dumb panel photos and discussion that the GDO is looking for an active-low pulse of two different short durations for light and lock buttons (generated by the RC circuit between C1 or C2 and the a pull-up resistor in the opener itself) and anything longer is treated as an open/close button press.

Would it be possible to do an add-on board fed with +5V (or +3.3V) and providing a suitable pull-up, along with something to square up the output and possibly a 0.1uF cap to debounce the button, and feed the output of that into the TRIGGER_OPEN pin. Then you'd just need the code to look for pulses of the appropriate duration for lock and light buttons.

[edrikk]

@PaulWieland from a user experience point of view, is it possible to build a toggle to enable/disable this ratgdo functionality? I don't think it's a reasonable expectation of people to change their existing equipment, or to lose base functionality to gain IP access to their GDO.

While these issues are being resolved / tightened / etc, being able to simply open and close the garage doors without the polling causing chaos would be a great thing.

i.e. "For now" (hopefully) the user gives up ability to see the door status, but in turn they are able to say "Open The Garage Door" to their assistant and that would cause the open action to be triggered (regardless of door state), and similarly for close.

In the end, I would venture a guess that in most cases, people want to take an action when they visually can see the state of the given door. e.g. they are driving home and want to open it from their car's Siri integration etc.

[lukescott]

@edrikk I believe that's what the existing dry contact mode is for. It does not poll, and the dumb panel works normally. But you don't only lose the ability to see door status, but also control the light from HA. For door status you need to use a dry contact sensor. Although I think you might lose "opening" and "closing" and just have opened/closed.

Ideally moving the dumb panel off the garage door and onto the trigger/sensor side of the Ratgdo would preserve the emulation functionality and allow you to use the same dumb panel for opening and closing. IMO, this would be a great first step. If there was a way to interpret the pulses (?) generated from Light/Lock that would be even better.

[ngrusz1]

@edrikk I believe that's what the existing dry contact mode is for. It does not poll, and the dumb panel works normally. But you don't only lose the ability to see door status, but also control the light from HA. For door status you need to use a dry contact sensor. Although I think you might lose "opening" and "closing" and just have opened/closed.

Am I correct in thinking that, when it comes to Security 1.0+ dumb panels, the panels are unfortunately not as dumb as we might hope? That is, based on the conversations and pictures above, it looks like the typical Security 1.0+ dumb panel is not simply a "doorbell button" like we were hoping. It contains a few capacitors, presumably so the gdo can differentiate between presses of the different buttons on the panel. Has anyone attempted to connect one of these "semi-dumb" panels to the dry contact terminals on the ratgdo? Does this work as intended? Otherwise, if someone wanted to use dry contact mode, it seems like they would still need to replace their semi-dumb panel with a new, truly dumb panel?

[lukescott]

@ngrusz1 I don't think the concern is the capacitors because those are not connected as part of the door switch, it's the resistor that powers the LED continually. The resistor connects the two branches just above the screw contacts, but below the switch.

[jasonlearst]

@ngrusz1 I don't think the concern is the capacitors because those are not connected as part of the door switch, it's the resistor that powers the LED continually. The resistor connects the two branches just above the screw contacts, but below the switch.

There should still be a potential difference across the resistor. So the ratgdo should be able to detect the short when the button is pressed. The other functions wouldn't be detectable without additional circuitry.

The current problem per my understanding is that there is no door toggle input (only open and close) on the ratgdo when in Security+ mode. When that gets implemented as @PaulWieland mentioned above likely we could keep the dumb switches and at least be able to control the door from them.

[lukescott]

@jasonlearst

There should still be a potential difference across the resistor. So the ratgdo should be able to detect the short when the button is pressed. The other functions wouldn't be detectable without additional circuitry.

Any idea what else is required?

[3ane1]

Just wanted to report that the same issue affects the LM398 panel as well.

[mattinx]

So in the interest in possible future integration with the dumb wall panels, I hooked up a scope to the back of my dumb wall panel to take a look at what the dumb signalling looks like. It appears that the GDO is putting out a 200uS low pulse at approximately 80Hz when idle:

When you press the light button, that puts the 1uF capacitor across the line, extending the negative pulses to 2ms or so:

When you press the lock button, that puts the 22uF capacitor across the line, extending the negative pulses to more like 15-20ms:

And when the door is locked, the idle signal (high with short negative pulses) is interrupted in 100ms bursts to give the flashing LED on the panel:

This would be consistent with the GDO internally pulling the line high through a 2k resistor and switching a 0.1uF capacitor across the line every 12.5ms and then monitoring how long the pulse stays low. Pressing the lock or light buttons puts the larger capacitor in parallel with the internal 0.1uF cap, thus increasing the RC constant and lengthening the low pulse. Pressing the open button results in an even longer pulse, as you'd need to give it a really quick tap to get a short enough pulse to trigger light or lock.

[PaulWieland]

I've updated the FAQ a few days ago to explain the Sec + 1 wall panel behaviors: https://paulwieland.github.io/ratgdo/09_faq.html

Analog panels like 78LM can control the door but will not be able to control the light or lock functions because the GDO ignores analog commands once its in serial communication mode, not to mention the timing of those commands will be totally unpredictable.

[3ane1]

So the above shown panel is a digital one (LM398), correct? @PaulWieland If I were to replace it with a doorbell switch, do I wire the doorbell switch to the red control or one of the dry contacts?

[PaulWieland]

@3ane1 I don't have that specific panel, but yes, I believe its a digital panel. Capture a serial log from ratgdo before you replace anything to confirm what the wall panel is doing.

A door bell or momentary switch would connect to the red/ctrl and white/gnd terminals.

[cypherstream]

Could we just wire the Chaimberlain Sec+ 1.0 panel in parallel with ratgdo? Have it go to red/white directly on the gdo but get another set of wires from ratgdo to also go to red/white directly on the gdo? This way the capacitors in the wall button still do their thing to the gdo. Ratgdo could still pulse the door open button.

And for door position sensing I take I need two normally open reed switches, one down low to make contact when the door is shut and one maybe on the ceiling on some wood or something to line it up when the door is open all the way? Right now the chaimberlan MyQ uses a sticky sensor on the door and it detects its horizontal or vertical orientation. It has something like a CR-2032 battery in it. Its paird with a myQ box somehow (BLE maybe).

[rlowens]

Could we just wire the Chaimberlain Sec+ 1.0 panel in parallel with ratgdo? Have it go to red/white directly on the gdo but get another set of wires from ratgdo to also go to red/white directly on the gdo?

That's already what the terminals on the ratgdo do.

This way the capacitors in the wall button still do their thing to the gdo.

They already do most of the time. Only if they are old/deteriorating do they not maintain enough power to keep the door panel powered.

Ratgdo could still pulse the door open button.

ratgdo doesn't pulse the door open button on Security+ 1.0. It sends the door open serial command.

And for door position sensing I take I need two normally open reed switches

Only if you are switching from Security+ 1.0 to Dry Contact control mode.

[cypherstream]

Thanks, I didnt trace out the terminals but that explains why the gdo operates fine if the ratgdo is powered off.

So far I didn't have to buy anything. I reflashed with ESPHome and installed homebridge-ratgdo by hjdhjd. ESPHome security 1.0+ flash seems to correctly report the door and light status. Paul's Homebridge firmware did not (and yes I chose Security 1.0 in the config). Pauls firmware always claimed the door was opened, and I had to "close" it to open it. Then to close it I'd have to use a real remote or wall button.

So with my homebridge.io setup plugin and ESPHome so far everything's working as expected wtih "Hey Siri open the garage door" or "Hey Siri close the garage door".