If you can't retrieve the state of the standby member of your cluster but you can see the active, that generally indicates that monitoring traffic heading for the standby member is flowing asymmetrically through the cluster. So in essence traffic bound for the standby member arrives at the active first, who forwards it to the standby, who then tries to answer directly which won't work due to asymmetry. Make sure that the General or "Main" IP addresses defined for each cluster member are the IP address that "faces" or is closest to where the SmartConsole and/or SMS are located to avoid this. If this cannot be achieved, a static host-based route will need to be defined for the dedicated/fixed IP addresses of each cluster member on whatever adjacent Layer 3 device is transiting the traffic on behalf of the SmartConsole and/or SMS.
Since this is R80.20, it could also be related to kernel variable fwha_forw_packet_to_not_active as reported by @Danny in this thread:
New 2-day Live "Max Power" Series Course Now Available:
"Gateway Performance Optimization R81.20" at maxpowerfirewalls.com