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
Describe the bug
With the fix for #133, we are occasionally getting an indication on the PD side that the connection has dropped, when our CP side is not detecting a drop.
The default timeout is set to 200ms here. The 200ms is how long a single PD needs to respond within. Several options to fix:
Increase the delay to at least 600ms. Note that in the OSDP spec version 2.2 and 2.1.7, the "off-line" time is set to 8 seconds, so that is probably the correct time to set it to.
Add an option to make this configurable on the PD side(e.g. osdp_pd_set_max_offline_time)
The text was updated successfully, but these errors were encountered:
@rm5248, thanks for reporting this. I have added a new macro OSDP_ONLINE_TOUT_MS defined to 600 ms. 8 seconds seem too high a number for my preference :).
The current defintion of 200ms seem to be too agressive for some use
cases.
Fixes: #140
Signed-off-by: Siddharth Chandrasekaran <sidcha.dev@gmail.com>
(cherry picked from commit 068bf59)
Describe the bug
With the fix for #133, we are occasionally getting an indication on the PD side that the connection has dropped, when our CP side is not detecting a drop.
The default timeout is set to 200ms here. The 200ms is how long a single PD needs to respond within. Several options to fix:
osdp_pd_set_max_offline_time
)The text was updated successfully, but these errors were encountered: