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.

[mariusmuja]

This does not work ok if one of the request fails. For example if GET_OPENINGS doesn't receive a response it doesn't retry the request like the original code did. (The opener can choose not to respond to commands if too many are sent too quickly, or the response is not received for any number of reasons).

[mulcmu]

I was looking at it like if GET_STATUS succeeded then the rolling code was okay. It is possible the door sends a STATUS response by chance during the sync retry period as well. I think adding the retry mechanism to the query_status() to make sure gdo sends new data for each request would make it robust for initial sync and any future calls but without the increment to the rolling counter. Does this address your comment?

[mariusmuja]

I was looking at it like if GET_STATUS succeeded then the rolling code was okay.

True, but the rolling code is not the only reason of failure. I've see it happen that the GET_STATUS succeeds and GET_OPENINGS does not get a response (for various reasons as I initially mentioned).

It is possible the door sends a STATUS response by chance during the sync retry period as well. I think adding the retry mechanism to the query_status() to make sure gdo sends new data for each request would make it robust for initial sync and any future calls but without the increment to the rolling counter. Does this address your comment?

Not sure what you mean "without the increment to the rolling counter". Each new command needs incrementing the counter by one. Additionally we increment the counter initially in sync in case we crashed and didn't manage to persist to flash the last counter value.

The retry mechanism is to ensure we sync the initial state correctly, rolling counter mismatch being the most likely reason for failure, but not the only one.

[mulcmu]

Not sure what you mean "without the increment to the rolling counter". Each new command needs incrementing the counter by one. Additionally we increment the counter initially in sync in case we crashed and didn't manage to persist to flash the last counter value.

I was referring to the initial increment by 10 in sync(). query_status() was reworked in ESPHome-RATGDO@8929b32 to retry with confirmation that each of the 4 status messages returned successfully.

[owendelong]

If I can get working ratgdo hardware to the point I no longer care about my HomeKit bridge, I have a good MSO (200Mhz 4 analog and 32 digital channels) with SPI decode and would be willing to try and poke around/capture data from said bridge.

Unfortunately my ratgdo seems to be doa, and I haven’t had any luck getting a response to deal with that.

[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

[WillCodeForCats]

I have an 829LM which I don't see mentioned here, but the only thing it does is send the close command (with light/sound warning). I don't have any logic analyzers to probe it though.