ratgdo / homekit-ratgdo

A native HomeKit implementation of a Security+ 2.0 garage door controller based on ratgdo hardware
https://ratgdo.github.io/homekit-ratgdo/
GNU General Public License v3.0
214 stars 21 forks source link

Troubleshooting Sec 1.0 #132

Closed nsayer closed 3 months ago

nsayer commented 8 months ago

I've got a ~2001 Liftmaster opener and some time ago I bought an 888LM so that it could work with the Home Bridge. Well, Chamberlain locked everyone out of the web API and the HK functionality of the Home Bridge is flaky, so I decided to try RatGDO and this firmware. I've been taking some time to catalog my experience.

I actually have two 888LMs and an 889LM to try. One of the 888LMs has a MFG date in 2013. That one failed many years ago and I got the 2nd one as a free replacement. But I'm handy with a soldering iron, so I replace the two bad supercaps and got the first one working again. I bought an 889LM to see if it handled RatGDO any better.

In all cases, the door functionality - condition sense and operation - works fine. However, after working the door a couple or three times, the panel stops working with symptoms that indicate that the supercaps on board are insufficiently charged. Let it sit for a couple minutes and it will beep and go back online again. This was not an issue before RatGDO, so I am wondering if this is an endemic hardware issue.

When using an 888LM, the light button on the panel works, but light control from RatGDO or HK can only turn the light on. Sensing the light status does not work.

When using the 889LM, light control doesn't work at all, and I also cannot pair my car's HomeLink button (which works fine with the 888LM). Also, with the 889LM, on an average of once a day the door would just open on its own for no apparent reason.

I honestly don't know how many of these issues have anything to do with firmware, hardware or what not. In the case of both 888LMs, I do know that prior to RatGDO everything worked completely normally. I have not tried the 889LM without RatGDO, but I suspect it would also work just fine.

jgstroud commented 8 months ago

@mitchjs can you comment on this?

mitchjs commented 8 months ago

to me its hardware issue... i only have 889LM wired to my GDO (old craftsman one) and it just works

i suspect wiring

nsayer, i would get it all working without any RATGDO connected get it stable which version of RATGDO board you have, the one with the 3 pin connector that you connect to the gdo? i think thats 2.53i

i have 2.5i, which uses orange connector block, that i just connected 3 wires to the GDO at the GDO's terminals and then im powering up the ratgdo with a usb wall adaptor to supply 5v

nsayer commented 8 months ago

My RatGDO is the latest one - 2.53i. My opener has 3 terminals on it, and I matched those up to the 3 wires from the 3 wire pigtail. I then connected the 88xLM and obstruction sensors to the push-terminals as per the wiring diagram. It seems pretty straightforward to me.

The wiring before was that the obstruction sensors were connected between white and black and the 888LM between red and white. The wires helpfully had black and red stripes on them so that you could easily tell them apart. Before the RatGDO it was working for over a decade (apart from when the supercaps died on the first 888LM).

mitchjs commented 8 months ago

You have a good solid 5v supply on the board?You might need to reach out to Paul the hardware designer…Maybe disconnect all the wires from ratgdo board… get it all working just 88xlm and gdoThen connect the pigtail wires in to the gdo terminals without doing passthruThat’s what I’m doingMitch Sent from my iPhoneOn Mar 20, 2024, at 9:55 PM, Nick Sayer @.***> wrote: My RatGDO is the latest one - 2.53i. My opener has 3 terminals on it, and I matched those up to the 3 wires from the 3 wire pigtail. I then connected the 88xLM and obstruction sensors to the push-terminals as per the wiring diagram. It seems pretty straightforward to me. The wiring before was that the obstruction sensors were connected between white and black and the 888LM between red and white. The wires helpfully had black and red stripes on them so that you could easily tell them apart. Before the RatGDO it was working for over a decade (apart from when the supercaps died on the first 888LM).

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

nsayer commented 8 months ago

Ok, I wired everything to the back of the opener (getting 4 wires on the white terminal was an adventure). The behavior is unchanged. It seems like the whole system is having a lot of trouble keeping the supercaps in the 889LM charged. It only takes a couple of operations for it to go back to yellow+red blinking. When it IS working, though, the light control button on the 889LM works, but HomeKit can only toggle the light state when told to flip the light from off to on. The current light state is not reported. I will try to disconnect the RatGDO and see what the behavior is.

mitchjs commented 8 months ago

4 wires in white terminal?Not sure I followAt most there is 2 wires in the control panel terminals(each)One goes to wall panel, one goes to ratgdoLeve the obstruction ratgdo wire disconnectsd for now…So just 2 wires from ratgdo land on terminals of gdo… control and groundAlso tell me about how the ratgdo gets powerSent from my iPhoneOn Mar 21, 2024, at 1:06 AM, Nick Sayer @.***> wrote: Ok, I wired everything to the back of the opener (getting 4 wires on the white terminal was an adventure). The behavior is unchanged. It seems like the whole system is having a lot of trouble keeping the supercaps in the 889LM charged. It only takes a couple of operations for it to go back to yellow+red blinking. When it IS working, though, the light control button on the 889LM works, but HomeKit can only toggle the light state when told to flip the light from off to on. The current light state is not reported. I will try to disconnect the RatGDO and see what the behavior is.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

nsayer commented 8 months ago

This GDO has 3 screw terminals - red, white and black. The two pairs of wires from the obstruction sensors each go to white and black, and the red and white wire from the 88xLM go to the red and white. Then there's a red, white and black wire from RatGDO - so 4 wires on white, 2 on red and 3 on black.

nsayer commented 8 months ago

GDOs newer than mine have 4 push terminals - red, white, white and black. But not this one.

nsayer commented 8 months ago

5 volts for RatGDO are coming from an old iPhone sugar cube supply through an A to micro-B cable.

mitchjs commented 7 months ago

ah, that is an old one.... well try just ratgdo, connected to the red and white, leave the black disconnected (obstuction sensor) white is the common ground on the gdo but you might need help from paul, he should know about the HW side, i looked at schematic. to me the rat shouldn't draw much current at all (assuming it built right)

and it sits idle, if you do nothing. ie it doesn't transmit anything on the control wire, only listens.

nsayer commented 7 months ago

I will admit that in my moments of despair I browse the Genie website and consider replacements.

100ideas commented 5 months ago

I just wired up a v2.53 ratgdo homekit fw edition to my old chamberlain security + 1 (red program button) opener via the ratgdo's obstruction sensor and wall control (analog a la 78LM) bypass terminals. Homekit activated. So far, only behavior consistent with docs is that homekit and webui can successfully turn ON the light. can't turn off (b/c protocol?), but most annoyingly can't reliably open garage door. opened once in 10 minutes.

I expected the light button to stop working according to paul, but the rest of his explanation for my scenario doesn't seem to fit:

Analog wall panels (such as the 78LM) do not communicate with the door opener at all, and in this case ratgdo is able to query the garage door opener for status directly. This allows ratgdo to know the door state, but it has the side effect of disabling the analog wall panel’s light and lock buttons (the door open button still works normally).

https://paulwieland.github.io/ratgdo/09_faq.html


little update after I played a bit more with the web ui and homekit ui and watched the ratgdo web log in the console:

I am going to see if wiring in open and closed dry contact reed switches helps solve this problem

// pressed "door close" button in ratgdo web ui - surprise! door opens!
// note "sending DOOR button press" message at [ 194910 ]
// why does send button press behavior happen only intermittently?
undefined

>>> [ 194888] RATGDO: Key: garageDoorState, Value: 0
>>> [ 194890] RATGDO: close door request
>>> [ 194894] RATGDO: SetGDO Complete
5Fetch finished loading: POST "<URL>".
>>> [ 194910] RATGDO: sending DOOR button press
>>> [ 213771] RATGDO: Client 10.34.0.31 requesting: /auth (method: HTTP_GET)
Set: garageDoorState to: 0
>>> [ 213886] RATGDO: Client 10.34.0.31 requesting: /setgdo (method: HTTP_POST)
>>> [ 213905] RATGDO: Key: garageDoorState, Value: 0
>>> [ 213964] RATGDO: close door request
>>> [ 213972] RATGDO: SetGDO Complete
>>> [ 213985] RATGDO: Free HEAP dropped to 17344
>>> [ 217353] HomeKit: [Client 1073699604] Get Characteristics
>>> [ 220638] RATGDO: Client 10.34.0.31 requesting: /auth (method: HTTP_GET)
Set: garageDoorState to: 0
>>> [ 220703] RATGDO: Client 10.34.0.31 requesting: /setgdo (method: HTTP_POST)
>>> [ 220706] RATGDO: Key: garageDoorState, Value: 0
>>> [ 220709] RATGDO: close door request
>>> [ 220712] RATGDO: SetGDO Complete
>>> [ 220716] RATGDO: Free HEAP dropped to 17176
>>> [ 224211] RATGDO: Client 10.34.0.31 requesting: /auth (method: HTTP_GET)
Set: garageDoorState to: 1
>>> [ 224231] RATGDO: Client 10.34.0.31 requesting: /setgdo (method: HTTP_POST)
>>> [ 224237] RATGDO: Key: garageDoorState, Value: 1
>>> [ 224243] RATGDO: open door request
>>> [ 224247] RATGDO: door already open; ignored request

