Goose66

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.

Honestly, I don't know. @bmercier, is this an ongoing issue? Could this be related to the fact that the trial is a "Free" edition where the perpetual license is a "Standard" edition? I have several like this and frankly never really grokked the "edition" thing. However, if he uninstalled the Free (trial) edition plugin and then installed the Standard (perpetual license) edition, it shouldn't matter, right?

The EnvisaLink does not report the number of configured zones or partitions for your panel. The number of zones and partitions present are driven by Custom Configuration Parameters. From the Nodeserver Configuration instructions (read the "NOTE" at the end): Custom Configuration Parameters: Required: - key: hostname, value: locally accessible hostname or IP address of EnvisaLink or DUO device (e.g., "envisalink.local" or "192.168.1.145") - key: password, value: password for EnvisaLink device - key: usercode, value: user code for disarming alarm panel (e.g., "5555") Optional: - key: numpartitions, value: number of partition nodes to generate (defaults to 1) - key: numzones, value: number of zone nodes to generate (defaults to 8) - key: numcmdouts, value: number of command output nodes to generate (defaults to 2) - key: disablewatchdog, value: 0 or 1 for whether EyezOn cloud service watchdog timer should be disabled (defaults to 0 - not disabled) - key: zonetimerdumpflag, value: numeric flag indicating whether dumping of the zone timers should be done on shortpoll (1), longpoll (2), or disabled altogether (0) (defaults to 1 - shortpoll) NOTE: On nodeserver start, the child nodes for the Alarm Panel are created based on the numbers configured. The disablewatchdog should be enabled if the EnvisaLink is firewalled to prevent the EnvsiaLink from rebooting after 20 minutes. Sounds like these are missing in your configuration. However, you said it used to show 1-16. Had it been configured to generate 16 nodes at any point, the plugin itself would have never deleted them - it would have just stopped updating them with status values when the "numzones" configuration parameter was changed (or removed). The only way nodes for zones 9-16 could have been deleted would have been if you explicitly deleted them in IoX or PG3x Dashboard or if you deleted and reinstalled the plugin.

This release fixes several issues, including an issue that could prevent you from being able to reauthenticate without having to delete and reinstall the plugin. However, to install this version (and prevent the reauthentication problem) you need to delete and reinstall the plugin. This will restore the default installation data (including the oauth configuration data). It should also give you the opportunity to pick up the correct node names.