Goose66

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.

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.

Can you DM your Plugin log to me?

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.

Working for me: "Alexa, open Tesla garage bay door" and "Alexa, close Tesla garage bay door" both work. Must be a problem with your Portal account. I suggest opening a ticket.

Adding to my ratgdo experience, one of the things that was extremely frustrating with MyQ is that, at least in my case with the IoS app, when you opened the MyQ app you seemed to get one open or close action, and then any subsequent button presses would just "spin" without performing the command. I had to close and reopen the MyQ app frequently if I wanted to do two things in one "session." The UD Mobile->IoX->ratgdo plugin->ratgdo does not have this problem. The garage door(s) respond instantly to open and close commands, the status is updated right away, and I can fire off multiple commands in rapid succession if I want, even when my iPhone is moving between Wi-fi and 5G. Appears to be a much more stable communication architecture.

This is now working in v3.1.4 of the ratgdo plugin.

Are you running the ratgdo plugin and does the Garage Door node show up in IoX? Is your Garage Door node showing up in the "My device" dropdown in the Connectivity->Amazon Echo window? After you setup the spoken in the UD Portal under Connectivity->Amazon Echo window, did you ask Alexa to "discover devices" again?

@bmercier can you answer a few pertinent questions here: 1. Are doors/gates specifically supported in the Alexa Smart Home Skill? 2. Are there any requirements for nodes to make them identify as doors? Node hints, specific drivers, etc.?

I have two T9s as well and, while they are still working through the plugin, I am worried about continued support. Ecobee is currently supported by plugin but requires a cloud service connection similar to the Honeywell, although I believe the API is public and supported. Venstar ColorTouch thermostats also have a plugin and are local (no cloud service), but they are expensive. I am currently working on a Nest plugin for the Nest thermostat that will require a cloud service connection and either 1) fees to be paid for by UD or other to support the connection or 2) each individual user to pay $5 and setup a Google developer account similar to the Honeywell thermostat plugin. Frankly, while I don't have any anymore, the most reliable and completely local thermostats I have had in my system were the Insteon thermostats. If I were looking into something completely new today, I would look for a thermostat that had the possibility of Matter support in the near future. That may be a Nest through the cloud service, or it may be a ZWave/Zigbee thermostat or Wifi-based. Unfortunately, there are not any good Tasmota thermostats (or basic thermostat support built into Tasmota as of yet).

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.

I have published a new version of the ratgdo plugin (v3.1.4). This version detects the base MQTT topic prefix for each ratgdo device, so no need to configure a prefix. In addition, the GDO nodes and Light nodes now generate DON and DOF commands when there status changes in order to make the nodes usable in scenes - see the release notes for details. !!! NOTE !!! This is a braking change, and you must delete your nodes in the PG3 Dashboard and re-add them through Discovery again. They will have the same node addresses, however, so all your programs should work without modification.

That doesn’t make a lot of sense. To be a scene controller, the node has to send commands on events, e.g., when the door is opened (presumably through means other than an IoX command to the node), the GDO node will send a DON command to IoX. This is primarily used for devices that sense direct user interaction, e.g. a switch. I don’t understand how lack of this capability would affect Alexa’s ability to control the door or put it in a routine?

If it has a browser and a GUI, then sure.

If you just go to automationshack.com you should be able to navigate to what you need.

Is this using the ratgdo plugin? I can look into it. One reason I didn’t add it originally is that there is no good way to differentiate when the status changes because the plugin sent a command and when the status changes because another device sent a command.