// I tried toggling a few buttons with noting down which. No effect on door.
// I'm confused by the log at this point - why are close/open door requests 
// being sent, and garageDoorState flipping from 0 to 1, instead of the 
// "sending DOOR button press" behavior above?
// now I decide to take more systematic notes in the console as I try diff buttons
//
// door is open, now I'm going to press Door CLose in UI

>>> [ 351705] RATGDO: Client 10.34.0.31 requesting: /auth (method: HTTP_GET)
Set: garageDoorState to: 0
>>> [ 351764] RATGDO: Client 10.34.0.31 requesting: /setgdo (method: HTTP_POST)
>>> [ 351779] RATGDO: Key: garageDoorState, Value: 0
>>> [ 351790] RATGDO: close door request
>>> [ 351793] RATGDO: SetGDO Complete
>>> [ 361147] HomeKit: [Client 1073699604] Update Characteristics
>>> [ 361174] HomeKit: [Client 1073699604] Get Characteristics
>>> [ 361207] HomeKit: [Client 1073699604] Get Characteristics
>>> [ 362218] HomeKit: [Client 1073699604] Update Characteristics
>>> [ 362276] HomeKit: [Client 1073699604] Get Characteristics
>>> [ 362332] HomeKit: [Client 1073699604] Get Characteristics
>>> [ 362355] HomeKit: [Client 1073699604] Get Characteristics
>>> [ 362373] RATGDO: get obstruction: 0
>>> [ 362376] RATGDO: get current door state: 0
>>> [ 362380] RATGDO: get target door state: 0
>>> [ 362383] RATGDO: get light state: Off

// hmm, no effect. Now I'm going to press "power off" in homekit - currently showing "powered on"
undefined

>>> [ 387008] HomeKit: [Client 1073699604] Update Characteristics
>>> [ 387014] RATGDO: set door state: 1
>>> [ 387031] RATGDO: close door request
>>> [ 402390] HomeKit: [Client 1073699604] Get Characteristics

// door still closed. now going to try "door close" button again in ratgdo webui 
undefined

>>> [ 421874] RATGDO: Client 10.34.0.31 requesting: /auth (method: HTTP_GET)
Set: garageDoorState to: 0
>>> [ 421918] RATGDO: Client 10.34.0.31 requesting: /setgdo (method: HTTP_POST)
>>> [ 421924] RATGDO: Key: garageDoorState, Value: 0
>>> [ 421927] RATGDO: close door request
>>> [ 421930] RATGDO: SetGDO Complete

// no effect on door. now going to try "door open" button in ratgdo ui
undefined

>>> [ 446313] RATGDO: Client 10.34.0.31 requesting: /auth (method: HTTP_GET)
Set: garageDoorState to: 1
>>> [ 446357] RATGDO: Client 10.34.0.31 requesting: /setgdo (method: HTTP_POST)
>>> [ 446383] RATGDO: Key: garageDoorState, Value: 1
>>> [ 446386] RATGDO: open door request
>>> [ 446389] RATGDO: door already open; ignored request
>>> [ 446391] RATGDO: SetGDO Complete

// no effect on door
undefined

>>> [ 459303] HomeKit: [Client 1073699604] Get Characteristics
>>> [ 459312] RATGDO: get current door state: 0
>>> [ 459315] RATGDO: get obstruction: 0
>>> [ 459322] RATGDO: get target door state: 0
>>> [ 459325] RATGDO: get light state: Off
>>> [ 464771] HomeKit: [Client 1073699604] Get Characteristics

// relaucnhed homekit app. ratgdo gararge widget indicaes "open". now going to close.
undefined

>>> [ 488034] HomeKit: [Client 1073699604] Update Characteristics
>>> [ 488053] RATGDO: set door state: 1
>>> [ 488058] RATGDO: close door request

// no effect. now going to wall control panel button and pressing it once (78LM type)
undefined

>>> [ 527146] HomeKit: [Client 1073699604] Get Characteristics

// door closed via wall mounted button
// note - have not wired up "dry contact" reed switches yet
undefined
mitchjs commented 5 months ago

