Goose66

I have released the first production version (v1.0.6) of the NestSDM plugin utilizing the UD Nest SDM Plugin project setup by Universal Devices so that you don't have to establish your own Google Developer sandbox and setup your own Device Access project and related infrastructure (it was too complicated and finicky). THIS VERSION HAS KNOWN ISSUES, but I wanted to go ahead and get it out there so folks could start playing with it. Among the most significant issues are: 1. There is a serious latency problem. Actions taken in the Admin Console may have a 1 to 3 second delay in being reflected in the state values when using your own Device Access project. With the UD Nest SDM Plugin, that delay is more like 10-25 seconds. I am working on it.... 2. The plugin does not have any internal logic for managing detection state values (motion, person, sound, doorbell) for cameras and doorbells, i.e., it doesn't monitor "Detected" states and return them to "Clear" after some time. For newer devices this is not a problem because the SDM API will send appropriate END messages for the detection events. However, for legacy devices, once "Detected," they will currently remain in this state indefinitely. It's on the list... 3. There is no "heartbeat" or other functionality to ensure the whole pathway (IoX->PG3->Plugin->SDM API->Google Home->GCP Pub/Sub->UD Nest Event Service->Portal->Plugin->Iox) is up so you can't really know if something breaks until you notice you aren't receiving state updates. This is also on the list... What is "final" (knock on wood) is the node hierarchy, and as long as you continue to use the UD Nest SDM Plugin project your user ID and device IDs should remain consistent. Therefore, once you install this version you should be able to install updates without having to uninstall and reinstall the plugin, re-authorize via oAuth, and rediscover your devices again. Hopefully a number of people can take the plunge here and we can work through the issues.

They are not supported in the Google Home API.

Yeah, I got a message from UD that my selection was invalid. As soon as I get to a computer, I will just add it as a new edition (e.g. “Standard”) and that should work. It requires a reinstall anyway, so won’t make a difference.

I changed the trial to unlimited. Let’s see if that fixes it.

Ooh, and it supports remote temperature sensors! Basic features should be supported by the Plugin out of the box. Will have to wait for the device to ship to see if new features are supported by the API and changes are needed in the Plugin. As far as Matter support, next to Tesla FSD, Matter is probably the most vaporwary thing I’ve waited for, so I’m not counting those chickens.

