Goose66

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.

Looks like there is a Python interface for the native API already available, but it's async! I have wanted an async version of the udi_interface for PG3 for years now. If only...

To support our (UD's) plugin, the MQTT firmware needs to support a query across all modes (Security+ 2.0, Security+ 1.0, and dry contact) and add state update on initialization of the ratgdo device. This would take care of the EISY reboot and power outages issues, respectively. There are issues entered in the MQTT firmware Github repository discussing both of these, but no word from Paul Weiland on any of it. I have a GDO (circa 2007 Genie Screwdrive) that's sounds like it's about to die. If I can replace it with a Security+ 2.0 MyQ model, I would have a testbed to perhaps doing a pull request and producing a UD-compatible MQTT firmware version. But very hard to justify that cost. If ESPHome has all of these issues solved, maybe an ESPHome version of the ratgdo plugin is not a bad idea.

There is a problem in the current version 0.1.3 that could affect the ability for a user to reauthenticate with the Google Nest Service (for whatever reason). It is a problem in the approach for updating OAuth configuration with Custom Configuration Parameters and a quirk of the asynchronous nature of the environment that may or may not affect a particular user. I am not sure if the fix will come in the form of an update to the plugin or a new version of the udi_interface module (or both), but just be aware that the problem exists if you are testing the Non-production (Beta) version of the plugin.

Working with @residualimages to step through some issues, and hopefully can correct some things with a new version soon, at least a new version of the Installation Instructions. However, I will point out that because this Beta version depends on the end user's ability to setup the requisite Google Device Access and GCP projects correctly, and because the procedure is long and complicated and prone to errors, the only reliable way to install and test and make sure things are working as they should, as well as move the process forward towards a much simpler UD "hosted" backend, is to follow the instructions for setting up the projects as laid out in the Release Notes linked above. We have found that going off that path, e.g., performing the steps out of order or utilizing existing GCP projects, seems to create problems - the Google Cloud Platform is, IMHO, unnecessarily complex and seemingly very fragile. I appreciate your patience.

The Nest SDM plugin uses the oAuth facility that was added to udi_interface 3.2.2. Not sure if that needs PG3x to run or if it's supposed to work in PG3 as well. I have sent a DM to Benoit asking about it. Right now that sounds right on your nodes. The nodes require a Discover call to populate them. This is so you could delete or rename some and they wouldn't reappear every time you restart the plugin. The Thermostat nodes have a fully complement of drivers, but the Doorbell and Camera nodes don't really have any driver values (except the camera clip for doorbell which is being fleshed out - doesn't work in Admin Console (and probably never will) and only works sporadically in UD Mobile). The Doorbell and Camera nodes do have events: Motion Detected (Doorbell, Camera) Person Detected (Doorbell, Camera) Doorbell Button (Doorbell) But you won't get these if you're not getting events from Google Cloud (see next paragraph). As far as the thermostats not updating, sounds like you are not getting events. I would like to get your log files (in package form please - not pasted here) to look for the event subscription calls. My bet is your getting 403 - Not Authorized errors. This is exactly what plagued us in trying to setup a Device Access Project in the UD Google Cloud account. What we did there, and it sounds like what you did, was tweak some existing things in the Cloud Project to get it working instead of following the procedure laid out in the instructions I posted verbatim. I think there is something having to do with permissions - specifically the permissions for subscribing to events - that doesn't get setup right if you don't do the steps of the project setup in the very specific order that I wrote in the Release Notes. I have setup two projects this way so far and they both work, but the third I setup (under the UD account) was setup in a convoluted fashion and we could never get it to work. Sorry I can't be more specific with the issues in setting up the Device Access project out-of-order. If I could figure that out, I could probably get the UD account project working and things would get much easier. But the Google Device Access Support is no help and I don't have access to a Google Cloud Platform (GCP) expert. If it had been AWS, I would have been flush with external advice! I'll update the documentation as to the events, and keep you informed on how work progresses on the UD account project.

