Goose66

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.

Just refresh your Plugins Store. It's there.

We don't need an updated version of the pyschlage library to implement this functionality, so I went ahead and rolled out a new version 3.2.4 using the older library that adds the requested functionality. Let me know if it works for you.

A new version v3.2.4 of the Schlage plugin has been uploaded. This version adds last message time, last message, and last used access code state values from lock nodes. Remember that this plugin relies on polling of a cloud service, so changes to node state, like an access code being used to unlock the lock, may not show up to up to 60 seconds or so after it occurs. Please don't set the polling intervals too low to capture this information any faster, because frequent, repeated polling may cause Schlage to start blocking access (a la MyQ). Instead, try and find some other event, e.g., a motion sensor, that may indicate that someone has entered or exited through the door, and in a program use the Force Update command to refresh the state of the lock before checking the state values for further action. See the Release Notes at https://goose66.github.io/nsdocs/schlage-pg3.html for more information.

I uploaded a new version of the 3.3.15 zip file to the Production Plugins Store. If you upgrade one last time, it should stop posting the message. Also, I updated the release notes for the 3.3.15 version.

Sure. Not released yet, though.

@JBalog Was this resolved? Also, did you delete and rediscover your devices after installing the update?

Does the Bond Home app show more commands than just Open or Close? Also, what is the device type up at the top of the node details in the Admin Console? A Shade should never show “On” or “Off,” but “Open” and “Close” (at a minimum). Adding a screen grab from the Admin Console would be helpful.

The docs suggest it may be a Pro only thing, but you can try deleting and re-discovering your shades to see if they show up as having position support.

I’ll take care of this in the patch. Let’s see what else shakes out this week.

Do you have a Bond Bridge Pro?

Look here:

Look here:

A new version v3.3.15 of the Bond plugin has been uploaded. This version adds enhanced support for shades (see below) and adds the ability to restart the BPUP listener thread and connection to the bridge if it fails for some reason, e.g., network troubles or power loss affecting the Bond bridge but not IoX/PG3. I have no real way to test these changes since I don't have any shades, so before I update all the documentation for this plugin, if a few of you (e.g., @tlightne and @JBalog) can bang on it for a few days and let me know what isn't work, that would be great. I can roll out a patch to fix any issues before updating the Release Notes. This version adds several commands to basic Shade nodes: Start Opening, Start Closing, Stop (Hold), Toggle Opening, and Preset Opening. The "Stop (Hold)" command stops the shade when in motion from an open or close command. Because most if not all shades have no way to report position back to the bridge, then status generally changes to "Open" when the "Stop (Hold)" command is used. "Toggle Opening" is pretty straight forward. "Preset Opening" opens the shade to a preset level (set by the shade remote) and is referred to in bond as "My" for some shades. These commands may or may not work for different shades, and if one doesn't work, a Warning may show up in your plugin log. On some shades, if the "Stop (Hold)" command is issued when the shade is not in motion, the "Preset" functionality is invoked (the likely case when the remote only has one button to perform both functions). "Start Opening" and "Start Closing" just call open and close, respectively. However, "Start Opening," "Start Closing," and "Stop (Hold)" map to FDUP, FDDOWN, and FDSTOP IoX commands, respectively. So the theory is you can drop a shade into a IoX scene with a Insteon SwitchLinc, and get easy control: tap top of switch to open; tap bottom of switch to close, press and hold top of switch to start opening, release switch to stop opening, etc., all without programming. If anybody can test this, that would be great. For shades that support positioning, there is a new Shade node that adds a "Set Position" command along with "Increase Opening" and "Decrease Opening" commands that increase or decrease opening by 10%. This node also reports the position as a percentage if not fully "Open" or "Closed." Several Notes: The Bond Home app and Bond API report position as a percentage of "closed," i.e., 0% is open and 100% is closed. IoX "Barrier Status" UOM reports position as a percentage of "open," i.e., 0% is closed and 100% is open. The conversion is done in the plugin so you should keep this in mind. If you have a shade that supports "Set Position" commands, either because it's native to the shade or you've set the "Course Time" in the Bond Home app for the shade and the Bond Bridge Pro is tracking it's position, then you will need to delete the existing shade nodes and the re-discover nodes from the bridge to get them to load with the right node definition. Let me know what works and what doesn't.