Goose66

Excellent. I just updated the release notes, but I will go back and work in some of your screenshots with the next release.

If you click the link on number 1. in the instructions above, you get the "ratgdo Firmware" page. It says "There are several excellent firmware options available for ratgdo..." and then shows options for "ESPHome" firmware, "Chowmain Software Integrations" firmware for Control4 and Elan, Native HomeKit firmware, and "MQTT" firmware. It is the MQTT firmware you want to install. It appears from the PDF file you posted that you installed the ESPHome firmware, and thus you get that ESPHome status/configuration page when you click "Visit Device."

From the symbol at the top of the attached PDF file, I am guessing you installed the ESPHome firmware. You need the MQTT firmware. Looking at the firmware installation page now, it appears that it has changed substantially since I flashed my first ratgdo and subsequently wrote the plugin directions. I will need to update the release notes to make sure folks are selecting the MQTT firmware option for flashing. Specifically, under the MQTT option on the firmware page, choose "ratgdo v2.57, Security + 1.0, 2.0 & Dry Contact" from the dropdown.

Sounds like you are never accessing or seeing the configuration web page from the device itself. After flashing your device with the MQTT firmware (hopefully what you've selected) and setting the Wi-fi connection parameters, there should be a link on the last page of the firmware flasher to "Access your ratgdo." If it seemed to connect to the Wi-fi successfully and you don't see this link, or if the link doesn't seem to work, then you can access the ratgdo configuration web page directly through your browser at http://<ip address of ratgdo>. You may have to go out to your network router to find the IP address. Look through your connected devices for a newly added "espressif" device (how all ESP32-based devices show up in my router) to get the IP address. On this configuration page, you have to provide a password (don't forget it!) and this is also where you will specify your MQTT broker info. Follow the instructions in the Release Notes and Instructions for the ratgdo Plugin for configuring this (reproduced below for your convenience): Make sure the "Enable MQTT" checkbox is checked. Set the "MQTT server IP" to the IP address of your Polisy or eISY (unless using an alternate MQTT broker). Set the "MQTT server port" to 1884 (unless using an alternate MQTT broker). MQTT server username and password need not be changed if using the default Polisy or eISY broker. Leave the "Home Assistant Discovery Prefix" set to "homeassistant" unless you changed it for your configuration - see discussion of the "discoverytopicprefix" Custom Configuration Parameter in notes below.

I had a friend that had this same issue. He tried everything: Mac, PC, drivers, different cables. Then I took my laptop and cable that I used to configure mine over to his house and tried and got the same thing. Just a bad device, I presume.

That makes sense. I’ll have to think about how we should be handling that, but I will log a change for the next version.

But… thinking about this, when it comes online it won’t repost its state values (the ratgdo uses retained messages) and there is no periodic query of state, so if it does go offline and the states are set to unknown, they will remain unknown until they change (assuming the ratgdo is back online when the change occurs).

Should only happen if the ratgdo devices go offline.

I've had put in a note to fix it in next release. But as I mentioned, it is a non-fatal connection error very infrequently returned from the Schlage API the plugin uses, and the data is updated on the next poll. But it adds the notification when the error occurs. So even though it's logged as a warning and the plugin recovers on the next poll, the notification just hangs out until you clear it. Shouldn't cause any issues in the operation of the plugin.

If it is “built upon … ratgdo software libraries” like it claims, it may be easy to work it into the ratgdo plugin.

If we could get the query to work in the ratgdo firmware, that would help too.

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.

No worries. And I did take away your vote for option 2 (sans the separate node 😜). But now that I think about it, there's absolutely no reason not to do both option 1 and option 2 at the same time, so that's probably what I'll go with.

I addressed the idea of the “motion” node in the text above. Would just be an extra node that always said “online” but otherwise never generated a node event for the majority of users.

Selecting "Chat with a specialist" at the bottom of this page: https://www.resideo.com/us/en/support/

I chatted with Resideo support. They can see my thermostats and the "ISY Node server HomeAutomation" app or integration. This particular support rep doesn't seem to think anything has changed on their end. I wonder if the current problem lies with the authorization step. It asks you to specify "https://udi-honeywellhome-auth.azurewebsites.net/auth" as the authorization callback. This appears to be a website created by the original developer dbarentine 5 years ago. I wonder if it still functions? Sounds like this plugin needs to be brought up to newer standards and more tightly integrated with UD's oAuth and websocket infrastructures. Still doesn't explain why resideo support is not responding to password reset requests, however.

I believe this plugin was ported from PG2 by @bpwwer several years ago. I don't believe the original developer is involved at this point.

So you can no longer log into https://developer.honeywellhome.com/?

Looks like the ratgdo developer is not interested in changing (or discussing) the fact that motion will only and always report "detected" status. He implies it is intended to be just an "event" -- not a state -- suggesting this is how other motion sensors work. Of course, this is clearly not how it is documented. Further, since the MQTT motion messages are retained, then every time anybody initially subscribes or reconnects, it will look as if a new motion "event" has occurred. So we can do one of two things: 1) Keep motion as a state and have the plugin set it "cleared" 60 or so seconds after the last "detected" event; or 2) send a command (e.g., DON3) from the GDO node every time the "detected" event is posted and remove the motion state from the node. I can try and deal with the initial motion "event" on plugin restart/reconnect. I don't really want to add a "Motion" node, because there is really no way to know if the installation has a motion detector and so it would just be an extra node with "Unknown" state for the majority of users. Let me know what folks think.

Appears to be periodic REST call failure that I’m not handling gracefully. Since it’s an authorization error it’s also posting the notification that’s never getting cleared. if you can turn on debug logging and capture more info, I can release a new version that ignores the periodic error.

Is it otherwise working?

Followed the procedure for PG3x migration from here: https://forum.universal-devices.com/topic/42072-pg3-to-pg3x-migration/#comment-372757 and got stuck on the same screen as the third post in this thread: "Not connected to server... Try refreshing the page. This will disappear once the connection is re-established." Multiple reboots with hours in between over a 24+ hour period didn't clear it. Solution: Required that I click "Logout" in PG3x, and the log back in with the default (admin/admin) credentials. Unfortunately only figured this out several minutes after posting here. Just to add additional information for others, the reboots were of my Polisy. I didn't reboot my computer (or even shutdown and restart the browser, evidently).

Unlike the other status, the ratgdo firmware only appears to write out the motion status if the status read from the MyQ controller is 1 ("motion"). Specifically: if(motionState == 1){ sendMotionStatus(); motionState = 0; } All of the other states are like "if(doorState != previousDoorState) sendDoorStatus();". I can log an issue for this on ratgdo Github page. In addition, the state is retained, so it won't ever go away. One possibility is just to generate some command everything a new motion "detected" status message is posted, as opposed to having a "Motion" state value. We could generate a, e.g., DON3 command and call it "Motion" for programming purposes.

Looks like it increased sensor debounce delay in "dry contact" mode and added something having to do with reading light and lock values from sec+1. I don't see anything directly affecting the MQTT interface with the plugin, so if yours ain't broke, then... https://github.com/ratgdo/mqtt-ratgdo/compare/2.56...2.57#diff-671002be345249c9b06f425aa29425086964ffd1e884c80db89c392089a3b21bL69

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.