Goose66 Posted June 15 Posted June 15 A new version v4.0.8 of the ratgdo plugin is available in the Plugin Store. This version has a couple of major changes: 1. It is designed to work with the ESPHome firmware through the ESPHome REST/Event Source API. The ESPHome firmware is more up-to-date and supposedly does not have the eventual loss of control in MyQ Security+ 2.0 GDOs that the MQTT firmware has. 2. It has a one month trial and then is $10.95 perpetual license. This was released as a separate edition of the plugin: the "Standard" edition as opposed to the "Free" edition for the MQTT firmware. This was done so that it didn't automatically upgrade on users' installations before the users had a chance to flash their devices with the ESPHome firmware. The release notes have been updated for the new v4.0.8 version as well: https://goose66.github.io/nsdocs/ratgdo-pg3.html
4481hoods Posted June 15 Posted June 15 (edited) Getting the following error: "There was an error attempting to connect to the device at ratgdov25i-4b1a56.local. Please check the log files and correct the issue before restarting the plugin." ratgdo_6-15-2024_72340_PM.zip Edited June 15 by 4481hoods
Mr B Posted June 15 Posted June 15 @4481hoods I kept getting that error also until I added a custom configuration parameter like in the release notes: Key: gdodevice Value: <ip address of ratgdo>;<Name of ratgdo modified as per the release notes> I have a DHCP reservation for the ratgdo and pulled the name from the ratgdo config page modified as per the release notes (periods and spaces). That modified name was showing up in the logs. Took me several tries to get it right but it's working great now. Restart the plug-in after you add the custom configuration parameter.
4481hoods Posted June 15 Posted June 15 (edited) Could you send the value line. Ty. Got it! Thanks Edited June 16 by 4481hoods Sucess
Goose66 Posted June 16 Author Posted June 16 What happens when you try to go to http:\\ratgdov25i-4b1a56.local in your web browser?
4481hoods Posted June 16 Posted June 16 Did this: Key: gdodevice Value: <ip address of ratgdo>;<Name of ratgdo modified as per the release notes> All works!!
SHM Posted June 16 Posted June 16 I downloded ratgdo_esp8266_v2.1.bin and refreshed the firmware from the ratgdo page. After completing, the page still shows all the MQTT data (server, port, prefix, home assistant). Is this correct?
Goose66 Posted June 16 Author Posted June 16 No, you have to specifically install the ESPHome firmware. Go to the ratgdo Plugin Release Notes and Instructions for the details and website.
Goose66 Posted June 16 Author Posted June 16 1 hour ago, 4481hoods said: Did this: Key: gdodevice Value: <ip address of ratgdo>;<Name of ratgdo modified as per the release notes> All works!! 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.
4481hoods Posted June 17 Posted June 17 Actually, it was not a big problem adding key and value. Once the problem was identified it was a very easy fix. Could the problem be remnants from the previous MQTT installation. I did try two ratgdos, thinking one was bad, installed in two different slots. neither did the trick. Things are working very well. Thank You
Goose66 Posted June 17 Author Posted June 17 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.
SHM Posted June 17 Posted June 17 OK. I downloaded ESP Home version directly , via USB cable, to the ratgdo. It appears on my LAN and opens and closes the door, etc. Then went to plugins store and downloaded 4.0.8, waited 10 minutes and tried to discover. No go. Here is log file. Should I try the custom parameter approach?
SHM Posted June 17 Posted June 17 I went ahead and used the custom Configuration pathway and the ratgdo is discovered. Interestingly, the plugin nodes show only "door status" and "obstruction", which appear the same in IoX. In UD mobile, Door Status shows up as either 0 or 1 and obstruction is absent. The UD mobile favorite is setup as a "toggle". Not a big deal but if there was a way to change to open or closed, that would be nice. The ratgdo for this door is set up as "dry contact" if that makes a difference. So far, the plugin seems more responsive. ratgdo_6-17-2024_10623_PM.zip
Goose66 Posted June 17 Author Posted June 17 As far as UDI Mobile, I get this: Try re-syncing UDI Mobile.
Goose66 Posted June 17 Author Posted June 17 4 hours ago, SHM said: It appears on my LAN and opens and closes the door, etc. 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?
Goose66 Posted June 18 Author Posted June 18 (edited) 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. Edited June 18 by Goose66
SHM Posted June 18 Posted June 18 By the way, in your notes for version 4.0.8 under #4, you state..."these commands are only generated if the status change results from and external control signal (i.e., not a command from IoX through the plugin." Does this mean that an IoX program that opens the door when a home geofence is entered will not trigger the door open?
Goose66 Posted June 19 Author Posted June 19 (edited) 13 hours ago, SHM said: Does this mean that an IoX program that opens the door when a home geofence is entered will not trigger the door open? 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. Edited June 19 by Goose66 1
dbwarner5 Posted June 19 Posted June 19 @Goose66 ReFlashed today. Ratgdo devices (2) were NOT recognized. Had to use two custom parameters and then Discover to find them: -gdodevice0, 192.168.68.125;ratgdov25i-ca0567 -gdodevice1, 192.168.68.127;ratgdov25-30f318 -error message was: STOP button does NOT work on either door under devices. For those with programs and want to make the change, this is an easy way to update all your programs and not lose anything. 1) Install new version 4.0 2) name the devices in the device tree similar to old names but slightly different 3) go to programs and do a FIND / REPLACE using the old name as the find, and new modified name as replace. 4) delete old nodes 5) rename new nodes to your original names. ie: -my original name was Pole Barn North Door. -New temp name PBNorth Door -Find: Pole Barn North Door --> Replace: PBNorth Door --> replace in all programs -Back to Device tree, Delete original nodes Pole Barn North Door -select PBNorth Door and rename to Pole Barn North Door. Cheers.
hart2hart Posted June 19 Posted June 19 As far as UDI Mobile, I get this: http://d2z8ydsemzif1x.cloudfront.net/monthly_2024_06/image.thumb.png.b0d1ddaa1587b50535a12cbf297adfb1.png Try re-syncing UDI Mobile. Everything in the ESPHome version looks and is working great!I do have a question about its interaction with UDM and have synchronized it to eISY A few times. The standard device has status values as expected. However when creating a Favorite with a door’s status, I get status integers of 1,2,3… instead of status values of Open, Closed, Opening, Closing etc. When I do UDM Advanced Status Configuration on the favorite I see the status values and I can say if Open display Open. Is there a linkage, hint, or mapping that needs to be updated? Also, if more of a UDM question can you assist me, @Javi ?
Javi Posted June 19 Posted June 19 Please try rebooting eisy. Formatted Property Values for Node Servers may not be published by eisy if eisy has not been rebooted after values are defined by the Node Server. This was due to limited processing power on ISY994, so we hope to have this corrected for eisy soon.
hart2hart Posted June 19 Posted June 19 Please try rebooting eisy. Formatted Property Values for Node Servers may not be published by eisy if eisy has not been rebooted after values are defined by the Node Server. This was due to limited processing power on ISY994, so we hope to have this corrected for eisy soon.Thanks, Javi. The reboot fixed it!
Recommended Posts