You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At least in dry contact mode, 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. I don't think this is the case in Security 2.0 because it appears to support a "querying" of state from the controller: getRollingCode("reboot2"); transmit(txSP2RollingCode,SECPLUS2_CODE_LEN);
This bit of code also appears to support the implementation of a "query" MQTT command from integrations.
The problem here is that, with the unknown door state, any subsequent open or close just reverses the state of true state of the door. So if I have, e.g., an automatic door close at night, but the ratgdo was rebooted due to a power failure during the day, that close command when sent to the door may, in fact, open the door.
It would be nice if, upon reboot, the door state in dry contact mode could be updated from the current state of the limit switches. It would also be helpful if the MQTT "query" command could also use the current limit switch state to update the door state.
The text was updated successfully, but these errors were encountered:
At least in dry contact mode, 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. I don't think this is the case in Security 2.0 because it appears to support a "querying" of state from the controller:
getRollingCode("reboot2"); transmit(txSP2RollingCode,SECPLUS2_CODE_LEN);
This bit of code also appears to support the implementation of a "query" MQTT command from integrations.
The problem here is that, with the unknown door state, any subsequent open or close just reverses the state of true state of the door. So if I have, e.g., an automatic door close at night, but the ratgdo was rebooted due to a power failure during the day, that close command when sent to the door may, in fact, open the door.
It would be nice if, upon reboot, the door state in dry contact mode could be updated from the current state of the limit switches. It would also be helpful if the MQTT "query" command could also use the current limit switch state to update the door state.
The text was updated successfully, but these errors were encountered: