gzahar

Try connecting directly to PC and erase all data when loading firmware.

Make sure the scene that turns the fan on includes the off button with a status of off.

If you have a plugin with the error, delete and reinstall the plugin.

The owner of the plugin has the PG2 version of the code on GitHub. The mappings didn’t change when it was converted to PG3. Also, I believe the A/C normally shows these starting with ST then GVx in numerical order, but there may be exceptions.

ST-ACP-ST-NAME = Alarm Panel Connected ST-ACP-GV0-NAME = System Alarm State ST-ACP-GV4-NAME = Bell Trouble ST-ACP-GV5-NAME = Battery Trouble ST-ACP-GV6-NAME = AC Trouble ST-ACP-GV7-NAME = FTC Trouble ST-ACP-GV8-NAME = Tamper Trouble ST-ACP-GV9-NAME = Fire Trouble ST-ACP-GV10-NAME = Zone Fault ST-ACP-GV11-NAME = Zone Sensor Low Battery

Post your "on" program and "off" if you have one you tried.

I received the following instructions from another member that fixed mine: 1) Z wave compatibility mode on 2) Z wave validation off 3) Z wave rewrite all device links

After this happened the second time to me, I was going to report the problem. This was before there were many others reporting this issue, so I didn’t know if it was just my device or not. Anyway, first I wanted to try to figure out how often this was happening. To do that, I created a program to ‘blink’ the light on the GDO when it detected I was in the garage. I was hoping this would allow me to catch when the control stopped working as I don’t normally use the that feature often. That has been at least several months ago and it has not ‘locked up’ since I did this. It may be very premature to say this, but it seems that if you send control on a regular basis, the problem doesn’t happen. I would be interested to hear if others that have the problem use their control feature daily?

You might also check the event viewer or program summary tab sorted by last time run to make sure it’s not being turned on/off by a program.

That is what prompted me to try the re-flash/erase option.

Don't know. I have not used OTA flashing. I think using the erase option is key (not sure) and that is probably only available with USB. But give it a try.

I see the issue. The key values used to be tied to variables (and their ids) when the plugin was first created. They aren't anymore. As stated each key must be unique, you can't use 78 more than once. There is no reason to not start with 1, 2, etc. For the value, you need to put in the word switch, dimmer, etc. This will create a node in the eisy labeled 1 (maybe with a nxxx_ prefix, I don't remember). You can then rename it (on eisy) whatever you want.

This was similar to the response you sent me. The AC responds that the light turns on, but it doesn't. It does seem to be the ratgdo not communicating properly with the gdo. I was not sure if I had a bad device or this was happening to others. Wanted to get more data if I could (how often, after some particular event, etc.) before opening an issue on github.

Mine has done this twice. Continues to report status correctly, just won't control. Unfortunately, only solution to re-flash (with erase option) and re-install. I have recently tried to put in an automated use of controlling the light so that I notice how often/when it actually happens.

Post a picture of your configuration page.

Yes. I do that. You can use network resources to control A/V equipment. Some devices can be controlled directly over IP network and devices that are IR only can be controlled with the use of IP to IR converters. Look at the Global Cache Flex IR devices for that. There may be cheaper alternatives also, haven’t looked in a while.

Currently sold out…

This looks suspicious. Agreed you may be changing the day and rerunning before it completes. Do the values change right at midnight so that if it reruns, you would get the wrong results the second pass? Nevermind, if the days changes it would not run again right away.

If it is all Insteon, put the devices in a scene and turn the scene off.

IF device = closed THEN flash lights This will run whenever the device transitions to closed. There is no need to qualify it any more. It will not run [THEN] again until the devices changes to something else and back to closed. (It will run ELSE statements whenever it leaves the closed state) You may want to add a several seconds WAIT before the flash lights depending on the device. This will de-bounce any open/close back and forth states during the transition that may start your flash routine several times.

Restart the plug-in in PG3. You may also need to restart the AC after that.

Short answer is, it is working now. I thought I would try to setup control through HA using MQTT and didn't know enough to get it working. Actually appeared to lock up the device after entering some configuration data incorrectly. Then I decided to flash it with the firmware meant for HA and that went very smoothly and was able to control door with HA. So then switched back to MQTT / PG3 setup and that seemed to do the trick. Only difference that I know of this time around is I check the 'erase all data' box when I flashed the MQTT firmware. Who knows... Hopefully it continues to operate and I don't have something going on that corrupts the device after some time. Thanks again for the plugin!

I agree it looks like the ratgdo is the issue. I guess I haven't played with it for a while until doing the upgrade, so it may have gone unresponsive before then. I will take it down and reflash to see if that changes things. I think I hit the lock command as one of my first things, because that status was unknown. Maybe I locked myself out somehow? It does report as being unlocked though.

I also ran a motion test and it seemed to work just fine. I did completely delete and reinstall the plugin due to other issues. Here was the output from the event viewer. And my test program did trigger (more often than expected; using the switched/DON3 condition). Wed 01/31/2024 11:39:14 PM : [n001_ratgdo47285] DON3 0 Wed 01/31/2024 11:39:14 PM : [n001_ratgdo47285] GV3 1 (uom=25 prec=0) Wed 01/31/2024 11:39:19 PM : [n001_ratgdo47285] DON3 0 Wed 01/31/2024 11:39:24 PM : [n001_ratgdo47285] DON3 0 Wed 01/31/2024 11:39:24 PM : [n001_ratgdo47285] GV1 1 (uom=25 prec=0) Wed 01/31/2024 11:39:27 PM : [n001_ratgdo47285] GV1 0 (uom=25 prec=0) Wed 01/31/2024 11:39:34 PM : [n001_ratgdo47285] DON3 0 Wed 01/31/2024 11:39:39 PM : [n001_ratgdo47285] DON3 0 Wed 01/31/2024 11:39:44 PM : [n001_ratgdo47285] DON3 0 Wed 01/31/2024 11:40:54 PM : [n001_ratgdo47285] GV3 0 (uom=25 prec=0) Wed 01/31/2024 11:49:44 PM : [n001_ratgdo47285] DON3 0 Wed 01/31/2024 11:49:44 PM : [n001_ratgdo47285] GV3 1 (uom=25 prec=0) Wed 01/31/2024 11:49:48 PM : [n001_ratgdo47285] DON3 0 Wed 01/31/2024 11:49:53 PM : [n001_ratgdo47285] DON3 0 Wed 01/31/2024 11:50:04 PM : [n001_ratgdo47285] DON3 0 Wed 01/31/2024 11:50:09 PM : [n001_ratgdo47285] DON3 0 Wed 01/31/2024 11:50:24 PM : [n001_ratgdo47285] DON3 0 Wed 01/31/2024 11:50:29 PM : [n001_ratgdo47285] DON3 0 Wed 01/31/2024 11:50:34 PM : [n001_ratgdo47285] DON3 0 Wed 01/31/2024 11:51:40 PM : [n001_ratgdo47285] GV3 0 (uom=25 prec=0)

1) ratgdo v2.57 for hardware v2.50 2) sec+2.0 3) attached I did try a reboot of ratgdo, but maybe I'll try a power reset on it and Polisy. ratgdo_1-31-2024_113809_PM.zip