Goose66

What happens when you try to go to http:\\ratgdov25i-4b1a56.local in your web browser?

A new version v4.0.8 of the ratgdo plugin is available in the Plugin Store. This version has a couple of major changes: 1. It is designed to work with the ESPHome firmware through the ESPHome REST/Event Source API. The ESPHome firmware is more up-to-date and supposedly does not have the eventual loss of control in MyQ Security+ 2.0 GDOs that the MQTT firmware has. 2. It has a one month trial and then is $10.95 perpetual license. This was released as a separate edition of the plugin: the "Standard" edition as opposed to the "Free" edition for the MQTT firmware. This was done so that it didn't automatically upgrade on users' installations before the users had a chance to flash their devices with the ESPHome firmware. The release notes have been updated for the new v4.0.8 version as well: https://goose66.github.io/nsdocs/ratgdo-pg3.html

Have no idea what an "A0" command is. Nothing in the (now ancient) documentation about such a command.

I just notice that, while this was posted in the Envisalink-HW forum, the title of the topic "DSC outputs." If you do in fact have a DSC panel with an Envisalink, then the answer is yes, the command outputs will work. Here is the Envsialink-DSC forum: https://forum.universal-devices.com/forum/340-envisalink-dsc/. If you have a Honeywell Vista panel instead, then I can add triggering outputs on and off in a future version. Whether or not I will be able to display the status of the output, though, is another question, and probably one I won't be able to determine (or add support for) because I do not have a relay board in my system.

The DSC version of the EnvisaLink plugin does have output (command output) nodes, but this was never added to Evisalink-HW. IIRC it is because the EnvisaLink HW API didn’t support it, but I can look into it. If NodeLink was doing it, then it should be accessible.

Yes. I will try to get a working version of MQTT ratgdo plugin out soon, but that may be the last one. If all development for ratgdo continues on ESPHome firmware, that’s probably where the plugin will go as well.

The new IoX updates since 3.2.23 break the ratgdo plugin.

I will add this as a to-do for any future version of this plugin.

This turns out to be an issue with the recent IoX firmware upgrade. There was evidently an upgrade from Python 3.9 to 3.11, and with it, and upgrade of the Paho MQTT client library to v 2.0. The Paho MQTT client library upgrade included breaking changes. Why in 2024 would someone roll out breaking changes to a widely used Python library? Who knows, and we're probably lucky if this is the only breaking change. So I need to complete testing of the ESPHome firmware version of ratgdo (probably rolling that out as a separate plugin or different edition) and then I can look into reverting the code back to MQTT version and make changes in the Paho MQTT client library calls. Honestly, though, there may not be any point in it if everybody is ok with upgrading to the ESPHome firmware.

TLDR, this boils down to a design decision. Nodes can both receive commands and send commands. So for, e.g., shades I would have the plugin process received DON commands to open the shades and close the shades, but the shades node would not send any commands. However, the keypad nodes in the Bond plugin send commands, e.g., DON commands, when pressed, but don't receive any commands. Generally, in my plugins, if it is a button, switch, or sensor, it will send commands and if it is a relay, dimmer, motor, etc. it will receive commands. If it is both (like an Insteon light switch) then it will both send and receive commands. There are a few exceptions: thermostats and garage door openers that are kind of both sensors and relays. In those I have to add a layer of complexity to ensure I am not sending a command back to IoX when the status change is a result of command received from IoX. The type of connection to the device (synchronous vs. async) drives how complex this actually turns out to be. If you want to sync a KeypadLinc with your shades position, I suggest using programs with the status value, much like you would synching a KeypadLinc with, e.g., a FanLinc.

@hart2hart A version of the ratgdo plugin for ESPHome firmware will be completed this weekend and rolled out early next week (probably Tuesday).

Well that is supposed to only happen when you click Discover before giving the plugin time to connect to the MQTT broker after plugin start. If it’s not connecting, then there should be some type of error in the log. Send your log file. But I did something that in hindsight was probably not smart: I coded a new version of the ratgdo plugin that is built on the ESPhome firmware on top of the old MQTT version. I need to finish testing the ESPHome version, roll it out as a separate plugin, and then I will have to revert to old MQTT version before I can fix any errors in that version.

When do you get the message and do you get it over and over or just the one time?

Glad it's working, but there aren't many reasons why your ratgdo would be so sporadically responsive short of 1) it's connection to your wi-fi network is flaky or 2) the network radio on the device is flaky. So you may want to put in the due diligence so you can return it within a reasonable period for another unit if it turns out to be the radio.

You may want to ask for a replacement.

You may find more answers on the ratgdo github pages or in a HomeAssistant forum.

There is no way to query the panel (at least through the EnvisaLink) to determine which zones are “used.” The only way is to set the “numzones” Custom Configuration Parameter to 18 and restart the plugin. Upon restart, it will generate 18 zones in the node tree. Unfortunately, even if you delete the unused zones in the Admin Console, they will be regenerated when the plugin is restarted. Perhaps I can add a to-do to only generate new nodes based on the Custom Configuration Parameter settings when the user clicks the “Discover” button in the Polyglot Dashboard.

Before entering an SSID, try let it ruminate for a minute to see if it will detect your WiFi and show it for selection. This should eliminate the 5Ghz/2.4Ghz issue as well.

Make sure you are using a data cable. Many usb-a to micro-usb cables are for charging only and have the data lines cut. Once you find one that works, stick with it. The ratgdo doesn’t have to be attached to the GDO to flash the firmware, so just sitting at your laptop at a desk is the best way to troubleshoot. Once it’s flashed and wifi is configured, it should keep the same IP address after you move it to the GDO.

You can test #1 by moving the ratgdo closer to your WiFi AP for firmware installation.

Does the firmware installation dialog ever proceed to the page where it shows you available SSIDs? if not, it sounds like one of two problems: 1. The WiFi signal strength at the ratgdo installation position is insufficient, or 2. the WiFi radio on your ratgdo is broken.

How many Wi-fi bars on your phone at the same location you are installing your ratgdo?

Mine is on a “good night” routine. I tell Alexa “I’m going to bed” and it does all the stuff. That gives me a chance to consciously think about context before doors moving, alarm arming, thermostat changing, etc., although it’s not really “automated.”

I'm not sure. I am using dry contact mode and don't experience the problems that show up in the Security+ 2.0 openers. But at least according to @sjenkins the ESPHome firmware works (better), and the MQTT firmware hasn't been changed in 3 months, whereas the ESPHome firmware was updated 3 weeks ago. So looking to see if there was an easy way to interface with the ESPHome firmware instead of the MQTT firmware seemed prudent.

tl;dr: I'm working on it. Yep. Looks like MQTT firmware is dead - although there is no confirmation from Paul Wieland on this. Most recent activity is on the ESPHome firmware. But there are gotchas there as well (see some of the discussion above). For example, the ESPHome firmware reboots itself every 15 minutes if the Native API (Home Assistant) is not being used. According to Paul, this is "by design." So if you want to use another API for the ESPHome firmware (e.g., REST/SSE) you have to trick the firmware into thinking it has a Native API connection as well to keep it from rebooting. Alternatively, if anybody here knows how to change yaml files local on their ratgdo devices (in a way that could be explainable to other users), we could set a flag to prevent the rebooting (or, even better, turn on the MQTT interface in the ESPHome firmware) and get a plugin running against the ESPHome firmware rather quickly. However, I don't relish the notion of forking the firmware and maintaining a completely separate version to support the UD plugin.