Closed elektron-bbs closed 11 months ago
Merging #1201 (dd092a5) into master (0fc687e) will increase coverage by
0.04%
. The diff coverage is71.42%
.
@@ Coverage Diff @@
## master #1201 +/- ##
==========================================
+ Coverage 67.61% 67.66% +0.04%
==========================================
Files 134 136 +2
Lines 9932 9942 +10
Branches 1591 1593 +2
==========================================
+ Hits 6716 6727 +11
+ Misses 1908 1905 -3
- Partials 1308 1310 +2
Flag | Coverage Δ | |
---|---|---|
fhem | 57.45% <71.42%> (+0.06%) |
:arrow_up: |
modules | 67.66% <71.42%> (+0.04%) |
:arrow_up: |
perl | 89.47% <ø> (ø) |
|
unittests | 67.66% <71.42%> (+0.04%) |
:arrow_up: |
Flags with carried forward coverage won't be shown. Click here to find out more.
Files | Coverage Δ | |
---|---|---|
FHEM/00_SIGNALduino.pm | 63.96% <ø> (ø) |
|
FHEM/lib/SD_ProtocolData.pm | 100.00% <ø> (ø) |
|
FHEM/14_SD_UT.pm | 50.05% <71.42%> (+0.10%) |
:arrow_up: |
... and 6 files with indirect coverage changes
:mega: Codecov offers a browser extension for seamless coverage viewing on GitHub. Try it in Chrome or Firefox today!
Die im Test hinterlegt RMSG wird vom 00_Signalduino vermutlich nicht akzeptiert oder?
Mhmm, warum sollten sie nicht verarbeitet werden? Bei mir werden beide verarbeitet und die Test liefen beim PR ja auch fehlerfrei durch.
2023.11.04 12:09:06 4: sduino_dummy: get rawmsg: MS;P1=425;P2=-1142;P3=1187;P4=-395;P5=-12314;D=15121212123412341234341212123412341212121212121234;CP=1;SP=5;R=232;O;m2;
2023.11.04 12:09:06 4: sduino_dummy: Parse_MS, Matched MS protocol id 3 -> chip xx2260 / xx2262
2023.11.04 12:09:06 4: sduino_dummy: Parse_MS, Decoded matched MS protocol id 3 dmsg i0AC501 length 24 RSSI = -86
2023.11.04 12:09:06 4: sduino_dummy IT: message "i0AC501" (7)
2023.11.04 12:09:06 4: sduino_dummy IT: msgcode "" (0) bin = 000010101100010100000001
2023.11.04 12:09:06 4: sduino_dummy IT: 1527x0ac50 not defined (Switch code: 0001)
2023.11.04 12:09:06 4: sduino_dummy: Parse_MS, Matched MS protocol id 118.1 -> Meikee
2023.11.04 12:09:06 4: sduino_dummy: Parse_MS, Decoded matched MS protocol id 118.1 dmsg P118#0AC501 length 24 RSSI = -86
2023.11.04 12:09:06 4: sduino_dummy: SD_UT protocol 118, bitData 000010101100010100000001, hlen 6
2023.11.04 12:09:06 1: sduino_dummy: SD_UT_Parse UNDEFINED sensor unknown detected, protocol 118, data 0AC501, code 0AC5
2023.11.04 12:09:06 4: sduino_dummy: Parse_MS, Matched MS protocol id 128.1 -> RCnoName128
2023.11.04 12:09:06 4: sduino_dummy: Parse_MS, last part pair=2 reconstructed, last bit=1
2023.11.04 12:09:06 4: sduino_dummy: Parse_MS, Matched MS protocol id 130 -> CREATE_6601TL
2023.11.04 12:09:06 4: sduino_dummy: Parse_MS, Decoded matched MS protocol id 130 dmsg P130#F53AFE length 24 RSSI = -86
2023.11.04 12:09:06 4: sduino_dummy: SD_UT protocol 130, bitData 111101010011101011111110, hlen 6
2023.11.04 12:10:17 4: sduino_dummy: get rawmsg: MS;P0=-11884;P1=392;P2=-1179;P3=1180;P4=-391;D=10121212123412341234341212123412341212121212341234;CP=1;SP=0;R=231;O;m2;
2023.11.04 12:10:17 4: sduino_dummy: Parse_MS, Matched MS protocol id 3 -> chip xx2260 / xx2262
2023.11.04 12:10:17 4: sduino_dummy: Parse_MS, Decoded matched MS protocol id 3 dmsg i0AC505 length 24 RSSI = -86.5
2023.11.04 12:10:17 4: sduino_dummy IT: message "i0AC505" (7)
2023.11.04 12:10:17 4: sduino_dummy IT: msgcode "" (0) bin = 000010101100010100000101
2023.11.04 12:10:17 4: sduino_dummy IT: 1527x0ac50 not defined (Switch code: 0101)
2023.11.04 12:10:17 4: sduino_dummy: Parse_MS, Matched MS protocol id 130 -> CREATE_6601TL
2023.11.04 12:10:17 4: sduino_dummy: Parse_MS, Decoded matched MS protocol id 130 dmsg P130#F53AFA length 24 RSSI = -86.5
2023.11.04 12:10:17 4: sduino_dummy: SD_UT protocol 130, bitData 111101010011101011111010, hlen 6
Hatte ich wegen dem ;O;m2 mal angenommen ;)
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
[ ] Bugfix (please link issue)
[x] Feature enhancement
[ ] Documentation update
[ ] Unittest enhancement
[ ] other
What is the current behavior? (You can also link to an open issue here, if this describes the current behavior) The protocol of this remote control has not been decoded, see https://forum.fhem.de/index.php?msg=1288203
What is the new behavior (if this is a feature change)? The protocol is now being decoded. In addition, a bug has been fixed, see https://github.com/RFD-FHEM/RFFHEM/commit/dfbed25aaef58d8d3df98a82f5791946a9338535
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?) no
Other information: