ratgdo / homekit-ratgdo Goto Github PK

Will this be supported on the v2.5 boards that are now shipping?

Follow-up to my comment here, because this is potentially useful info

#24 (comment)

There is a problem when connected to Eero (Gen 2) satellites - loss of connection, No Response, pings all over the place (up to 1000ms and drops). I moved the ratgdos next to the master Eero Pro AP, far away from the garage and other satellites, and all these issues vanished.

This is the case with 0.7 & I also built the firmware per #24 (comment) - there was no improvement.

So, I dug out an ancient OpenWRT reflashed-TP-Link (irrelevant but it was a fun find) and installed it in my garage as an additional AP and now the ratgdos are rock solid, with steady 5ms ping times, no dropouts. It works perfectly.

For what it's worth: my wifi is very stable across the whole mesh, the satellites give me 300Mbps all day long with no issues on my phone, laptops etc. So it really seems like there is perhaps something in Eero mesh management that messes with the wifi stack.

I'll keep an eye out for any improvements in the firmware and give them ago if they might address this.

Suggestion: if you make changes in a release such as adding a login, please update the README.md file with the information. The release notes for v0.11.0 do specify the default username and password which is necessary. The README.md does not have this info yet.

And yes, I know I could put in a PR to address this. :)

It would be fantastic to have a Lock/Unlock feature for the remote lockout. Imagine the convenience of being able to disable your garage remotes or the outdoor keypad remotely via HomeKit, especially when you're away from home for an extended period.

When attempting to create an automation related to the door opening, Open/Close isn’t available but Lock/Unlock are. They don’t work the same way. Version 0.9.0.

I've recently been getting a lot of false notifications from HomeKit.

Without logs from ratgdo, it's hard to understand what's happening, but one giant red flag is the uptime from the admin page. Right now it shows it's only been up for 4 minutes which doesn't meet my expectations. I only restarted it last week when I upgraded to FW 0.10.0.

If there's any more info I can provide to help debug, please let me know.

The device log in the flasher page doesn't work. No idea why. It'll speak Improv so obviously it's getting serial bytes but... just nothing shows up. Super weird.

Well, I don't appreciate closing issue #42 without any opportunity to discuss. And as GitHub would not let me reopen it, I am opening a new issue.

I understand the need to keep the firmware image as small as possible, but offloading HTML (or in this case the QR code PNG) to an off-site server is not the answer. The incremental size is small (the PNG is way larger than it need be) and the QR code can easily be embedded into the HTML as SVG... see here.

Yes, I understand that internet connectivity is required to flash the device. But that does not mean that it should be required for setup.

I have not opened a PR with the above commit only because if you shutdown #42 without discussion, why bother if you won't merge it.

For some reason my HA is not detecting my ratgdo. My HA is reporting other MQTT devices?
My MQTT broker can see it?
Any suggestions?

HA:
Core
2023.11.3
Supervisor
2023.11.6
Operating System
11.1
Frontend
202310.2

MQTT broker:

shellyplugus-
shellyplugus-
frigate
homeassistant
cover
light
binary_sensor
MAIN DOORGARAGE DOOR
status
availability = online
obstruction = clear
motion = detected
door = closed
light = on
lock = unlocked
$SYS
shellies

There are currently two timer-esque things (activity LED and motion sensor) that are handled alongside in the comms loop. While not representing a huge amount of computation time, it'd still be better if these were pulled into their own file or section of ratgdo.cpp (per this comment)

I have a door opener by Overhead Door, so I need support for the dry contact switches. I'm hoping that can be enabled on this project soon.

Would it be possible to add buttons to trigger the door and/or lights to the ratgdo's web page? Then one could test to make sure things are wired up properly even before pairing to HomeKit.

As we get close to feature complete, I think we could do a much nicer job for the web page. But rather than dive in and try code something I thought best to document requirements / design ideas and ask for comment. Then maybe we can divide tasks among ourselves. Here are my initial thoughts...

Design:

• As lightweight as possible (no loading of 3rd party UI helpers, all self-contained)
• Looks just as good on phone/tablet/desktop portrait and landscape
• Both http and https (self signed cert only?)
• Password protected with default "admin" that user can change
• Password protect and/or require confirmation for potentially destructive actions

Content:

• Basic system information (IP address, firmware version, free memory, etc)
• QR code (which should display/hide without different page formatting)
• Garage door/light/obstruction status
• Copyright/Trademark/Contributor attribution

Available actions:

• Upload new firmware
• Reboot
• Unpair/re-pair
• Manually set IP/netmask/gateway/DNS
• Update/change SSID/password (maybe too risky?)
• Update/change web page password
• View logs / set syslog server address?
• Control the door (open/close/etc) -- going too far maybe?

API

• Should we provide a basic http/https API that returns say a JSON with door/light/obstruction status?
• Protect potentially destructive URLs with basic authentication (right now nothing stops you from going to http://<ipAddr>/reset)

Thoughts? Reactions?

Decoding the motion packet type is supported, but does not currently result in anything happening. Add support for reporting the motion sensor state by adding and wiring up the service.

Current code triggers a notification from HomeKit that the Garage Door is Open as soon as the gdo button is pressed. The door is still in the opening process. The notification should happen after the door is finished opening.

However, the code does seems to work correctly for closing the door. When the door is open, and the gdo button is pressed, HomeKit does not notifiy you that the Garage Door is closed until it is actually fully closed. This is working as intended.

Opening this Issue to track updates to the web page. This compliments and replaces issue #56

Tasks to do (reported bugs):

• Fix typos/spelling errors, formatting, etc. --- done
• reduce size of favicon / apple-touch-icon --- done

Still to implement:

• Password protected with default "admin" that user can change --- done default UID is admin, PW is password, both lowercase.
• Upload new firmware, improve GUI --- done
• Manually set IP/netmask/gateway/DNS
• Update/change SSID/password (maybe too risky?)
• Update/change web page password --- done
• View logs / set syslog server address? (may not be possible)
• Control the door (open/close/etc) and light --- done
  Progress on the above is being committed into this branch, no PR yet.

I'm running ratGDO v2.5 HW, homekit-ratgdo-v0.6.0 FW, LiftMaster 8550WL.
I have the fancy 880LMW Wall Button with motion sensor and the LCD display on it constantly displays:

SENSOR MOMENTARILY
OBSTRUCTED
ERROR CODE 4-6
SEE USER MANUAL

The top GDO button works, and the bottom light button works, but nothing I can do to clear the message... the 4 menu function buttons directly under the LCD don't do anything to clear the screen either. I still have the MyQ app installed and the MyQ Diagnostics show No Issue(s) reported, and it shows that the sensors are good and aligned (meaning no obstruction I guess). Unplugging Liftmaster and replugging didn't fix either.

(Just received ratGDO HW, loaded v0.6.0 HK FW,, and wired up. Everything works beautifully and I just spent the last half hour testing everything I could think of on homekit/etc as well as sensors/lights/buttons. All works well with only this one bug found thus far- Thanks for everyone's fun hard work!!! )

The auto_firmware_version.py script is not safe way to establish the version. The script presumes that git describe --tags will work, but that requires that the git repository actually have tags. Without it you get:

fatal: No names found, cannot describe anything.

And the firmware version embedded into the source is empty. This matters because anyone who forks the repository will not carry over all the tags, each repository have their own tag history.

A better place to pull the version number from would be manifest.json file. This contains the actual version number and is independent of any git tagging.

The discord link on the project home page

Pointing to https://discord.com/channels/432663330281226270/1184710180563329115 is broken. It should be an invite to the Discord server, so tapping/clicking on it will launch the Discord app or website and take you directly to the project’s Discord. Invites should look like https://discord.gg/hTKzmak, hTKzmak, or https://discord.gg/cool-people

If you can add warning beep as Myq does from app that would be awesome

I think the ESP8266-based devices' flash is too small (confirm this), but the ESP32 should easily support OTA updates.

So, like, do that.

I just received 2 ratgdo v2.5i boards and flashed them both to "HomeKit-ratgdo" and the seem to work great for my current needs... until they are both plugged in. They have the same HomeKit ID and seem to conflict with each other. Am I imagining this or can you not have two modules in the same home right now? I was having significant delays and unresponsiveness on the one that is hooked into my main door. The other one is just powered on, sitting on my desk. When I removed power from the "Left Door" that is sitting on my desk the "Right Door" became extremely responsive.

Did I miss something? can I change the HK ID somehow? I couldn't find an email address and the Discord link is busted.

Discord in READ.me not work

Hello,
New user - I just hooked up RatGDO which I flashed with HomeKit according to the instructions.
I have a purple Learn Button so I assume that I have a Security + 1.0
I also have the LiftMaster 889LMMC Control panel
Followed all wiring and setup instructions.
The web interface displays the correct status.
However, adding to HomeKit displays the garage door with incorrect status and no ability to control it.
Will post pics below
Can someone point me in the correct direction to resolve the issue?
Thanks:

LED stays on with current version. Set LED to default off unless there is activity (ie command sent from HomeKit, door in operation)

My gdo doesn’t have a motion sensor on it, so it is useless for me and just clutters up the home app.

Would be great to have a way to opt out of this, either just ifdef’ing it out and offering two firmwares, or perhaps a config in the webpage that allows you to turn it off.

There’s probably a similar use case to remove the light control, but I imagine most people’s openers have a light bulb built in.

I can successfully add the ratgdo to HomeKit, and everything works great, but after a day or so, it shows as "No Response" until I reboot the device.

@PaulWieland anyway you can set the permissions outlined in this answer so that we can get the releases automated?

https://stackoverflow.com/questions/75995802/resource-not-accessible-by-integration-github-action-fails-for-pushed-commit

I just use the flash page to upgrade my ratgdo_v2.5 device to homekit-ratgdo 0.10.0.

I am attempting to pair it with my home via pointing my camera at QR code shown in the webUI. Home.app starts walking me through the adding process and warns me about the the unverified accessory. I continue through that and after a short delay it errors out with the message:

Unable to Add Accessory.
The setup code is incorrect.

I don't recall ever having this problem on the homekit-ratgdo 0.9.0 firmware.
What do I do next?

Here's the video of what happens.
https://github.com/ratgdo/homekit-ratgdo/assets/704392/3648e24a-515a-4b52-b9ef-4f8bc1bc5cd3

During Improv-based provisioning, the various steps never "recover", and progressing requires closing the flasher UI entirely and re-connecting. Once the user has re-connected, the next step is available and succeeds (but never "recovers").

That is, instead of

• connect
• flash image
• connect wifi
• open device page

Instead a user must

• connect
• flash image
• disconnect and reconnect
• connect wifi
• disconnect and reconnect
• etc

post-flashing

After flashing, the console log reads:

Wrote 542416 bytes (378008 compressed) at 0x0 in 37.034 seconds.
Leaving...
HARD RESET
DISCONNECT
Initializing Improv Serial
Starting read loop
Writing to stream: [0x49, 0x4D, 0x50, 0x52, 0x4F, 0x56, 0x01, 0x03, 0x02, 0x02, 0x00, 0xE5, 0x0A]
Finished read loop
Improv initialization failed. Error: Improv Wi-Fi Serial not detected

The time between DISCONNECT and Initializing Improv Serial is far, far shorter than the time required for the Improv loop to have begun running.

post wifi

After provisioning WiFi, the console log reads:

Writing to stream: [0x49, 0x4D, 0x50, 0x52, 0x4F, 0x56, 0x01, 0x03, 0x1B, 0x01, 0x19, 0x07, (ssid bytes), 0x10, (psk bytes), 0x12, 0x0A]
PROCESS {version: 1, packetType: 1, packetLength: 1, data: '[0x03]'}
Uncaught (in promise) TIMEOUT
Finished read loop

I suspect this is because the connect_wifi loop bails after 2 seconds (10 times 200ms delay). Increase this and see what happens.

Posted on reddit and they mentioned to try and post here. I can't connect the USB because the port is covered. Is there a way for me to fix?

The light bit in the status packet is currently decoded, but not used for anything. There also support for the light command packet type, but it's also not used.

Add a light service to the device and wire it up to be updated with that status bit. (read-only mode initially)

Add support for sending light commands to the GDO in order to control the status of the characteristic. (read-write mode)

The ESP32 is pretty cool. This should also run on that. Preferably in the D1 Mini form-factor.

The project will not build. I get the error that secplus.h is not found, which is included in packet.h

Noticed that our car’s programmable HomeLink GDO buttons now take multiple tries… I dismissed as RF interference for a while. Today I realized my clickers also take multiple tries to successfully send an open/close signal (My GDO is SEC+ 2.0).
HK app will always work still though, and also wired Wall button. It’s only the clicker remotes, HomeLink, and external wireless keypad that now take multiple tries.

Having an issue pairing with HomeKit and wonder the best way to trouble shoot / debug what's going on.

• I flashed version 0.2.2
• Vist Device
• Add Accessory in iOS
• Scan QR Code
• Add Anyway

Then an error appears saying that the device could not be added.

I then started over/erased/repeated entire procedure. Failed a second time. But the third time it worked...

Hi!

Thanks for creating this. I installed successfully, and was able to open and close the garage door a few times using the Home app.

It seems like after an hour or so, HomeKit reports "No response". It seems like I can occasionally ping the device, though not reliably. The wifi strength at the location is good, I've got an AP that it's connected to very close.

Are there any logs or anything I can do to help investigate?

Also it appears the discord link might be expired.

Obstruction support is not completely implemented. The characteristic is required so it's already there, and its value is based on the status packet bit, but that bit is not like super reliable.

Add code for reading and reporting the state of the obstruction sensor wire itself, and updating the characteristic with that value. Probably ignore the status packet bit, or at least confer with the other firmware authors to figure out how it works (or doesn't).

Every time a command is sent, the rolling code value is written to EEPROM. This is not ideal, as (very, very, very) frequent usage could result in the EEPROM exceeding its rated write cycles (100k?).

Refactor the code to:

• only write the rolling code count to EEPROM once every n commands
• Increment the stored count by n at boot up

This will reduce flash wear by a factor of n, and extend hardware life.

I can help develop/debug if someone documents what the development / build environment needs to be.
Thank you

Current lock state log message here is the same as current door message here

Same for target states here and here

So you cannot tell in the log which state is being requested.

Security+ 1.0 GDO's have Purple, Red, and Orange Learn Buttons.

https://paulwieland.github.io/ratgdo/01_features.html

I can't get the unit to connect to wifi. Ive tried it two different wireless networks, and it always times out. Any ideas on why that might be? Thx.

I'm not sure this belongs here. But I'm not sure where else to go. So ...

I've been running on v0.9.0 and it's been completely stable and reliable with no interruption for over 9 days. Yesterday I upgraded OTA to v0.10.0 using the web page. While everything appeared to go fine, when the device came back up it wasn't connecting to my non-mesh, single router, 2.4 Ghz only Wi-Fi network.

After waiting for quite some time I disconnected the ratgdo from the garage door and brought it inside close to my router. That didn't help. Here's where it gets weird. I connected over the serial connection from my PC (tried both Win 11 and Mac OS with the same results). The flasher tool works fine and I re-flashed the firmware (tried with and without erase). But when I get to the page to connect to Wi-Fi, even though it lists my network in the dropdown, the connection always times out no matter how many times I try. To eliminate my router, I tried two other 2.4Ghz networks on separate routers. Same results, timeout!

Is there some process to completely reset the board? Is there an older flasher I can use to try to load the older v0.9.0 code? Any other ideas?

Jeff

First, thanks for this amazing work!

I was wondering what was the upgrade process. Can I simply re-flash to ratgdo for every new update? Should I need to re-enter the wifi credentials? Need to re add to my Homekit setup?

Thanks!

This was mentioned in Issue #25 that was closed but the issue persists. Per PaulWieland from Issue #25 "fwiw, the mqtt firmware turns the led on when searching for wifi. Once connected it shuts off. It then flashes whenever it receives a command. I would suggest having the same behavior for all firmware versions to help people trouble shoot issues in a common way."

Currently the activity LED stays on as default instead of turning off after connection to Wifi and flashing on activity.

Tested on 5x RATGDO v2.5i running 0.9.0.

The pairing QR code should be self contained within the device. Right now internet access is required to retrieve the QR code and is therefore at risk of not being available.

Need to find a way to embed this with the firmware and not require internet access.

Firmware: 0.10.0

We have 2 RATGDOs. Something went a bit haywire a few days ago and both were showing No Response. I unpaired both from HomeKit in the RATGDO web interface and removed them from the home app. I can now add one, but the other displays the attached screenshot error - Accessory Already Added / Garage Door has already been added to this home.

I've tried downgrading to 0.9.0, reupgrading to 0.10.0, tried rebooting, tried unplugging and replugging.

Reboot required after obstruction and GDO light stays on all the time unless manually turned off from homekit.

I'm testing with just the board itself, not yet connected to garage door opener. Successfully paired to HomeKit but if I then try and open the door it goes into a loop...

!!! [ 227921] RATGDO: transmit failed, will retry
>>> [ 227927] RATGDO: Collision detected, waiting to send packet
!!! [ 227933] RATGDO: transmit failed, will retry
>>> [ 227939] RATGDO: Collision detected, waiting to send packet
!!! [ 227944] RATGDO: transmit failed, will retry
>>> [ 227950] RATGDO: Collision detected, waiting to send packet
!!! [ 227956] RATGDO: transmit failed, will retry
>>> [ 227963] RATGDO: Collision detected, waiting to send packet
!!! [ 227969] RATGDO: transmit failed, will retry
>>> [ 227975] RATGDO: Collision detected, waiting to send packet
!!! [ 227980] RATGDO: transmit failed, will retry
>>> [ 227986] RATGDO: Collision detected, waiting to send packet
!!! [ 227992] RATGDO: transmit failed, will retry
>>> [ 227998] RATGDO: Collision detected, waiting to send packet
!!! [ 228004] RATGDO: transmit failed, will retry
>>> [ 228010] RATGDO: Collision detected, waiting to send packet
!!! [ 228016] RATGDO: transmit failed, will retry
>>> [ 228022] RATGDO: Collision detected, waiting to send packet
!!! [ 228027] RATGDO: transmit failed, will retry
>>> [ 228033] RATGDO: Collision detected, waiting to send packet
!!! [ 228039] RATGDO: transmit failed, will retry
>>> [ 228045] RATGDO: Collision detected, waiting to send packet
!!! [ 228051] RATGDO: transmit failed, will retry
>>> [ 228057] RATGDO: Collision detected, waiting to send packet
!!! [ 228063] RATGDO: transmit failed, will retry
>>> [ 228069] RATGDO: Collision detected, waiting to send packet
!!! [ 228075] RATGDO: transmit failed, will retry
>>> [ 228081] RATGDO: Collision detected, waiting to send packet
!!! [ 228087] RATGDO: transmit failed, will retry
>>> [ 228093] RATGDO: Collision detected, waiting to send packet

Eventually I think it crashes and reboots. Connecting this to my GDO is not practical for testing purposes.