Goose66

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.

Given everything that happened with Chamberlain and their intentional blocking of non "trusted partner" access to their control API, I am disabling the MyQ plugin in the Plugin Store. After some time, I imagine it will be removed. For an alternative, fully local and instant status (no polling) solution, check out the ratgdo device and the ratgdo plugin here: https://forum.universal-devices.com/forum/436-ratgdo/.

Cleanest solution here (and just about all other instances with motion/presence triggering events and timed activities) is the two program solution: First program: Utility Room Motion (Enabled) If 'Wireless Tags / Utility Room Sensor' Event State is Detected Movement Then Run Program 'Utility Room Lights on Motion' (Then Path) Else - No Actions - (To add one, press 'Action') Second program: Utility Room Lights on Motion (Disabled) If - No Conditions - Then Set 'Basement / Utility Room' On Wait 15 minutes Set 'Basement / Utility Room' Off Else - No Actions - (To add one, press 'Action') When the Wireless tag sends movement, the first program starts the second program, and the second program turns on the lights, starts the timer, and turns off the lights when the timer expires. Subsequent motion from the Wireless tag turns the lights on again and resets the timer. 15 minutes after the last motion detected, the lights turn off. An advantage to this structure is that it works whether or not your Wireless Tag (or other motion detector) sends a DOF (No Motion) command after some delay.

Mine is dry contact mode and I never get light or lock status. But that’s not really germane to my point. To the point of initial status, when you start the plugin, the initial subscription to the MQTT should cause any retained messages to be sent. For example the plugin gets the online status right away. In my case, however, I don’t get a doorstate until the doorstate changes. And if IIRC, when I shutdown MQTT explorer and restart it, the door state is gone until the state changes. I can look at it when I return on Jan. 2. Moreover, there doesn’t appear to be an MQTT command I can send that forces the ratgdo device to update all states (e.g., as in the case of Tasmota), so we may have to log an issue with the ratgdo developer to either add such a command or change the retention of the state messages.

I’m not seeing that from my ratgdo connected to my Polisy MQTT broker.

I would say not feasible. At minimum it requires knowledge of object-oriented scripting languages and a basic understanding of how to read and interface with an API. It’s not really structured for non-programmers. i would try the built-in programming paradigm with the Networking Module first. That requires knowledge of Internet protocols: TCP/IP, HTTP, MQTT, etc. A more focused body of knowledge to sink your teeth into.

If you restart MQTT explorer, do you still see all of those statuses? Or is it only after MQTT explorer has been running for a while that the all get values?

As to firmware or plugin? As far as the plugin is concerned, I want to change the discovery process to pickup the configured MQTT topics for the device(s) so that folks can have it work with IoX and Home Assistant at the same time. I’m am waiting to see if any firmware changes or issues crop up to include in the next release.

Going through the code and the two log files you sent more thoroughly, it appears to work the way I understood it to work above. What you are saying is happening and what I see in your log files and in the code just don't comport. It appears that the "name" of hardwired temperature sensors comes from the selected type, where wireless sensors have a separate, configurable name. It further appears that, after initial discovery, the names (not the addresses) of the nodes (both thermostat nodes and sensor nodes) were all changed in the Admin Console, and somehow these name changes propagated their way back into the PG3 database. I can see this in your log file(s) on the initial loads of the nodes on restart of the plugin. Now, this is not supposed to be possible, unless you modify the PG3 database directly. Another possibility is that an update to the Thermostat firmware changed the way the thermostat reports the sensor names through the API, but this doesn't seem likely given the specificity of some of the current node names. Moreover, with the node names of the sensors like they currently are (i.e., 'Internal Temp sensor', 'Outdoor Temp Sensor', 'Attic Temp Sensor', and 'Media Temp Sensor') and the thermostats returning the names of the sensors as "Thermostat", "Outdoor", and "Remote", there should be no way that any of the sensor nodes are having the proper temperature reported. I think the only way to make sure it is all correct is to delete all of your Thermostat and Sensor nodes from the plugin using PG3 Dashboard (allowing the change to propagate to IoX), restart the plugin, then perform the discovery again. All of the nodes when recreated should have all of the same node addresses so your programs should all work correctly. I believe you should be able to change the names for thermostats and temperature sensors that appears in IoX through the Admin Console without changing the names from discovery in the PG3 database, but I am checking on that with some other folks.

I have to go back to the code again - thought I understood how it worked.

Look at the third entry of the log entries you posted above. The Thermostat is reporting it as “Outdoor” instead of “Outdoor Temp Sensor”. So it can’t match it up.

It needs to be renamed in the Venstar thermostat.

It appears that the names of the sensors from Venstar thermostats were changed after the Discovery process that found the thermostat(s) and created the nodes. For example, the sensor node for the Outdoor temp was initially created with the name "Outdoor Temp Sensor" but now appears to be called "Outdoor." Because the remote sensors are separate nodes, they have node addresses that are an extension of the thermostat node address, and the way the plugin links them back to the node is through the name, so the names have to match what the original node has. Two ways to fix this: 1) change the names of the remote sensors back to what they were (you can see these names in the Node listing in PG3 Dashboard) or 2) remove the node and rediscover the thermostats. If choosing #2, remember that the dynamic discovery no longer functions because of a change made in PG3/PG3x. I need to fix that, but in the meantime you can just list the hostnames/IP addresses of your thermostats in the "hostname" Custom Configuration Parameter (separated by semicolons) and then click "Discover" in the PG3 Dashboard to recreate all the nodes. The nodes should retain the same addresses, so your programs should all continue to work.