Closed vehlajatt closed 6 months ago
For anyone reading, this requires TTC support.
For anyone lost like I was: TTC stands for Time To Close and seems to be a delayed-close feature? I'm not sure what support is needed for this (if it is a software problem or if only some GDOs support it or what).
Also discussed at https://github.com/ratgdo/esphome-ratgdo/pull/43
This was one of the first things I noticed, the lack of delay and beep. While I would like ot have this feature I am not sure it is critical EXCEPT for remote closing. Which I have had to do a couple times. If it is added I will update the device to have it.
I actually really like the fact that it just closes and doesn't beep and flash. Works just like a remote would. Am I the only one that likes it better this way?
There should be option to turn on/off beepOn Jan 5, 2024, at 7:45 PM, jgstroud @.***> wrote: I actually really like the fact that it just closes and doesn't beep and flash. Works just like a remote would. Am I the only one that likes it better this way?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
I actually really like the fact that it just closes and doesn't beep and flash. Works just like a remote would. Am I the only one that likes it better this way?
I agree. Honestly don't get the point.
The beeping flashing was always so annoying to me.-Bruce GuidottiOn Jan 5, 2024, at 7:53 PM, Donavan Becker @.***> wrote:
I actually really like the fact that it just closes and doesn't beep and flash. Works just like a remote would. Am I the only one that likes it better this way?
I agree. Honestly don't get the point.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
I used to think that it was just an annoyance, but a big benefit of HomeKit control is being able to operate the door remotely, and as someone with young children I can see why the beep and flash is used (mandated possibly?). I can probably learn to live without this, but having this would add some peace of mind.
@OleSam85 isn't that what the obstruction sensors are for though?
@donavanbecker yes in theory, though I’ve seen kids playing on something that might straddle it, and some of the assorted neighborhood animals are either small enough to fit below the beam or large enough to straddle it. While I’d love to say we’re always in control, kids and pets are unstoppable agents of chaos. Parenting has broken my brain to the point where I’ve become very good at imagining a myriad of ways for my kids to maim themselves. As mentioned it’s livable without the feature, but any bit of extra insurance for tired/absent minded parents can be welcome. My personal opinion is it’s better left open (albeit as a lower priority issue) but I won’t be offended if anyone tells me I’m nuts and closes this.
I am not saying that it should never be added, I just don't think it is a priority. If someone wants to take it on an open a PR. PERFECT!
The beeping just never made sense to me. Even if you were straddling the obstruction beam, even a small child or animal would move out of the way when they hear the garage door coming down on them.
Also, just to ease your mind a bit, your garage door opener by code is supposed to automatically open if it encounters resistance when closing. You can safely test it. Close your door and stand near it and hold your arm out. It should reverse with only a bit of pressure.
I'm really not trying to be a prick about it. I have kids myself. I just never saw this as a feature that was doing anything to keep anyone safe.
Its helps a lot to some,if you dont like it then you don't need to explain.. we should be able to turn on/off for who likes ot or who dont.On Jan 5, 2024, at 10:40 PM, jgstroud @.***> wrote: I'm really not trying to be a prick about it. I have kids myself. I just never saw this as a feature that was doing anything to keep anyone safe.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
For the record, I personally do like the warning beeps and flashes, but I was always annoyed by the delay. My GDO is pretty dang quiet, and heavy machinery shouldn't be sneaky. My current thought/plan is to check if the TTC packet supports few- (or zero-) second delay values, and if it does, then send TTC instead of a door command so the control is nicely responsive but still gives warning to anyone around.
For the record, I personally do like the warning beeps and flashes, but I was always annoyed by the delay. My GDO is pretty dang quiet, and heavy machinery shouldn't be sneaky. My current thought/plan is to check if the TTC packet supports few- (or zero-) second delay values, and if it does, then send TTC instead of a door command so the control is nicely responsive but still gives warning to anyone around.
This is out of scope of ratgdo project, it'd be neat if it were possible to use (e.g. Ring) motion sensor as an interlock on any switch/door controller. I haven't explored if this is possible. Maybe it is possible to tie a motion sensor into the obstruction sensors.
[[removed my anecdote because it was interpreted as suggesting the warning is somehow unsafe by OP. Not my intention at all]]
That’s possible by using the (not visible in Apple’s Home app) lock characteristic of the garage door accessory, but yes out of scope of this discussion ;)
People who don't want it stay out here it’s discussion for people who wants it..and i if it can happen …. and if it will happen there should be toggle for on/off.
We don’t need ideas if its safe or not. Thank you
People who don't want it stay out here it’s discussion for people who wants it..and i if it can happen …. and if it will happen there should be toggle for on/off.
We don’t need ideas if its safe or not. Thank you
Sorry. I didn't suggest I didn't want it, that it was useless, or dangerous. If it was added I'd enable it.
People who don't want it stay out here it’s discussion for people who wants it..and i if it can happen …. and if it will happen there should be toggle for on/off.
With all due respect, I am interested in collecting many user opinions, and welcome all input. No decision has been made about whether it will be supported (likely) or configurable (unlikely).
Just to add another data point: I like the idea of this being implemented but would want it configurable. The fact that I'm able to close the door instantly is starting to grow on me. If implemented, I may try enabling it, but I'm betting I'd prefer to leave it off.
The delay/beeping/flashing on MyQ are a by-product of US federal safety regulations 1211.14 for "Unattended operation of residential garage door operator".
TL:DR 5 second delay before closing, audible signal (45db at 10ft), visual alarm (360 lumens). Unattended operation is disabled after 2 consecutive unsuccessful closer attempts caused by "entrapment protection", requiring manual operation to be re-enabled.
So "technically" RatGDO (and many other "Smart" GDO accessories for that matter) aren't following safety regulations. Is it a little bit "nanny state" over protection? 🤷♂️
Thank you for the citation! I’m not (we’re not) bound by that rule but it’s good to have definitive source.
As for the “nanny state” question, the counter to that is that safety regulations are often “written in blood”. Until we get a committee representative in this thread, I guess we’ll never know.
Is the TTC communications understood or does that still need to be sniffed and reverse engineered?
TTC is understood.
What’s not understood is if there is a different door control command that will cause the beeper to beep. The wireless myq commands cause the GDO to beep. If someone has the hardware, time and energy to use a software defined radio to capture those commands from a wireless myq controller we could try and send the same command via hardwired serial.
I do have the MyQ HomeKit hub (819LMB) and a garage door monitor (829LM) which both trigger the flashing/beeping. If I recall both devices communicate to the opener on a ~900MHz frequency band. Is the assumption that the data packet there may be similar/same as the on the wire communication?
I can try to capture the data from each device. Give me a few days to dig out the RTL and find some time to capture some data. Or if there is someone who knows for certain what they would be hunting for we can arrange lending hardware (829LM)
Reading up on the FCC documents for the 829LM (FCC ID: HBW7451) the unit hops frequency across 902-928MHz and has 50 different channels that it hops between. I don't have a ton of experience with the RTL-SDR and I doubt it has the bandwidth to capture the full message across hops. If anyone has any pointers though I am happy to give it a try.
aren't following safety regulations
This is a consumer product safety issue. It isn't a requirement of random accessories (which ratgdo is), only of the opener itself if it offers unattended closing directly.
For what it's worth, the folks who promote Tailwind's GDO device use this as the reason to not get a ratgdo -- that it doesn't meet this antiquated safety standard.
I have started to implement this and am doing it within the ratgdo firmware and NOT using the garage door opener's built-in delay function. The team working on the PR that @jgstroud cited above have not fully reverse engineered how that works and so leaving the GDO's delay feature untouched seems wise.
Here is what I have implemented...
Does the above sound right?
The current door state reported to the web page and HomeKit does not change during delay period... it still reports opened until the end of the delay when it will change to report closing.
My only concern with this is that could appear as "unresponsive" to some systems like Alexa or HomeKit. I'm unsure of what their window is for believing that the device has heard their command.
It would also seem prudent to report that as "closing" unless it was somehow cancellable.
The current door state reported to the web page and HomeKit does not change during delay period... it still reports opened until the end of the delay when it will change to report closing.
My only concern with this is that could appear as "unresponsive" to some systems like Alexa or HomeKit. I'm unsure of what their window is for believing that the device has heard their command.
It would also seem prudent to report that as "closing" unless it was somehow cancellable.
I've not checked yet what HomeKit reports when the myQ app is used to remotely close with a delay. We should do the same as it does.
If you close from the Apple Home app it moves the door slide to closed position immediately, it doesn't wait to get a "closing" state back from the door.
The other situation we have to handle is if someone in the garage presses the wall control or another remote button during the delay period. The garage door will close immediately, but the ratgdo delay loop will still be flashing light on/off. The firmware needs to cancel delay loop if it detects that someone (something) else has initiated door close.
I have support for this queued up in PR #145
Fixed in #145
Fixed in #145
I tried this but got no beeping, is that expected?
@donavanbecker yes, that's expected.
If you can add warning beep as Myq does from app that would be awesome