Goose66

As far as UDI Mobile, I get this: Try re-syncing UDI Mobile.

For most folks with their ratgdos on the LAN, you shouldn't need the Custom Configuration Parameter. It should simply discover them using mDNS service browsing and connect directly to them. That's the part I wanted to try and debug. But I'm glad it's working for you.

Glad is working, but I could use some help in diagnosing the original problem. If nobody can use the automatic discovery then I did something wrong.

Take a look at latest couple of posts in this forum.

No, you have to specifically install the ESPHome firmware. Go to the ratgdo Plugin Release Notes and Instructions for the details and website.

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.