A new release of the plugin is in the Non-Production (Beta) Plugin Store. Also, the "trial" time has been extended to 6 months. This code contains all the code for support of the central UD Device Access project, but, while we are close to rolling out UD Device Access project support, I still need some debug time from Benoit on the service side, so that's currently not working. If you have your own Device Access project in your personal sandbox, then you can test this version. You will need to reinstall this new version - probably in a new slot. This is because this version changes the oAuth parameters that are installed with the Plugin. MAKE SURE YOU COPY YOUR THE CUSTOM CONFIGURATION PARAMETERS KEYS AND VALUES from the old version before uninstalling it, because you will need to reenter them for the newly installed version and the new version doesn't put the Custom Configuration Parameter keys in place by default (since they won't be needed for the UD Device Access project implementation). This version includes new node definitions for Doorbell and Cameras that has both state values and commands for motion/person/sound detection. It also has a Structure node that provides a node hierarchy for folks that have multiple structures. The state values for motion and person detection events clear automatically (from generated ENDED events) in newer devices (no sound support in newer devices), but I will be interested in seeing if this is the case with older, legacy devices. Let me know how it goes and I can add plugin-managed clearing of state values for detection events if necessary.

We were all there in the beginning of our programming efforts. I fought it for years, but was finally assimilated…

To be clearer (😁), the wait in the program is not causing the if statement of the program to be reevaluated. What is happening is events are causing the same program to execute again, and if the presently executing program is in a WAIT, then execution of it will stop in favor of the newly triggered instance of the program. In other words, basically you can’t have two copies of the same program running at the same time. Normally this is actually quite handy feature, and you can structure your programs to take advantage of it. This generally involves the use of the frequently discussed two-program structure - one enabled with trigger conditions and one disabled with simple if statements regarding state. This is discussed ad nauseum in this forum and I won’t go into detail here. Suffice to say in both of your examples above the programs could be structured to take advantage of this feature and create intuitive responses.

Maybe they secretly still had a few Microsoft Windows servers in the mix running crowdstrike.

That’s an error I would have expected if you were still on IoX 5.8.0 (Python 3.9). Are you sure your IoX upgrade went OK?

@tmorse305 Yes, the Envisalink 3 was limited to 6 character password, but the Envisalink 4 supports 10. However, the API specifically says that the you pass a password consisting of 6 characters. Because I only have an Envisalink 3, I was never able to send 10 characters to the password API to see if an EVL4 would accept it. More over, when initially connecting to the API of the Envisalink, we have no information whether we are talking to an EVL3 or EVL4 (nor am I aware that we ever get that information), so I wouldn't know what format to use in the API either way.

A new version v3.2.14 of the Bond plugin has been uploaded. This version fixes problems with the plugin running under IoX 5.8.3/Python 3.11 as well as cleaning up a few other items and making support for Bond Bridge Pro and Sidekick keypads "official." mea culpa, I made a pretty big mistake in changing this version so that it now only works with Python 3.11 (technically, 3.10). I didn't figure this out until I tried to install it in my production environment. However, instead of going back and fixing it, hopefully everyone needing to upgrade will also want to upgrade to IoX 5.8.3, so I just restricted this version to running on IoX 5.8.3 or better. If this is a problem, let me know and I will figure out the places where compatibility with Python with 3.9 was broken and go back and fix it.

Don’t know what to tell you. One of the reasons that I believe the ratgdo developer moved to the ESPHome version of the firmware is all the wi-fi stuff is somebody else’s issue. You could log the problem as an issue on the github site for the eSPHome firmware, but there aren’t a lot of answers there, unfortunately. As I said, I have two Genie screwdrives operating in “dry contact” mode and they both worked fine with the MQTT firmware (with some programmatic limitations) and so far have been stable and functional on the ESPHome firmware.

"it appeared to take several reboots and more than a dozen attempts to connect to the wifi..." It took the reboots and connection attempts before what? You said you could see the GDO's mac address and assigned IP address in the router. Did it show as connected? In trying to access the onboard website, were you using "ratgdov25i_XXXXX.local" or the IP address? If what took all those attempts was accessing the onboard website via the .local hostname, this is likely a problem with the PC from which you are running your browser and/or the network configuration and how it handles multicast traffic. I am no network expert, but I am beginning to believe that some home Wifi routers break multicast mDNS traffic from LAN to WLAN. If you have LAN segments with managed switches or bridges, make sure they are configured to forward the mDNS multicast addresses/ports.

Glad it worked out. Don't know why people aren't able to use local discovery using mdns. It works here, but I have Polisys, not eISYs. I believe it has something to do with LANs and broadcast restrictions. A PC with Bonjour seems to be more forgiving than the eISY environment. Note for others, you can always use the free version through MQTT - it should work. And if you have dry contact GDOs, this may be sufficient. However, there appear to be issues with the MQTT firmware and Security 1/2+. After several days or weeks, it seems to lose control (probably a code rotation issue), and upon reboot you are left in an inconsistent state until you can exercise the door manually. The ESPHome firmware appears not to have these issues, and, as of now, will be the only firmware supported by the ratgdo plugin in future updates.

If you can put, e.g., http://ratgdov25i-8d3159.local in your browser address bar and access the ratgdo, then the auto-discovery should work. Remove the config parameters and try discovery without them. If not, then your ratgdos may not be receiving broadcasts from the eISY, e.g., may be on a different LAN segment without a bridge or route. In that case, you need a “gdodeviceX” configuration parameter for each with the IP address and the device name. The device name doesn‘t have to match anything, but if you ever perform discovery again and the device name for that ratgdo is different, then a new node for that ratgdo will be created and you will have two GDO nodes pointing at the same ratgdo.

It means if the door is opened by an IoX scene or program, the door status for the node will change but the node will not generate an “Open” command to trigger other programs. An “Open” command is only triggered by the node if something outside of IoX opens it. IMO, this is consistent with the basic design philosophy of the commands in IoX, as in commands are meant to reflect actions by a user and not changes in status. That said, these are added to make the nodes usable in scenes. Making the nodes generate commands in response to them receiving those same commands creates a weird loop, logically, IMO.

I have released a new version of the "Free" edition of the ratgdo plugin for the MQTT firmware. This fixes the error introduced by the latest UD firmware update containing breaking changes in the MQTT library. This will likely be the last version of the Free edition of the plugin for the MQTT firmware unless something changes over on the Paul Wieland/ratgdo development side. See the upgraded Standard edition of the plugin for the ESPHome firmware here:

Can you access it by ratgdov25i-8d3168.local hostname? Because that's what the plugin gets from the mDNS discovery process and that's what the plugin uses to connect to the ratgdo.

when you say “it appears on my LAN,” does that mean you can access it via a web browser? Do you access it by ratgdov251-XXXXXX.local or by IP address?

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.