Goose66

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.

@EWhitesend them on when you have a chance

This comes down to design approach. In order to get it out quickly, the first version of the ratgdo plugin was based on the Tasmota plugin. The Tasmota plugin, like the ratgdo plugin, can support any number of devices. In order to simplify management of MQTT subscriptions for an arbitrarily large number of device, the Tasmota plugin relies on a top-down topic format, i.e., a broad topic prefix (in this case "tasmotans/") that supports a single subscription, and then narrowing topic segments for device ID and finally message type ("STAT", "CMND", "TELE"). Without this top-down topic format, you would have to create and manage separate subscriptions (and more specifically three distinct subscriptions) for each Tasmota device. If you were to have, say, 100 Tasmota devices in your HA system, you can see how this may get ungainly. The Tasmota plugin actually has a Custom Configuration Parameter for changing the broad topic prefix (though it's not documented), but allowing the full topic to be configured is not supported because of this top-level topic subscription limitation. The ratgdo plugin, however, only really supports ratgdo devices, and this limits the total number of devices it would support, and thus the number of MQTT subscriptions that would be needed for each device to have its own subscription(s) (one command and one status topic per device). So getting rid of the need for top-down topic format is doable in this plugin. In fact, the HA discovery messages that are published by the ratgdo devices contain their command and status topics in the payload, thus no specific configuration of MQTT topics through Custom Configurations Parameters would be needed. As long as the topics you have configured work with Home Assistant and the HA discovery process, the ratgdo plugin should be able to get them in discovery and use them. This is already on the roadmap for the plugin, and, while it's not a trivial change (the GDO nodes have to be coded to remember the topics and set their own subscriptions upon plugin restart), it should be included in the next release (3.1.x). It will mean you will have to delete your nodes and rediscover them when this release comes out, but all of your programs should continue to work.

@EWhite It appears to be based on the Sonoff Basic module. While I’m still learning all the ins and outs of Tasmota, unfortunately, this doesn’t tell me much. Without one here to test with, I would need complete documentation of the MQTT topics and payloads that it generates and/or consumes, including the discovery messaging, preferably with discovery set to Tasmota protocol as opposed to Home Assistant protocol.

Answering my own question, it doesn’t look like it supports Tasmota. I thought Eve devices did.

Can you flash the Eve motion sensor with Tasmota? If so, you can get it working with the MQTT plugin, or I can work with you to add it to the Tasmota plugin.

It’s fortuitous you mentioned that. If you go from the documentation to the Github project using the link on the page (https://github.com/PaulWieland/ratgdo), you get to a project with no issues or discussions. So I was thinking there wasn’t a lot of movement on the firmware. However, after reading your post I did a Google search for “MQTT” and “ratgdo” and found the GitHub project you are referring to. I will get some of my issues posted.

The ratgdo device firmware definitely has some problems - not making the configured device name have to be a valid MQTT topic is just one of them. Another one is the retention settings for the state messages. Hopefully, when he can catch up with deliveries, he will circle back to the firmware.

You need 3.3v so don’t know if you are getting that out of any GDO. There are 3.3v power supplies out there, however, with micro-USB connector or can be wired into the ratgdo directly. Look for a 3.3v one for an Arduino.

Problem 1 - Door State: fixed - even though I had changed the profile and code to use the Index UOM (25) for door state, since the nodes were created in v3.0.1 of the plugin, they are stuck in the PG3 database with the Barrier Status UOM (97). IMHO, state values should never be stored in a database for any reason, but in this particular case it means there was only one way to fix it: delete all of your nodes (in PG3 dashboard), restart the node server, and perform Discovery again. Instead, I just forced the code to report the door state explicitly using the Index UOM every time it is updated, so the two of you won't have to recreate your nodes. Problem 2 - Lockout State: fixed - had an "if" that should have been an "else if". Thanks for the testing!

I have published a new version of the ratgdo plugin (v3.0.3). This version fixes the lockout status (no really this time) and forces the door state to utilize the index UOM everytime it is reported so users of the 3.0.1 version don't have to delete their nodes and start again.

Probably best for feedback in a new topic for each major issue. This relates to the change in UOM of door state from built-in Barrier Status to a custom index UOM. It looks like, despite having upgraded the plugin, that your Admin Console is still using the old profile with Barrier Status. Restarting the Admin Console should clear it up. If not, you may need to reload the Profile for the plugin in the PG3 Dashboard and then restart the Admin Console. The joys of being an early adopter! 😁

Multiple options are good. I myself have gone back and forth on the idea of making one plugin that works with everything that Home Assistant works with via MQTT and utilize the Home Assistant MQTT discovery protocol vs. making individual plugins for individual manufacturers or devices, and trying to be as "native" to each as possible. My current thoughts are (number of plugin slots notwithstanding) that plugins that support as close to out-of-the-box, native devices as possible (even if they all use MQTT) AND map them to familiar Insteon/ZWave/IoX interfaces that we've come to know and understand serves the most people. And individual plugins developed by a group of developers is probably the best way to achieve this. But more options are always good, because not everybody has the same goals, level of expertise, or, frankly, time to put into it that some of us do. 😁

I have published a new version of the ratgdo plugin (v3.0.2). This version fixes the lockout status so that it works correctly and changes the door state from the built-in Barrier State UOM to an index UOM with specific defined door states to make programming easier through the IoX programming UI. You may need to stop and restart your Admin Console to pickup the profile changes for the door state to display correctly.

Here is my anecdotal Insteon experience from the last 12 years: If I have individual commands in a program, I can just enter them sequentially in the Then or Else branch and it seems to work. If I have multiple scenes, however, I will generally put a wait between them of 2 or 3 seconds. I think this is because the sequence that Insteon uses for scenes (send scene command broadcast, then follow up individually with each device) takes multiple zero-crossing cycles to perform. Also, for my Holiday Lights programs and my daily/nightly lighting programs, I execute an On on the scene, wait a minute, then execute the On on the scene again. This frequently cleans up stragglers that may be multiple hops down the communication path that never receive the initial signal because of the noise that is generated from turning on all these LED power converters at one time.

Are you turning them on or off individually in your scheduled programs or through scenes?

I see the lockout status problem - will be fixed in next release. So what does motion change to? Does it change to undetected after a certain amount of time? Or does it just send "detected" messages when motion is detected. Note, one way to test would be to close MQTT Explorer and then reopen it and see if "motion = detected" is no longer under status (indicating that motion is not a retained state).

Excellent. As far as motion, I don't see anything in the ratgdo MQTT documentation that references motion, nor do I see anything in the discovery messages from the ratgdo device that indicates a separate motion sensor. There is a binary_sensor of class "motion" for the occupancy sensors, and those should be working. Let me know if you are seeing something different.

Also, did you change the "MQTT Topic Prefix" on your ratgdo to "ratgdons/" as instructed in the very detailed release notes here: https://github.com/Goose66/NSDocs/blob/main/ratgdo-pg3.md

Well "kinda" was certainly not what I was going for. Can you DM me your log file?

How many plugins does your Production Plugin Store show? It should show 118 plugins. Again make sure you are looking all the way down to the bottom of the list.

It's in the Production store and called "ratgdo." Since it's all lowercase, it's all the way down at the bottom of the list (somebody doesn't know how to sort database entries). It was added just this afternoon, so you may need to refresh your Plugin Store list.

Adding a topic to discuss experiences with the ratgdo device. My experience: Took 5 1/2 weeks from ordering (Nov. 6) for my ratgdo device to arrive. Initial flashing and connection to my Wifi using Chrome browser, Windows 11, and a USB->micro USB cable was very easy. Configured it for my test MQTT broker and played with it using MQTT explorer to put it through its paces. However, the built-in configuration website is somewhat brittle. If you enter something wrong, or if you forget your password, you are stuck reflashing it to regain access. Of course, this time, if you are like me, it will be done with a laptop from the top of a ladder, so not quite as easy to do subsequent changes. The passwords for OTA and Wifi connection are hidden, with no "show" or "reveal" functionality, so it's easy to mess them up and "brick" the device (especially one handed from the top of the ladder). In addition, each time you flash it, it picks up a new Device Name, so watch for that. Mine is hooked up to a Genie Screw Drive Pro (CM7600IC) so it is in "dry contact" mode. My GDO unit doesn't have exposed terminals for the door position sensors, but I was able to use tap splices on the cables from the door sensors to hookup the sensors to the ratgdo terminals and door status works perfectly. I only get door open, close, and stop functionality from the ratgdo, but my keypad has separate light and lock controls and those continue to work even with the keypad connected through the ratgdo. The obstruction sensors were too high of a voltage (12.95v) so I couldn't hook them up. The status changes and commands are instantaneous - no cloud service or polling latency here. So the ratgdo plugin is already more capable than the MyQ node server was. There is no delay with beeping alarm when closing the door, which I thought I would like but is actually a bit unnerving when closing the door remotely. Also, I haven't thought through all the security implications here, and with holidays coming up I am unsure of whether I want it online while I'm not here. However, the lockout button on my keypad seems to lockout the ratgdo as well, so maybe just manually locking the doors when we leave will have it covered. I am ordering ratgdo devices for my other doors now and taking down the MyQ Smart Garage system and I guess chucking it in the garbage. I hope to work with the developer to add light and lock control to my Genie GDOs from the ratgdo, as well as improve the discovery process so that the plugin is better at creating the requisite nodes based on your installation.