14_SD_WS.pm small corrections

elektron-bbs commented 6 months ago

Please check if the PR fulfills these requirements
[ ] Tests for the changes have been added / modified (needed for for bug fixes / features)
[ ] commandref has been added / updated (needed for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
[ ] Bugfix (please link issue)
[ ] Feature enhancement
[ ] Documentation update
[ ] Unittest enhancement
[x] other
What is the current behavior? (You can also link to an open issue here, if this describes the current behavior) OK
What is the new behavior (if this is a feature change)? Small corrections without changing the function of the module.
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?) no
Other information:

codecov[bot] commented 6 months ago

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (f5a9a2a) 71.41% compared to head (c5e26fe) 71.34%.

Files	Patch %	Lines
FHEM/14_SD_WS.pm	85.71%	1 Missing and 1 partial :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## master #1226 +/- ## ========================================== - Coverage 71.41% 71.34% -0.07% ========================================== Files 138 139 +1 Lines 10145 10150 +5 Branches 1584 1584 ========================================== - Hits 7245 7242 -3 - Misses 1577 1585 +8 Partials 1323 1323 ``` | [Flag](https://app.codecov.io/gh/RFD-FHEM/RFFHEM/pull/1226/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=RFD-FHEM) | Coverage Δ | | |---|---|---| | [fhem](https://app.codecov.io/gh/RFD-FHEM/RFFHEM/pull/1226/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=RFD-FHEM) | `62.01% <85.71%> (-0.06%)` | :arrow_down: | | [modules](https://app.codecov.io/gh/RFD-FHEM/RFFHEM/pull/1226/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=RFD-FHEM) | `71.34% <85.71%> (-0.07%)` | :arrow_down: | | [perl](https://app.codecov.io/gh/RFD-FHEM/RFFHEM/pull/1226/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=RFD-FHEM) | `89.09% <ø> (-0.21%)` | :arrow_down: | | [unittests](https://app.codecov.io/gh/RFD-FHEM/RFFHEM/pull/1226/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=RFD-FHEM) | `71.34% <85.71%> (-0.07%)` | :arrow_down: | Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=RFD-FHEM#carryforward-flags-in-the-pull-request-comment) to find out more.

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

sidey79 commented 6 months ago

Das sind ja eine Menge id Werte, die da nicht funktioniert haben.

elektron-bbs commented 6 months ago

Ich bin mir nicht sicher, ob sie bisher trotzdem funktioniert haben. Bisher ist mir diesbezüglich nichts aufgefallen.

elektron-bbs commented 6 months ago

Ich habe es jetzt gerade nochmal ausprobiert, indem ich bei Protokoll 27 wieder den ursprünglichen Zustand hergestellt habe:

        # id         => sub {my ($rawData,undef) = @_; return substr($rawData,1,3); },
        id         => sub {my (undef,$bitData) = @_; return substr($rawData,1,3); },

Dann eine Nachricht dispatcht:

2024.01.08 20:43:25 4: sduino_dummy: get rawmsg: MU;P0=-241;P1=251;P2=-470;P3=500;P4=-4868;P5=743;P6=-718;D=012121212303030123012301212123012121212301212303012121212121230303012303012123030303012123014565656561212301212121230303012301230121212301212121230121230301212121212123030301230301212303030301212301;CP=1;R=23;
2024.01.08 20:43:25 4: sduino_dummy: Parse_MU, Fingerprint for MU protocol id 27 -> EFTH-800 matches, trying to demodulate
2024.01.08 20:43:25 4: sduino_dummy: Parse_MU, Decoded matched MU protocol id 27 dmsg W27#21D442607679 length 48 dispatch(1/4) RSSI = -62.5
2024.01.08 20:43:25 4: sduino_dummy: SD_WS_Parse protocol 27, rawData 21D442607679
2024.01.08 20:43:25 4: sduino_dummy: SD_WS_27 Parse msg 21D442607679, CRC 79
2024.01.08 20:43:25 4: sduino_dummy: SD_WS_Parse decoded protocol-id 27 (EFTH-800, EFS-3110A), sensor-id 1D4
2024.01.08 20:43:25 1: sduino_dummy: SD_WS_Parse UNDEFINED sensor SD_WS_27_TH detected, code SD_WS_27_TH_3

Die Sensor-Id ist korrekt. Das "undef" bewirkt offensichtlich an dieser Stelle nichts.

sidey79 commented 5 months ago

Ich habe es jetzt gerade nochmal ausprobiert, indem ich bei Protokoll 27 wieder den ursprünglichen Zustand hergestellt habe:

        # id         => sub {my ($rawData,undef) = @_; return substr($rawData,1,3); },
        id         => sub {my (undef,$bitData) = @_; return substr($rawData,1,3); },

Dann eine Nachricht dispatcht:

2024.01.08 20:43:25 4: sduino_dummy: get rawmsg: �MU;P0=-241;P1=251;P2=-470;P3=500;P4=-4868;P5=743;P6=-718;D=012121212303030123012301212123012121212301212303012121212121230303012303012123030303012123014565656561212301212121230303012301230121212301212121230121230301212121212123030301230301212303030301212301;CP=1;R=23;�
2024.01.08 20:43:25 4: sduino_dummy: Parse_MU, Fingerprint for MU protocol id 27 -> EFTH-800 matches, trying to demodulate
2024.01.08 20:43:25 4: sduino_dummy: Parse_MU, Decoded matched MU protocol id 27 dmsg W27#21D442607679 length 48 dispatch(1/4) RSSI = -62.5
2024.01.08 20:43:25 4: sduino_dummy: SD_WS_Parse protocol 27, rawData 21D442607679
2024.01.08 20:43:25 4: sduino_dummy: SD_WS_27 Parse msg 21D442607679, CRC 79
2024.01.08 20:43:25 4: sduino_dummy: SD_WS_Parse decoded protocol-id 27 (EFTH-800, EFS-3110A), sensor-id 1D4
2024.01.08 20:43:25 1: sduino_dummy: SD_WS_Parse UNDEFINED sensor SD_WS_27_TH detected, code SD_WS_27_TH_3

Die Sensor-Id ist korrekt. Das "undef" bewirkt offensichtlich an dieser Stelle nichts.

Das würde bedeuten, dass die anonymen subs mit den Variablen aus den parse subs arbeiten können, da die subs innerhalb dieser generiert werden. Das ist glaube ich so ja, daher hat es vorher funktioniert.

RFD-FHEM / RFFHEM

14_SD_WS.pm small corrections #1226

Codecov Report