Correct the Heartbeat pulse process for garage door

[tipi85]

In class FrameStatusRequestRequest, FPI1=254 creates an error for garage door ( opening device ) With FPI1=0, the error is gone and other equipements are reporting correctly.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 78.95%. Comparing base (6cb8633) to head (6fc9380). Report is 3 commits behind head on master.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #377   +/-   ##
=======================================
  Coverage   78.95%   78.95%           
=======================================
  Files          78       78           
  Lines        3649     3649           
=======================================
  Hits         2881     2881           
  Misses        768      768           

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[tipi85]

fixes : #377

[pawlizio]

Have you tested this modification with forfunctional parameter also for other device types? The idea of the FPI1 and FPI2 in this request is, that you receive the status of functional parameter as well. If you set FPI1 to 0, the reply will only include the main parameter:

Logic of FPI1/FPI2 is discribed here:

For example Dual Roller Shutter use functional parameter 1 for the position of the upper cover and functional parameter 2 for the lower one.

However I do not understand why it is set to 254 currently, as this is in binary 11111110 (big endian). In the specification only the first 3 functional parameters are used on the list of different actualy types. In this case a reply for them would be enough, so FPI1 with value 11100000 should be OK, but this is not 254 but 224

Can you test if you have problems with your garage doors with 224?

[tipi85]

Indeed I reduced it at first to 224 (11100000) then 128 ( 10000000 ) but the effect was unchanged. Unfortunately all my devices are not using FP1 to 3 so I cannot evaluate if this as an effect on the reporting of the other parameters. I always got the same logs : current_position_fp1="UNKNOWN" current_position_fp2="UNKNOWN" current_position_fp3="UNKNOWN" current_position_fp4="UNKNOWN"