Jump to content

New Release v4.0.8 - ESPHome version


Recommended Posts

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

Link to comment

@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.

Link to comment

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?

Link to comment
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.

Link to comment

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

Link to comment

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.

Link to comment

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?

 

Link to comment

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.

Plugin.png

IoX.png

UD mobile.jpg

ratgdo_6-17-2024_10623_PM.zip

Link to comment
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?

Link to comment
Posted (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 by Goose66
Link to comment

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?

Link to comment
Posted (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 by Goose66
  • Like 1
Link to comment

@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:

Screenshot2024-06-19at9_34_40AM.thumb.jpg.5a0b74f000d63fb8f0eace8f5efd5bcd.jpg

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.

 

Link to comment

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 ?
Link to comment

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.

Link to comment
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!
Link to comment
Guest
This topic is now closed to further replies.

  • Recently Browsing

    • No registered users viewing this page.
  • Who's Online (See full list)

  • Forum Statistics

    • Total Topics
      36.6k
    • Total Posts
      368.3k
×
×
  • Create New...