Attention Users: Dry Contact and Security+ 1.0 Issue!

[Goose66]

Something I came across when looking into some firmware issues:

It appears that in security+ 1.0 and dry contact modes, after a reboot the ratgdo firmware does not seem to know the door state. You must move the door for the ratgdo to regain the door state. This does not appear to be the case in security+ 2.0 mode because that mode supports "querying" the state from the controller.

The potential issue here is that, with the unknown door state, any subsequent open or close command to the ratgdo just reverses the true state of the door. So if you have, e.g., a program that automagically closes your door at night, but the ratgdo was rebooted due to a power failure during the day, that close command when sent to the device may, in fact, open the door.

I have logged an issue and hope that the firmware can be updated to set the door state in dry contact mode from the current state of the limit switches upon reboot. In the meantime, keep an eye on it.

[SHM]

Yes, I have been experiencing that quite a bit even in the security + 2.0.  Is there a way to query the ratgdo every morning using a program?  I do that for my door locks.

[Goose66]

Query only appears to work (or at least be implemented) for security+ 2.0. But querying the ratgdo won't do any good because it is the ratgdo that is unaware of the door state, so even if I could force it to report the current state back to the plugin, it seems to me it would just report "Unknown."

I guess every morning, if the door state is reporting unknown, you could just toggle the door state  and then about 10 seconds later close (or open) the door based on the newly reported state. But I would prefer that the ratgdo firmware be corrected to determine the door state on restart so that it could initially report the correct door state. I have logged an issue with Paul Wieland.

Edited March 19 by Goose66