TTC Controls

[mulcmu]

On my gdo sending SET_TTC time to close of 1 second with door fully open, will close door with flashing light and beeping for #42.

A flag is used to clear the TTC once closed with no checks of prior state, so this is a bit of a hack and would clear any prior TTC set by user. TTTC times other than 1 min, 5 min or 10 min cause the opener panel to cycle the TTC indicator lights.

Limited testing but working proof of concept.

[bdraco]

Marking this as draft until the TODOs are finished

[mulcmu]

There was still one TODO open that I'm not sure how to solve & still investigating. When the door is closed automatically with the TTC feature the position status doesn't get updated.

TTC function implemented using a select dropdown box with Off, 1 min, 5 min and 10 min options and the Auto Hold as a switch.

[bdraco]

Please format with clang-format --style=Webkit -i components/ratgdo/*.h components/ratgdo/*.cpp components/ratgdo/**/*.cpp components/ratgdo/**/*.h

[PaulWieland]

@mulcmu (or anyone with an 880LMW/881LMW wall control) Do you have a logic analyizer or another way of capturing the messages being sent from your wall control panel?

I have a feeling that you have replicated the command to set the TTC value, and that once that value is set the wall control panel will send a slightly different command value when closing the door.

What I would like to see is a normal "close door" command after the TTC value is set. We can decrypt it and see what values are being used. If you dont have a way of data capturing the serial data I'll just order an 881LMW or 880LMW wall control to find out.

[mulcmu]

Here is what I had worked out for the TTC commands. The PAIR_2 and PAIR_3 commands looked to be TTC related.

https://github.com/ratgdo/esphome-ratgdo/blob/5d72946c4ac3a0acc7745250f9c0c8f2b3c0db77/components/ratgdo/ratgdo.h#L90-L95

And what I was calling extended status, with the TTC state:

https://github.com/ratgdo/esphome-ratgdo/blob/5d72946c4ac3a0acc7745250f9c0c8f2b3c0db77/components/ratgdo/ratgdo.h#L73-L74

Here were some of my notes with the esphome logging set to Verbose for the packet decoding ratgo logs.txt

[mulcmu]

The TTC operations are all working and tested with my gdo. HA and the 881LMW wall pad stay in sync with any TTC changes. It is fully functional if anyone wants to start physical testing.

Still left to finish up:

• [ ] Some more testing of the close_with_alert function to restore prior TTC settings.
• [ ] Add a trigger for TTC interrupted feedback to HA UI.
• [ ] Readme changes for TTC
• [ ] Close with alert seems to get ignored if attempted right after opening door, test more

[PaulWieland]

I can confirm this works but I'm not really sold on the idea of:

• reading the TTC setting
• changing the TTC setting to 1 second (which then closes the door)
• restoring the original TTC setting

There are a number of problematic things I can think of that could happen if we deployed that to everyone... imagine a scenario where a person has a basic wall control panel with no means to change the TTC setting of their door. Now imagine what would happen if either the read or the restore message wasn't processed correctly.

They could end up in a situation where their door's TTC is stuck on 1s without an obvious way of fixing it, which would not result in a happy user.

I think the safer solution would be to add an option to convert the obstruction status output into a beeper driver. A two wire beeper could be wired to the 3.3v and obs - status terminals and a user selectable option to swap the obst status for a beeper could be chosen.

[mariusmuja]

They could end up in a situation where their door's TTC is stuck on 1s without an obvious way of fixing it, which would not result in a happy user.

They would be able to change it back from home assistant or esphome web page. I see this feature being useful for people wanting to use it in automations, so changing it in home assistant would be obvious to them.

[bdraco]

We can set the entity to be disabled by default so they would need to turn it on

[PaulWieland]

Just playing devil's advocate here...

1. I'm sure most households have one person who is the HA expert and then one+ who are users, all with different levels of enthusiasm and knowledge. One person might use HA while the other uses the button on the wall.
2. the obstruction sensor normally doesn't trip until the wheel hits the obstruction beam (meaning the trunk/hatch can strike the door before the obstruction sensor can save you). If your TTC is set to one second because the read or write failed, then then you back your car out the door without realizing the door was already closing, you are going to be extremely mad that this feature was available for you to try.

[bdraco]

Ideally we find the command to close the door with the beeping so we don't have to adjust the TTC do to that. There must be one since the HK bridge can do it

[bdraco]

Happy to mail out the spare bridge I have if someone has a way to decode what its sending

[mulcmu]

Door getting stuck on TTC of 1 second can be mitigated to some extent by retrying to restore the value until confirmation that is was restored. Still some risk of communication/power/software failures.

Backing up into closing door is a risk with any remote operation or automation that closes the door if the timing is right.

TTC off causes door to beep once. We could just spam the gdo with light toggles and TTC off to simulate the alert until proper command is identified.

[mariusmuja]

Happy to mail out the spare bridge I have if someone has a way to decode what its sending

@bdraco I recently got a software defined radio (RTL-SDR) dongle and I'm able to decode button presses from the garage opener remote. If you still have the MyQ bridge and want to mail it, I might be able to decode something from it now.

[bdraco]

I will send it when I get back to Texas on Monday if you send me your mailing details via discord (same handle) or nick@koston.org

[bdraco]

@mariusmuja I am back and Texas and can ship that now. I didn't see an email from you or discord message. If you sent an email it might have ended up in spam. Please let me know

[mariusmuja]

I emailed the mailing address, I just sent another email.

[bdraco]

Perfect, bridge is boxed, labeled, and in the box to go out in the morning

[mariusmuja]

Perfect, bridge is boxed, labeled, and in the box to go out in the morning

Cool, I received an USPS tracking email as well.

[apaperclip]

I have an rtl-sdr and the simple myq wifi bridge to interface with my 888lm. When closing via the myq I get the warning beeps prior to and while closing. Happy to help capture the rf signal and decode, just need some direction on what you captured with and used to decode if its more than rtl_433.

[mariusmuja]

rtl_433, although it claims to support Security+ 2.0, for me it doesn't seem to be able to decode the signals from the remote and keypad.

Try cloning https://github.com/argilo/secplus, run ./secplus_rx.py and share the output it's showing when closing the door via the myq wifi bridge (assuming it's able to decode it).

[mariusmuja]

As a side note, for anybody using a pin keypad to open the door, this thing is sending the PIN in the radio messages to the gdo every time you open / close the door. Crazy how insecure these things are, anybody with an rtl-sdr could capture the pin, would not even need to get fancy with replaying the message with an updated rolling code, the pin is right there!

[jfroy]

As a side note, for anybody using a pin keypad to open the door, this thing is sending the PIN in the radio messages to the gdo every time you open / close the door. Crazy how insecure these things are, anybody with an rtl-sdr could capture the pin, would not even need to get fancy with replaying the message with an updated rolling code, the pin is right there!

Wait all of those pin pads that everybody has aren't wired, they're RF-based, and they send the pin on the air?? 🙃

[mariusmuja]

Wait all of those pin pads that everybody has aren't wired, they're RF-based, and they send the pin on the air?? 🙃

Exactly! And anybody with a $20 rtl_sdr dongle and a laptop sitting in range can capture the pin.

[PaulWieland]

Lets be honest here though... we already know how to decode and encode the rolling codes. All you have to do is capture the last used rolling code, decode it, advance it +1, re-encode and transmit. The only way to secure these door openers is to disconnect them from the internet, clip the RF antenna wires off and control the door exclusively through ratgdo 😎

[mariusmuja]

Lets be honest here though... we already know how to decode and encode the rolling codes. All you have to do is capture the last used rolling code, decode it, advance it +1, re-encode and transmit.

Fair enough. For transmitting you can't do it with an rtl_sdr though, but there are alternatives, more expensive (HackRF) or more knowledge required to hack together something. But yeah, all these radio remotes/keypads are very insecure. Better use a cellphone with ratgdo.

[apaperclip]

rtl_433, although it claims to support Security+ 2.0, for me it doesn't seem to be able to decode the signals from the remote and keypad.

Try cloning https://github.com/argilo/secplus, run ./secplus_rx.py and share the output it's showing when closing the door via the myq wifi bridge (assuming it's able to decode it).

@mulcmu

after some trial and error with differ pi os releases I was able to get secpus_rx to run but I'm not sure its working correctly. I get the analyzer window that does show a transmission, but the terminal window just shows a repeating 0 no matter what. It does not match the output from the readme at the secplus repo.

I have a few more tests to do but I'm worried the library is not running correctly.

[mulcmu]

@mariusmuja @apaperclip

Any progress finding command to close with warning?

[mariusmuja]

I should receive the MyQ bridge this week (tracking info says this Thursday), then I'll see if I can decode something. If I do, hopefully the same command(s) are going to be accepted & behave the same on the wire...

[apaperclip]

@mariusmuja @apaperclip

Any progress finding command to close with warning?

I just realized I meant to reply to @mariusmuja in my reply about secplus_rx, my bad. I've pivoted to the nightly docker container of rtl-433 hoping it can give me something useful. I'm keen to hear what mariusmuja finds.

[apaperclip]

@mariusmuja

I should receive the MyQ bridge this week (tracking info says this Thursday), then I'll see if I can decode something. If I do, hopefully the same command(s) are going to be accepted & behave the same on the wire...

Have you had any time to see if your sdr can identify whats being transmitted?

[mariusmuja]

Have you had any time to see if your sdr can identify whats being transmitted?

I did have some time to play with it this past weekend.

I was not able to decode anything yet, indeed secplus_rx doesn't decode anything out of the box. Looking at the spectrum analyzer in gqrx it would seem that the bridge does not transmit on the 310, 315 or 390MHz frequencies that the remote/keypad transmits on (and on which secplus_rx listens on by default) - when I open the garage door though the bridge I see no indication on the spectrum graph of any transmission from the bridge.

Both the GDO and the bridge are working on both 300MHz and 900MHz frequencies according to the FCC ID, so now I'm trying to figure out if the bridge is sending commands on a 900MHz frequency and which frequency that is.

[apaperclip]

Both the GDO and the bridge are working on both 300MHz and 900MHz frequencies according to the FCC ID, so now I'm trying to figure out if the bridge is sending commands on a 900MHz frequency and which frequency that is.

Yeah I would guess ~915 and looks like the fcc test agrees. I'll spend some time looking at that range.

[mariusmuja]

Unfortunately, some bad news on this: we're unlikely to be able to capture communication between the bridge and the GDO using a RTL_SDR. When looking at the 900MHz range while the bridge is sending an open command, it looks like this on the spectrum analyzer:

You can notice it transmits on several frequencies on this 902-904 MHz frequency slice, which made me suspect it might be using frequency hopping. After some search I found this, which (although it refers to a Chamberlain radio used in commercial openers) says:

The 300 MHz and 400MHz low bands are unidirectional and receive only. The 900 MHz high band is bidirectional which can both transmit and receive data packets between an Internet Gateway and other MyQ devices. In high band the ESARM operates in Frequency Hopping Spread Spectrum (FHSS) mode

After some more searching I found confirmation that the 819LM bridge (and all other MyQ accessories/hubs most likely), use FHSS for the bidirectional 900MHz band: https://www.nwdusa.com/wp-content/uploads/2018/05/819LMB-Sell-Sheet.pdf, https://amz.dekcanada.com/files/product_files/821LM_BROCHURE.PDF

902-928 MHz 50 Channel FHSS (Frequency Hopping Spread Spectrum) Provides two-way communication from garage door opener and MyQ Accessories Enables remote closing of garage door with key MyQ Accessories and Control Panels Enables monitoring and control of garage door openers and lighting controls via internet-enabled computer or smartphone

So capturing the bridge communication with a RTL_SDR is likely a dead end due to the limited sample rate/bandwidth (possible with more expensive SDR receivers). It's also unclear if in the bidirectional 900MHz FHSS mode the bridge and opener talk to each other using the Security+ 2.0 protocol or something else....

[PaulWieland]

I've never tried this, but can we get an electrical copy of the data by probing the antenna circuit with a scope?

[mariusmuja]

I've never tried this, but can we get an electrical copy of the data by probing the antenna circuit with a scope?

Possibly, with a good enough scope, it's going to be a 900Mhz signal.

I was thinking the next best hope would be to check on the board if the radio module talks to the microcontroller using some serial protocol (UART, SPI, I2C) that we can sniff with a logic analyzer.

[mariusmuja]

I had a look inside, it's using a Si4432 chip (https://www.silabs.com/documents/public/data-sheets/Si4430-31-32.pdf) as wireless transceiver, programmed though a SPI bus by the MCU, so it should be possible to sniff that. I'll give that a try one of these days when I have some time.

[mulcmu]

Another idea I had was to send random or incremental wireline commands to a gdo with the door open until it responds / closes. As stated before, even if we find the right rf command, there is no guarantee it will work the same on the wire. I don't have a spare gdo to test. There is some risk the random commands clear some configuration setpoints, activate a factory test mode, or otherwise make gdo self destruct.

[mulcmu]

had a look inside, it's using a Si4432 chip (https://www.silabs.com/documents/public/data-sheets/Si4430-31-32.pdf) as wireless transceiver, programmed though a SPI bus by the MCU, so it should be possible to sniff that. I'll give that a try one of these days when I have some time.

Any luck intercepting/decoding the MCU to radio traffic?

[dkerr64]

@mulcmu can you advise status of this PR. Can you set a TTC duration and request the door to close with it... while beeping and lights flashing? Thanks.

[mulcmu]

The commands to send to the GDO and feedback responses form the GDO for the TTC status are figured out and implemented. The GDO operates the same as if TTC were enabled at wall control (beeping/flashing + 2 attempts to close if obstruction is triggered). Ratgdo changes to TTC settings are reflected on the wall panel, wall panel changes get updated on ratgdo. An explicit command to just have door close with lights/beeping has not been found to my knowledge.

These changes are based on the code prior to the Security 1.0 overhaul and need a rewrite to integrate with the current main branch.

[doctorkb]

An explicit command to just have door close with lights/beeping has not been found to my knowledge.

I understand that there was a thought that a TTC of 1 second would effectively do this. Has that been found to not be the case?

[dkerr64]

The commands to send to the GDO and feedback responses form the GDO for the TTC status are figured out and implemented. The GDO operates the same as if TTC were enabled at wall control (beeping/flashing + 2 attempts to close if obstruction is triggered). Ratgdo changes to TTC settings are reflected on the wall panel, wall panel changes get updated on ratgdo. An explicit command to just have door close with lights/beeping has not been found to my knowledge.

I am looking at how to implement TTC in the HomeKit version of ratgdo firmware. It would help to understand the sequence of commands that need to be sent to the GDO and the expected responses from it. For example, do we first set a TTC duration, then send a regular close command, then reset/clear the TTC duration. Thanks.

[PaulWieland]

The risks of something going wrong with this approach outweigh the benefits. If for some reason the TTC clear command isn't accepted by the GDO, the TTC will be 1 second, which is far more likely to cause physical damage or harm than the door not beeping.

If you want to implement a warning feature, the safest thing to do is to delay the door close and blink the light on and off

[dkerr64]

The risks of something going wrong with this approach outweigh the benefits. If for some reason the TTC clear command isn't accepted by the GDO, the TTC will be 1 second, which is far more likely to cause physical damage or harm than the door not beeping.

If you want to implement a warning feature, the safest thing to do is to delay the door close and blink the light on and off

Ah, so you suggest implementing it all in the ratgdo firmware... flash the lights, say once a second, for whatever duration I want and then send a door close. Essentially the same thing (without beeps) but all within our control. That actually sounds like a good idea and easy to implement.

[mulcmu]

Sending a TTC duration of 0 command will cause the GDO to beep, but it will also disables TTC if it was enabled. So visual and audible alert using only ratgdo and gdo is possible if you forgo using TTC. In theory TTC duration could be restored after the close is complete