Goose66 Posted January 5 Posted January 5 The latest release of the ratgdo plugin contains a "breaking" change - see release notes. Ultimately this will make configuration easier for folks not as familiar with MQTT, but early adopters will have to delete their nodes (in the PG3 Dashboard) and then perform Discovery process again. 1
bigDvette Posted January 6 Posted January 6 Just installed and discovery went fine. All statuses were updated on initial creation of nodes. Didn't have to redo any programs. Thanks!
SHM Posted January 6 Posted January 6 Hmmm. Seems like I have gone backwards. Updated to polisy 3.2.17, IoX 5.8.0 and ratgdo plugin 3.1.4. I did the node deletions and re-discovered. My 3 garage doors with ratgdo devices installed and configured properly are added and show again on ISY. For each door node, I see "door state", "lockout", "online" and "obstruction." All doors are online and correctly show the open or closed status. However, the "open" and "close" buttons no longer open or close the doors. The ratgdo plugin log doesn't show anything, but the MQTT plugin log shows "waiting on valid configuration." For the latter, I have entered custom parameters of MQTT_host ("localhost"), MQTT_port ("1884"), MQTT_clientID ("RATGDONS") and discoverytopicprefix ("home assistant"). Any suggestions? Doors had been working fine.
SHM Posted January 6 Posted January 6 P.S. I should mention that MQTT explorer shows all doors and nodes active under my polisy LAN IP
Goose66 Posted January 7 Author Posted January 7 (edited) What do you mean by “MQTT plugin?” It appears from your post that you are running the MQTT plugin and the ratgdo plugin at the same time and the MQTT plugin is configured to use the client ID of “RATGDONS”. This will not work. Since the ratgdo plugin uses an MQTT client ID of “RATGDONS” by default, if you also configure the MQTT plugin to use the same client ID, they will continually kick each other off the broker in your eISY. Edited January 7 by Goose66
SHM Posted January 7 Posted January 7 OK. I deleted the MQTT plugin and went to the ratgdo plugin, deleted the nodes then re-discovered. Populates ISY fine, but still no garage door activity (or light) when I try "one" or "close" from the AC. MQTT explorer shows all 3 doors. I did upgrade the ratgdo firmware to 2.57 btw. Interestingly, the UD Mobile app does open and close the doors (albeit slowly). Will see if my door open/close programming still works.
SHM Posted January 7 Posted January 7 Here are the log and log package ratgdo_1-7-2024_82253_AM.zip ratgdo_1-7-2024_82307_AM.zip
Goose66 Posted January 7 Author Posted January 7 It would be helpful to change the logging level to debug and retry Open and Close commands, then resend the log. I will say, however, from the logs you sent, this looks a lot like network issues. Remember, the plugin doesn't talk to the ratgdo device. The plugin only talks to the MQTT broker, which should be the local MQTT broker on your eISY/Polisy. It seems the commands are being published successfully (i.e., no warnings or errors logged) to the MQTT broker for, e.g., "Turn Off" for light on ratgdo1234_lt and "Open" for gdo on ratgdo67899, but given the lack of change in the corresponding status values being published back from the ratgdo device, I suspect the commands aren't making it from the broker to these two ratgdo devices. For ratgdo41031, it appears to respond to commands, but takes a LONG TIME to update status: 12 seconds to respond to the "Open" command and 17 seconds to respond to the close command. You mentioned using MQTT Explorer before. If MQTT Explorer has a robust connection to the MQTT broker on your Polisy/eISY, then you should be able to monitor all this in real time and determine where the network problems are. In addition, try publishing Open and Close commands directly to the ratgdo device(s) via MQTT explorer and see how they respond. It should be virtually instantaneous.
SHM Posted January 7 Posted January 7 So in the interim, I started over by deleting the ratgdo plugin, then re-installing it and re-discovered the ratgdo devices. I have attached the debug log and MQTT Explorer page that lists the devices (is it expected that under Homeassistant, the devices also appear?). When I use UD Mobile and watch the MQTT Explorer, each device shows the correct change in the open and close command from UD mobile, although there is a 5 second or so delay. For some reason ratgdo-41031 only shows the open/close under a separate level labeled "command". Since I still have my doors connected to MyQ wireless (maybe I should not?), I can watch the doors open and close. When I am on AC, the open/close commands also work, but with a slightly longer delay. At one point, I did receive a TCP error on AC after hitting the open command several times for one door. Not sure how I troubleshoot the network but I am willing to learn. Hope this helps and again, thanks for your Sunday help. ratgdo_1-7-2024_14011_PM.zip
Goose66 Posted January 7 Author Posted January 7 Looking at the section of the log with Debug logging mode turned on, I can see that the plugin and PG3 appear to be operating correctly and fairly fast - for example, it takes 4ms after PG3 receives an Open (DON) command from IoX for ratgdo-12345 until the plugin publishes the "Open" command to MQTT broker (debug logging was not on when the plugin was started but I am assuming the local MQTT broker on your Polisy/eISY). However, a corresponding state change message is not received from the ratgdo device for another 13 seconds. That means it's taking 13 seconds for the MQTT broker to get the command to the ratgdo-12345 device, the device to start moving the door, and the device to publish a status change message back to the MQTT broker reflecting the movement. By contrast, in my network, that delay is 536 milliseconds. This points to the problem being in your network (or possibly your local MQTT broker on your Polisy/eISY). Addressing some of your specific points/questions: 1. The messages under the "homeassistant/#" topics are for discovery. They aren't actual status messages. 2. The "command" topics reflect the command message posted by the ratgdo plugins. These should show up almost immediately after you press a command button in IoX Admin Console or UD Mobile. These messages are not retained, so if you disconnect MQTT Explorer and reconnect to the broker, they will be gone. 3. AFAIK, having MyQ connected shouldn't affect anything, but I don't know the details. My MyQ continues to operate with the ratgdo devices in control, but I don't have Chamberlain MyQ door openers - I have Genie with the MyQ Universal Controllers. However, watching the doors open and close on MyQ app won't give you a very good indication of timing, because the MyQ app has tremendous latency (and variation in latency) in reflecting changes since it has to travel roundtrip to Chamberlains cloud servers (including their 3rd Party web servers and security servers). 4. Yes, hypertapping may take you to the killscreen in Tetris (evidently), but it will certainly break things in Admin Console and UD Mobile 😁. Especially when testing and debugging problems, I counsel patience so you can see what button presses causes what issues and is associated with which log entries. 5. If it is a network issue with your ratgdo devices, I won't be able to help you. If it winds up looking like a problem with the MQTT broker on your Polisy/eISY, you will need to open a support ticket with UD.
SHM Posted January 8 Posted January 8 Thanks you. Makes sense. When I drove away from the house today, my ISY program that closes the door based on geolocation ran and gave me a push notification that the door was closed but it did not. I was able to close it on UD mobile but sounds like the network is the issue. I have one of the original Polisy devices that has been upgraded along the way to PG3 but maybe its time to upgrade to eISY. I will open a ticket. Maybe Michel can work his magic.
EWhite Posted January 8 Posted January 8 I found out that most of these devices DO NOT like running on a mixed wireless environment(2.4g and 5g). I upgraded my wireless and now have a dedicated 2.4g only wireless IoT network that REALLY sped thing up for me. just throwing my 2 cents in.......cant even buy bubble gum with that! 1
bigDvette Posted January 8 Posted January 8 18 hours ago, SHM said: Thanks you. Makes sense. When I drove away from the house today, my ISY program that closes the door based on geolocation ran and gave me a push notification that the door was closed but it did not. I was able to close it on UD mobile but sounds like the network is the issue. I have one of the original Polisy devices that has been upgraded along the way to PG3 but maybe its time to upgrade to eISY. I will open a ticket. Maybe Michel can work his magic. Just out of curiosity after you deleted and added node servers and such, donations a refresh on the mobile app and have it clean up the devices?
toddhutch Posted January 10 Posted January 10 (edited) (Early adopter) I was able to update to to 5.8, and 3.1.4, but the commands weren't working with alexa. To narrow this down, I tried to run the "run then" for the program that I have. That didn't work. I had to highlight the command, and click the update in the add to program window, then save the changes, and it worked. Seems like the eisy device while visually looked correct, the acition set for door1 close won't work until the action was updated and save. I'm not really thinking this is an issue with the plugin, but the mechanism which things were changed and how eisy handles this. I had to updated each open and close command for the doors. I'm glad I made this variable based, so I only had to update it in 6 places. But I wonder if there was a simple way to refresh those programs. Everything seems to work great now. Thank you @Goose66 Edited January 10 by toddhutch
SHM Posted January 13 Posted January 13 My MQTT communications problems have gone away for some unknown reason. Good news. I have noticed that if the power goes out to your garage (and ratgdo if you connect it via usb to AC power), then all the nodes default to "unknown." Hitting the open/close button in the node resets the door status, but if you use door status in a program and the condition depends on "open or close" status, then the program won't run. Argues for connecting the ratgdo to the batter backup, if you have it.
Goose66 Posted January 13 Author Posted January 13 Resetting the status values to “Unknown” when the device goes off line is something I’m doing. I don’t really use it in programming though, so if it’s hanging other people up, I can remove it.
Goose66 Posted January 13 Author Posted January 13 If we could get the query to work in the ratgdo firmware, that would help too.
Recommended Posts