Goose66

Unfortunately reading through this topic I can’t tell what the final solution was. Perhaps @tjmeiner can clarify how they fixed it.

Polisy or eISY? What version of the Schlage plugin?

Never mind. The information originally posted was for Gen 1.0 devices, which won't be supported.

I started on a MQTT version of the plugin that would require every Shelly device to be configured to connect to the eISY MQTT broker. But you can sort of already do that with the MQTT plugin. So was going to try something more native so you could discover and use installed Shelly devices “out-of-the-box,” but never really made much progress. The Shelly devices I have installed here actually have Tasmota flashed on them. Perhaps I can complete the MQTT version and roll it out and followup with a version 2 for more native support. The capabilities and node definitions would basically be the same - just more plugin-specific configuration of each Shelly device needed for the MQTT version.

I think ecobee is a @Jimbo.Automates plugin.

Many of the plugins have what you are asking. The plugins I have developed that use cloud services (iAquaLink, Schlage, MyQ, Nest, ipool) should all have a node that represents the cloud service connection with connection status. Others have done the same.

This is a design decision made by each plugin author. IMHO, the right answer is for each plugin to report statuses (running, connected to cloud service, authenticated, stopped, failed, etc.) that are common across most plugins and have this displayed and managed in the Admin Console, e.g. under the Plugins menu. Unfortunately this require a rework of the Plugin interface - preferably by ripping out the old Node Server REST API layer and linking the plugins directly to IoX via MQTT (a layer that already exists). The nodes are supposed to represent devices.

Don’t know what to tell you. Obviously the plugin hasn’t changed in 14 months, including the “profile” files, and it seems to have been working before. I would think something has changed in UD Mobile and the way it interprets profiles from a recent update, and that is likely the problem. If there is some new format for plugin profile files that UD Mobile has changed to, I am not aware of it. Please open a ticket with UD to investigate, reminding them that the last code changes to the plugin was 14 months ago.

The erase is not as important as going through the setup steps to get the initial settings right so the Discovery process will work. See here and here.

The original issue just sounds like the “profile” for the plugin didn’t get successfully loaded. You could have loaded the profile from the PG3 dashboard and restarted the Admin Console to see if that straightened it out. However, now it sounds like the plugin setup is corrupt once you updated your ratgdo. I would suggest factory reset ratgdo, delete plugin, and then follow all the instructions again to install and discover.

I only did it once. It was the DSC1832 I had when I wrote the original PG1 version of the plugin. It had been installed by an alarm monitoring company (Loud). The keypads and everything was branded. The factory reset via pin jumpering technique took it back to default factory settings.

There is a way to factory reset the 1832 boards to default values (including passwords) by jumpering two pins in the controller chip.

Run the plugin with “Debug” logging level so we can see what it’s doing differently.

I think you need an EyezOn UNO4 expander as well. Never tested the plugin with this setup, though.

A new version of the plugin v3.2.10 has been uploaded to the Production Plugin Store. This version adds the ability to specify a user code for the Disarm command. If you do not specify a code, it uses the user code from the Custom Configuration Parameters.