i havent read this in detail yet, but lets confirm you have no existing digital wall plate? if thats the case, something is wrong with the "emulation" of wall plate.... in code you mention 78LM (not sure if that has any "electronics" in it)

mitch

mitchjs commented 5 months ago

anyway to capture the logs from startup of the unit?

dgoudie commented 4 months ago

I have observed very similar behavior with my brand new v2.53i ratgdo I just purchased on both of my craftsman Sec+ 1 GDOs (red button on both). Running newest 1.6.0 firmware.

Activating any controls via either homekit or the UI doesn't do anything 95% of the time, but occasionally a random button can cause the GDO to close when open. State doesn't seem to be captured correctly either for both the light and door open/close. As expected, the light toggle on the wall control doesn't work (as I assume I have an old analog wall control, which I can verify if necessary). The button on the wall control does indeed still work. I'll try to capture some logs this week, including startup logs.

image

mitchjs commented 4 months ago

i should be able to get some time this week to unplug my digital wall panel (888/889LM) and do some testing when its present, the digital wall panel does all the polling of the GDO, and the ratgdo basically listens in on the results when you don't have one of those digital panels, the ratgdo has to emulate one to get status... and of course without proper status... no proper functions...

mitchjs commented 4 months ago

good news, i found the issue (my fault)... i will fix with a PR soon

dgoudie commented 4 months ago

@mitchjs If you'd like me to flash a pre-release firmware to test, let me know. I'll be around so I can test for you if you care for that. 🙂

mitchjs commented 4 months ago

@dgoudie , sure... just need to figure out how to get it to you :)

im not 100% on this yet... i still have an issue... working to solve

try: https://github.com/mitchjs/temp-homekit-ratgdo

after flashing, the unit will look for wall panel for 15 seconds... then go in to emulation mode check webpage after that, see if you got status

image

dgoudie commented 4 months ago

It looks like your changes worked as far as the device being able to capture GDO state, it seems like door and light state are properly updating, however controlling the door still seems sporatic. It does seem better, however. It seems like all commands eventually run, but some run after a hefty delay. Some run immediately. I took a video with logs for you to see - you can see that some commands (specifically the first 'open' command) work immediately, but other ones are delayed: https://1drv.ms/v/s!ApVhK4jfEN6mgZxDGQx5DSzDnq8Vaw?e=eM2JUe

mitchjs commented 4 months ago

I just posted test #3 i have some bit of excess logging in it too, which could affect things...

mitchjs commented 4 months ago

test ##4 removes the logging... i have to pick this up in morning, but im pretty happy with it im very picky programmer, so ill review again in morning thanks for testing

dgoudie commented 4 months ago

Yep! Sure thing. Test 4 seems to work pretty well. Commands are pretty quick. Let me play around with it for a couple days and get back to you.

dkerr64 commented 4 months ago

@mitchjs once you nail this down, can you please included any necessary instructions in the README file when you submit the PR. I'm just a little concerned that things appear to behave differently depending on what wall panel is connected, etc. So, if end users need to be aware of things let's document it.

Thanks.

mitchjs commented 4 months ago

@dkerr64 , there is no difference to end user.... just internally... i should have caught this day 1 when i did the sec1.0 code ;( i have PR ready...

mitchjs commented 4 months ago

@dgoudie , there is test 5 posted (which should be final :) )

mitchjs commented 4 months ago

@dgoudie , how your testing going... passes all my tests here

dgoudie commented 4 months ago

@mitchjs seems to be working pretty well so far. I think we can call it good here, we can address anything else in a new issue if there's something else that comes up.

vmsandeeprao commented 3 months ago

Hi @mitchjs, thanks for fixing the issue. Do you know when your changes are getting merged and which firmware update it'll be included in? I'm also seeing the same symptoms as @dgoudie & @100ideas after I installed my brand new v2.53i ratgdo running firmware v1.6.0 yesterday and the system is basically unusable.

My GDO is a Liftmaster Professional 3280 (Sec+ 1.0 with a purple learn button) and a 78LM door control panel (analog).

mitchjs commented 3 months ago

good question, i thought by now it would have been merged in by now... @jgstroud did you every finish what you were working on? maybe just get the sec1.0 pr merged and rev to 1.6.1

jgstroud commented 3 months ago

Sorry. It's been merged just haven't done a new build. Life got in the way. Maybe @dkerr64 can kick off a build.

vmsandeeprao commented 3 months ago

The new fw v1.6.1 is flawless! Thank you so much for fixing this @mitchjs.

dkerr64 commented 3 months ago

Thanks. Will close this issue as fixed in 1.6.1.