hart2hart Posted March 18 Posted March 18 (edited) Its been quite a while since I used it but the ratgdos are no longer controlling my garage doors or lights. I've confirmed: Stable wifi to the two ratgdos Power cycled the ratgdos Restarted the node server Sent logs via PM. Thanks. Edited March 18 by hart2hart
gzahar Posted March 18 Posted March 18 Mine has done this twice. Continues to report status correctly, just won't control. Unfortunately, only solution to re-flash (with erase option) and re-install. I have recently tried to put in an automated use of controlling the light so that I notice how often/when it actually happens.
Goose66 Posted March 19 Posted March 19 It looks like from the logs you sent that the door state wasn't changing from the door commands, but the light state was changing correctly based on the light commands. The ratgdo plugin uses MQTT. So for the plugin, a command for a node is "successful" if the plugin puts the corresponding message for the ratgdo device into the MQTT message queue. The MQTT message queue runs on the same Polisy or eISY as the plugin, so sending commands are almost always logged as successful. If the ratgdo retrieves the message from the MQTT message queue on the Polisy and correctly executes the command, then the ratgdo turns around and sends a status change back to the MQTT server (e.g., Polisy) which the plugin picks up and changes the corresponding node state. Accordingly, from the log file, all I can tell is that your door open and close commands are successfully making their way into the MQTT message queue. I believe there must be a problem with your ratgdo as to network connectivity to the Polisy/eISY or the ability of your ratgdo to control the door. Because the light commands seem to work, I think it must be the latter. Unfortunately for all of us, the current MQTT firmware for the ratgdo device does not contain a locally hosted website that allows you to test/exercise control functions like the other firmwares do in order to debug operation. At least you can test the connectivity to the ratgdo device by accessing the locally hosted website. Outside of that, restarting or flashing and reconfiguration as @gzahar suggested may be your best debug options. We all need to chime in on an issue in the ratgdo firmware Github repository that control buttons needed to be added to the locally hosted website for troubleshooting.
gzahar Posted March 19 Posted March 19 7 minutes ago, Goose66 said: It looks like from the logs you sent that the door state wasn't changing from the door commands, but the light state was changing correctly based on the light commands. This was similar to the response you sent me. The AC responds that the light turns on, but it doesn't. It does seem to be the ratgdo not communicating properly with the gdo. I was not sure if I had a bad device or this was happening to others. Wanted to get more data if I could (how often, after some particular event, etc.) before opening an issue on github. 1
hart2hart Posted March 19 Author Posted March 19 This was similar to the response you sent me. The AC responds that the light turns on, but it doesn't. It does seem to be the ratgdo not communicating properly with the gdo. I was not sure if I had a bad device or this was happening to others. Wanted to get more data if I could (how often, after some particular event, etc.) before opening an issue on github.Same here. ratgdo did not control the lights or doors but the states tracked perfectly. @Goose66 I said sky was falling last week so hate to do it again… any chance the recent PG3x update for MQTT may have been part of issue? It was working early last week but I don’t know when it stopped. Edit: wife used the MyQ app to remote open and close door last week. She did not use UDMobile as I thought so can’t say last time it worked.
hart2hart Posted March 19 Author Posted March 19 Mine has done this twice. Continues to report status correctly, just won't control. Unfortunately, only solution to re-flash (with erase option) and re-install. I have recently tried to put in an automated use of controlling the light so that I notice how often/when it actually happens.Do I have to do this from USB port or can I do it with OTA flashing back to the same version it’s already running 2.57?
gzahar Posted March 19 Posted March 19 2 minutes ago, hart2hart said: Do I have to do this from USB port or can I do it with OTA flashing back to the same version it’s already running 2.57? Don't know. I have not used OTA flashing. I think using the erase option is key (not sure) and that is probably only available with USB. But give it a try.
hart2hart Posted March 19 Author Posted March 19 I went to the ratgdo site. This might be issue #17. RATGDO not controlling opener · Issue #17 · ratgdo/mqtt-ratgdo · GitHub I did the OTA update with same version and it didn't fix it. In next few days, I'll get a laptop and erase and then reflash it. If that works does it imply there is an area of config data that is corrupted or bad from a bug and the erase is the only fix to get it back in sync?
Goose66 Posted March 19 Posted March 19 It does appear that the issue you posted is what’s happening. It also seems that the problem may be fixed in the ESPHome firmware, so maybe there’s hope that a similar fix is coming to the MQTT firmware. I have dry contact mode openers and am not having similar problems. Maybe the problem is something to do with the rolling codes? That could explain why a reflash fixes it (temporarily).
hart2hart Posted March 19 Author Posted March 19 1 hour ago, Goose66 said: It does appear that the issue you posted is what’s happening. It also seems that the problem may be fixed in the ESPHome firmware, so maybe there’s hope that a similar fix is coming to the MQTT firmware. I have dry contact mode openers and am not having similar problems. Maybe the problem is something to do with the rolling codes? That could explain why a reflash fixes it (temporarily). I flashed them one at a time this morning (now I know why I took time to 3D print an enclosure for easy access) with erase and they are working again. I'll post and as you said we should post the issue on ratgdo site because it's likely to occur again. On the topic of rolling codes, I wondered on original install why the ratgdo did not require being "learned" by the garage door opener -- it just worked. I made sure this morning not to open door manually before reinstalling it and it worked first press again and seemingly did not have a chance to learn/teach.
Goose66 Posted March 19 Posted March 19 (edited) It actually seems to have something to do with "client ID" (?). From the faq: Quote ratgdo is wired correctly and won't control my door Verify that you are using the correct control protocol for your door opener model. ... If you are using Security + 2.0, you can try and reinstall the firmware and choose the "Erase" option which will force the generation of a new client ID for communicating with the door. Edited March 19 by Goose66
gzahar Posted March 20 Posted March 20 12 hours ago, Goose66 said: If you are using Security + 2.0, you can try and reinstall the firmware and choose the "Erase" option which will force the generation of a new client ID for communicating with the door. That is what prompted me to try the re-flash/erase option.
hart2hart Posted April 14 Author Posted April 14 @Goose66 I’ve recently flashed with erase for second time. As you noted and others, the ESP Home FW does not appear to have this issue. Feel certain you’re tired of GDO at his point, but if MQTT FW is not fixed at some point is moving plug in to ESP Home even a possibility?
Goose66 Posted April 15 Posted April 15 I am hoping the ratgdo creator (Or someone else) will get a version of the MQTT firmware working. I only have dry contact and have no problems.
hart2hart Posted April 15 Author Posted April 15 I am hoping the ratgdo creator (Or someone else) will get a version of the MQTT firmware working. I only have dry contact and have no problems.Me too! My question is would it even be possible to use the ESP Home FW in our environment.
Goose66 Posted April 16 Posted April 16 (edited) It may be possible but it would be a heavier lift for me to move the plugin to ESPHome than for the ratgdo FW developer to put whatever fix is in the ESPhome firmware into the MQTT firmware. The door control portions of the firmwares should be the same. I would offer to fork the firmware and implement any fixes myself, but I don’t have Security+ 2 gdos. Edited April 16 by Goose66
sjenkins Posted April 16 Posted April 16 I’ve gotten so frustrated with the mqtt version I abandoned it & put home assistant on a pi. I have no use for HA otherwise. I am now backfeeding to the ISY the variables I want. Pain in the a** but it is working. certainly not the recommended solution. My next step was to figure out how the HA protocol works. Sounds like a time sink. I would really rather they just fix the mqtt version. Seems like he knows how as this esphome version is bulletproof.
Goose66 Posted April 17 Posted April 17 (edited) Both versions of the ratgdo firmware are available on GitHub. If somebody has Security+ 2 gdos could compare the code, fork the MQTT firmware repository, make the changes, test, and then submit a pull request back to Paul. Edited April 18 by Goose66
sjenkins Posted April 17 Posted April 17 Yes, and. The issue with that is his use of ESPhome , it’s a platform in its own right. So he is really programming his application as a set of JSON scripts which ESPhome then handles as a platform. So not much to easily compare. That is why I was thinking if I could understand the HA comms. For now my very ugly method of adding a pi with HA is working more reliably than you might think. My current frustration is that the author seems to want the MQTT version to go away. It was why we purchased hardware. There currently seems to be one sided dialogue with little from the author. Happy if I’m wrong here but I am subscribed to the issues & that is my read. 1
Tommy James Posted April 25 Posted April 25 My experience is that when the GDO stops working it comes back on it own after a short time period which usually involves us using the physical remotes and wall buttons but for whatever reason the codes sync back up and everything works again. My theory, from reviewing the logs of the GDO, is the rolling codes get back on track from the utilization of the physical buttons. The door that gets used several times a time a day sync back up very quickly and the other door takes longer because we don't use it that often. My GDOs stop working during power outages, wifi issues or EISY reboots. Hope this helps and see if a few physical button pushes and a bit of time help you guys.
Goose66 Posted April 25 Posted April 25 To support our (UD's) plugin, the MQTT firmware needs to support a query across all modes (Security+ 2.0, Security+ 1.0, and dry contact) and add state update on initialization of the ratgdo device. This would take care of the EISY reboot and power outages issues, respectively. There are issues entered in the MQTT firmware Github repository discussing both of these, but no word from Paul Weiland on any of it. I have a GDO (circa 2007 Genie Screwdrive) that's sounds like it's about to die. If I can replace it with a Security+ 2.0 MyQ model, I would have a testbed to perhaps doing a pull request and producing a UD-compatible MQTT firmware version. But very hard to justify that cost. If ESPHome has all of these issues solved, maybe an ESPHome version of the ratgdo plugin is not a bad idea.
sjenkins Posted April 25 Posted April 25 I do agree an ESPhome version may be the right way to go. Got so frustrated with the MQTT version that I abandoned it. I have been running for now the last month with ESPHome on my Ratgdo. I put up a HomeAutomation server on a Pi4 laying around (I don't use HA for anything else) and then using the UDI plugin on HA backfed the Ratgdo flags to variables then Virtual devices on my EISY. The above chain gang of handoffs which took about 2hrs with writing the automation on the HA and some programs on the EISY has been rock solid for a month, in both directions. Go figure. My plan is to make a Virtual device to match the garage door opener I/O. For bonus points, If I can find the time, would like to take the HA out of the chain with a plugin. Just really need to find some docs with the protocol and write it. Or wait for someone else to do it.
Goose66 Posted April 25 Posted April 25 Looks like there is a Python interface for the native API already available, but it's async! I have wanted an async version of the udi_interface for PG3 for years now. If only... 1
Goose66 Posted May 6 Posted May 6 (edited) tl;dr: I'm working on it. Yep. Looks like MQTT firmware is dead - although there is no confirmation from Paul Wieland on this. Most recent activity is on the ESPHome firmware. But there are gotchas there as well (see some of the discussion above). For example, the ESPHome firmware reboots itself every 15 minutes if the Native API (Home Assistant) is not being used. According to Paul, this is "by design." So if you want to use another API for the ESPHome firmware (e.g., REST/SSE) you have to trick the firmware into thinking it has a Native API connection as well to keep it from rebooting. Alternatively, if anybody here knows how to change yaml files local on their ratgdo devices (in a way that could be explainable to other users), we could set a flag to prevent the rebooting (or, even better, turn on the MQTT interface in the ESPHome firmware) and get a plugin running against the ESPHome firmware rather quickly. However, I don't relish the notion of forking the firmware and maintaining a completely separate version to support the UD plugin. Edited May 6 by Goose66
Recommended Posts