So after 10 days there's only one download of the Nest SDM plugin, and I think that's me on my production system. So, before I turn back to trying to get a UD version working, what is everybody's interest in Nest device support via PG3 Plugin?

Both versions of the ratgdo firmware are available on GitHub. If somebody has Security+ 2 gdos could compare the code, fork the MQTT firmware repository, make the changes, test, and then submit a pull request back to Paul.

It may be possible but it would be a heavier lift for me to move the plugin to ESPHome than for the ratgdo FW developer to put whatever fix is in the ESPhome firmware into the MQTT firmware. The door control portions of the firmwares should be the same. I would offer to fork the firmware and implement any fixes myself, but I don’t have Security+ 2 gdos.

I am hoping the ratgdo creator (Or someone else) will get a version of the MQTT firmware working. I only have dry contact and have no problems.

You may want to open a ticket. I think your PG3 must be corrupt somehow. The installation appears to either be incomplete or there may be a permissions error, but it seems it can’t find the main folder of the installation that contains the plugin code.

Can you post the PG3 log where you tried to start it?

@SteveT Sorry I missed this one. Did you get this fixed? It looks like an incomplete installation of the code. You may want to try the new version I just uploaded to see if it runs.

I have released a new version that should fix how these values show in the Admin Console's programming interface. Enjoy!

A new version of the Schlage plugin has been released. This version adds support for the latest version of pyschlage library, a "Connected" status to the lock nodes, changes to the profile so selection dropdown boxes properly show up in the Admin Console programming interface, and some fixes to notifications.

Also, forget the comment about two plugins stepping on each other, the list in the first screenshot you posted is a list of your defined variables.

I will take a look at the Schlage Plugin code and profile to make sure there are no errors, but the plugin simply relies on the "Deadbolt status" unit of measure for reporting status, which the Admin Console seems to acknowledge in the "Deadbolt Position" display out to the right of the value selection. This is a built-in status unit of measure, so all of the text decoding and drop down lists should be handled intrinsically by the Admin Console. Here are the values and there associated text (from the API docs): 0 - Unlocked 100 - Locked 101 - Unknown 102 - Jammed

This looks like profiles from different plugins stepping on each other. Try going to PG3 Dashboard for the Schlage Plugin and click "Load Profile." Then restart the Admin Console.

A new plugin has been added to the Beta (Non-production) Plugin Store that supports Google Nest devices (thermostats, doorbells, and cameras). The Beta version currently requires the user to create their own Google Cloud project and Device Access project on the Google Cloud platform (GCP). The process is quite involved, but I have endeavored to document it the best I can. The release notes (including a link to the GCP/Device Access project setup and configuration instructions) can be found here: https://goose66.github.io/nsdocs/nestsdm-pg3.html. I encourage you to read through them before endeavoring to try the plugin. The hope is that (soon) a version can be released to the Production Plugin Store that will utilize UD's Google Cloud back-end and should be considerably easier to setup and use (as well as not require any per-user fees for Google). But I wanted to rollout a version for testers to test with IoX and PG3 and see what bugs and or enhancements we can identify as we move forward with the production version.

I like DSC panels with hardwired sensors. There is a connection device called EnvisaLink that connects your DSC panel to the LAN in the building (which I assume is linked back to the house and eISY via ethernet in the low voltage conduit). There is a plugin that will allow the DSC/Envisalink to work with the eISY. The envisaLink and plugin also support Honeywell Vista panels.

And that's exactly where it was! But I have clarified it in the Release Notes.

The Venstar T4900 are Wi-fi, and there is a Venstar Plugin developed for the ColorTouch thermostats, but the T4900 should work with it. I would be happy to help you get it working and be able to add the T4900 to the "supported device" list. There is a Honeywell plugin, too. Long distance Insteon is going to be problematic. Many have tried over the past decade, and there are really no good solutions. Insteon really needs some type of ethernet or Wi-fi bridge, but based on the status of the technology today, don't count on any future solutions or upgrades coming to Insteon - it's pretty much a dead technology, IMO.

Any resolution/new info here?