SD_UT remote control DC-1961-TG #1129

elektron-bbs · 2022-12-10T12:59:50Z

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, ...)

What is the current behavior?
(You can also link to an open issue here, if this describes the current behavior)
No decoding of remote control commands.
https://forum.fhem.de/index.php/topic,53282.msg1240911.html#msg1240911
What is the new behavior (if this is a feature change)?
Receive and send these remote control commands.
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 · 2022-12-10T13:04:31Z

Codecov Report

Merging #1129 (7d3da67) into master (1d5733d) will increase coverage by 0.26%.
The diff coverage is 47.61%.

@@            Coverage Diff             @@
##           master    #1129      +/-   ##
==========================================
+ Coverage   66.84%   67.11%   +0.26%     
==========================================
  Files         132      135       +3     
  Lines        9785     9806      +21     
  Branches     1570     1572       +2     
==========================================
+ Hits         6541     6581      +40     
+ Misses       1952     1933      -19     
  Partials     1292     1292

Flag	Coverage Δ
fhem	`56.64% <47.61%> (+0.33%)`	⬆️
modules	`67.11% <47.61%> (+0.26%)`	⬆️
perl	`90.33% <ø> (+0.16%)`	⬆️
unittests	`67.11% <47.61%> (+0.26%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
FHEM/lib/SD_ProtocolData.pm	`100.00% <ø> (ø)`
lib/Test2/SIGNALduino/RDmsg.pm	`74.00% <0.00%> (-0.75%)`	⬇️
t/FHEM/14_SD_UT/01_attr.t	`100.00% <ø> (ø)`
t/FHEM/14_SD_UT/03_set.t	`92.30% <ø> (ø)`
FHEM/14_SD_UT.pm	`48.76% <50.00%> (+3.88%)`	⬆️
FHEM/10_SD_Rojaflex.pm	`66.39% <0.00%> (-4.05%)`	⬇️
FHEM/00_SIGNALduino.pm	`63.64% <0.00%> (-0.45%)`	⬇️
t/FHEM/14_SD_AS/00_load.t	`100.00% <0.00%> (ø)`
t/FHEM/14_Hideki/00_load.t	`100.00% <0.00%> (ø)`
t/FHEM/10_SD_Rojaflex/09_parseData.t	`94.11% <0.00%> (ø)`
... and 1 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

elektron-bbs · 2022-12-10T15:33:05Z

schon wieder codecov/patch :-(

Wieso mäkelt das Teil an diesen Zeilen:

+        ############ RCnoName20 ############
+        } elsif ($attrValue eq 'RCnoName20' || $attrValue eq 'RCnoName20_10' || $attrValue eq 'DC_1961_TG') {
+          $deviceCode = substr($bitData,0,16);
+          $deviceCode = sprintf("%04X", oct( "0b$deviceCode" ) );
+          $devicename = $devicemodel.'_'.$deviceCode;

Testdaten für alle drei Fernbedienungen existieren.
Allerdings habe ich die Testdaten für 'DC_1961_TG' zuerst nur im Branch Master vom SD_Tool gehabt und erst nach dem Pull request ein merge in pre-release durchgeführt.

Generelle Frage: Wann sind wo (master, pre-release) Testdaten erforderlich?

sidey79 · 2022-12-10T22:51:42Z

schon wieder codecov/patch :-(

Wieso mäkelt das Teil an diesen Zeilen:
+        ############ RCnoName20 ############
+        } elsif ($attrValue eq 'RCnoName20' || $attrValue eq 'RCnoName20_10' || $attrValue eq 'DC_1961_TG') {
+          $deviceCode = substr($bitData,0,16);
+          $deviceCode = sprintf("%04X", oct( "0b$deviceCode" ) );
+          $devicename = $devicemodel.'_'.$deviceCode;
Testdaten für alle drei Fernbedienungen existieren. Allerdings habe ich die Testdaten für 'DC_1961_TG' zuerst nur im Branch Master vom SD_Tool gehabt und erst nach dem Pull request ein merge in pre-release durchgeführt.

Generelle Frage: Wann sind wo (master, pre-release) Testdaten erforderlich?

Die Tests werden einmal mit den Daten aus pre-release und einmal mit denen aus dem master ausgeführt.
Wenn es Fehler im pre-release gibt, dann wird der Test nicht als fehlerhaft gewertet, das ist eigentlich alles.

Sollten wir die Testdaten zu den Modulen legen, dann wird das irrelevant.

Besagter Abschnitt wird im übrigen nur aufgerufen, wenn schon mal was empfangen wurde:

RFFHEM/FHEM/14_SD_UT.pm

Line 2255 in 49766ff

if (InternalVal($name, 'bitMSG', 'no data') ne 'no data') {

Das ist ja hier nicht der Fall, es wird erst das attribut gesetzt und danach erst parseMsg aufgerufen, daher wird der codeabschnitt nicht angesteuert.

elektron-bbs · 2022-12-11T10:27:19Z

Generelle Frage: Wann sind wo (master, pre-release) Testdaten erforderlich?

Die Tests werden einmal mit den Daten aus pre-release und einmal mit denen aus dem master ausgeführt. Wenn es Fehler im pre-release gibt, dann wird der Test nicht als fehlerhaft gewertet, das ist eigentlich alles.

Demnach könnten wir uns die Tests mit pre-release eigentlich sparen.

Sollten wir die Testdaten zu den Modulen legen, dann wird das irrelevant.

Mhmm, willst du dann für jedes Modul ein JSON pflegen?

Besagter Abschnitt wird im übrigen nur aufgerufen, wenn schon mal was empfangen wurde:

RFFHEM/FHEM/14_SD_UT.pm

Line 2255 in 49766ff

if (InternalVal($name, 'bitMSG', 'no data') ne 'no data') {

Das ist ja hier nicht der Fall, es wird erst das attribut gesetzt und danach erst parseMsg aufgerufen, daher wird der codeabschnitt nicht angesteuert.

Stimmt, demnach müsstest du im Test das InternalVal 'bitMSG' vorher befüllen, oder halt die Nachricht zweimal dispatchen.

sidey79 · 2022-12-11T19:50:40Z

Demnach könnten wir uns die Tests mit pre-release eigentlich sparen.

Sollten wir die Testdaten zu den Modulen legen, dann wird das irrelevant.

Mhmm, willst du dann für jedes Modul ein JSON pflegen?

Das war zumindest mein Verständnis aus RFD-FHEM/SIGNALduino_TOOL#87
Dadurch kann dann auch die Unterscheidung in pre_release entfallen, da die Tests immer passend zum Versionsstand des Modules geladen werden.

Besagter Abschnitt wird im übrigen nur aufgerufen, wenn schon mal was empfangen wurde:

RFFHEM/FHEM/14_SD_UT.pm

Line 2255 in 49766ff

if (InternalVal($name, 'bitMSG', 'no data') ne 'no data') {

Das ist ja hier nicht der Fall, es wird erst das attribut gesetzt und danach erst parseMsg aufgerufen, daher wird der codeabschnitt nicht angesteuert.

Stimmt, demnach müsstest du im Test das InternalVal 'bitMSG' vorher befüllen, oder halt die Nachricht zweimal dispatchen.

Richtig, über prep_commands kann man ein beliebiges Kommando nach Define, aber vor dem Setzen der Attribute ausführen.
Ein zweimaliges dispatchen würde nicht helfen, denn das kommt nachdem Attribute gesetzt werden.

elektron-bbs · 2022-12-13T20:08:25Z

Mir sind noch zwei "return undef" aufgefallen. Kann ich das ändern, oder ist das im Moment eher ungünstig?

sub SD_UT_bin2tristate {
  my $bitData = shift // return undef;

sub SD_UT_tristate2bin {
  my $tsData = shift // return undef;

Testdaten für diesen PR sind z.Z. allerdings nicht im JSON.

sidey79 · 2022-12-13T20:49:34Z

@actions-user
Das kannst Du anpassen, kein Problem.

Testdaten sind hier und werden auch ausgeführt:
RFD-FHEM/SIGNALduino_TOOL@cd4600a

elektron-bbs · 2022-12-14T19:36:19Z

Testdaten sind hier und werden auch ausgeführt: RFD-FHEM/SIGNALduino_TOOL@cd4600a

Das war mein commit vom Dec 10, 2022.
Die Daten wurden aber wieder gelöscht am Dec 12, 2022 durch diesen RFD-FHEM/SIGNALduino_TOOL@306d256 (remove testdata for remote control DC_1961_TG protocol 20 (later addition)).

sidey79 · 2022-12-14T19:48:43Z

Testdaten sind hier und werden auch ausgeführt: RFD-FHEM/SIGNALduino_TOOL@cd4600a

Das war mein commit vom Dec 10, 2022. Die Daten wurden aber wieder gelöscht am Dec 12, 2022 durch diesen RFD-FHEM/SIGNALduino_TOOL@306d256 (remove testdata for remote control DC_1961_TG protocol 20 (later addition)).

Im Branch pre-release ist er ja noch enthalten:
RFD-FHEM/SIGNALduino_TOOL@e98c1bc

HomeAutoUser · 2022-12-14T19:52:17Z

Im Branch pre-release ist er ja noch enthalten: RFD-FHEM/SIGNALduino_TOOL@e98c1bc

Das ist nicht richtig @sidey79. Hier https://github.com/RFD-FHEM/SIGNALduino_TOOL/blob/pre_release/FHEM/lib/SD_Device_ProtocolList.json ist nichts mehr drin.
Grund, nach deiner Aussage, das es voreilig war diese reinzunehmen, entfernte ich es im Master und Pre-Release.

sidey79 · 2022-12-14T20:09:11Z

Pre_Release ist ein anderer Branch als pre-release.
Letzterer wird für Tests verwendet und da können auch Tests aufgenommen werden die noch nicht im master Branch erfolgreich laufen.

HomeAutoUser · 2022-12-14T20:13:01Z

Pre_Release ist ein anderer Branch als pre-release. Letzterer wird für Tests verwendet und da können auch Tests aufgenommen werden die noch nicht im master Branch erfolgreich laufen.

Ja es gibt 2 fast gleiche Branchs .... diese sind sehr Different. Wenn ich diesen nun gleich ziehe, weil das Master vom Umfang der Funktionen des TOOL´s voran schritt, so ist Pre_Release ebenso ohne die Daten.

Frage: WIESO testen wir etwas im pre-release wenn die Tests noch nicht fertig sind? WIESO machen wir es nicht gleich richtig?
Wenn wir im Pre... immer voraus eilen und im Master etwas rein kommt, weil der Code oder das TOOL entwickelt bzw. verbessert wird, so kommen Konflikte auf.

elektron-bbs · 2022-12-14T20:14:08Z

Generelle Frage: Wann sind wo (master, pre-release) Testdaten erforderlich?

Die Tests werden einmal mit den Daten aus pre-release und einmal mit denen aus dem master ausgeführt. Wenn es Fehler im pre-release gibt, dann wird der Test nicht als fehlerhaft gewertet, das ist eigentlich alles.

Sollten wir dann nicht pre-release "beerdigen", wenn es es eh nichts auswirft?

sidey79 · 2022-12-14T20:21:16Z

Sollten wir dann nicht pre-release "beerdigen", wenn es es eh nichts auswirft?

Sobald alle Testdaten bei den Modulen liegen können wir das machen. Jetzt ist es doch praktisch.

elektron-bbs · 2022-12-14T20:31:20Z

Mir nutzt es aber nichts, wenn ich auf Fehler in den Tests erst dann aufmerksam gemacht werde, wenn ich Test-Daten im Master-Branch hinterlegt habe und vorher denke, es ist alles im grünen Bereich, weil nur mit pre-release getestet wird und das keine Fehler ausgibt.
Wenn ich die Test-Daten vorher schon in Master lege, blockiere ich aber damit andere Pull requests.

sidey79 · 2022-12-14T20:34:36Z

Richtig erkannt.
Da ist manuelles nachschauen angesagt, aber das hat sich ja in kürze erledigt

HomeAutoUser · 2022-12-14T20:49:46Z

Da ist manuelles nachschauen angesagt, aber das hat sich ja in kürze erledigt

Ist das die Aussage um sämtliche Tests fehlerfrei zu gestalten erstmal oder die Zusage um nur den Master Branch zu nutzen ;-) ?

sidey79 · 2022-12-14T20:57:54Z

Da ist manuelles nachschauen angesagt, aber das hat sich ja in kürze erledigt

Ist das die Aussage um sämtliche Tests fehlerfrei zu gestalten erstmal oder die Zusage um nur den Master Branch zu nutzen ;-) ?

Die Frage irritiert mich. Das mit dem "master" Branch hat sich doch erledigt wenn die Testdaten migriert wurden.

HomeAutoUser · 2022-12-14T21:03:23Z

Ich denke wir kommunizieren alle etwas "aneinander vorbei machmal" oder jeder von uns interpretiert aufgrund des großen Umfang der Tests etwas anderes.

Können wir nicht Fakten schaffen um nicht aneinander vorbei zu reden?

Testdaten SD_UT in Master und die Tests dazu fertig machen
zukünftig die Struktur vom neuen Schema JSON die Tests einbringen wie sie für SD_WS vorbereitet sind als Datensatz aber der bisherige Test noch nicht "umgeschrieben" wurde auf die Quelle

sidey79 · 2022-12-14T21:36:19Z

Ich bin ja schon dabei, das RDMsg Modul auf das neue Schema zu ändern :)

elektron-bbs · 2023-01-02T20:15:17Z

Die Tests liefen ja hier nun wieder nicht durch. Woran es liegt, kann ich leider nicht finden.

Auf jeden Fall sind in der testData.json keine Daten für DC-1961-TG mehr enthalten.
Im SIGNALduino_TOOL waren sie am 12.12.22 noch enthalten RFD-FHEM/SIGNALduino_TOOL@75d303b und wurden kurz darauf wieder entfernt RFD-FHEM/SIGNALduino_TOOL@306d256.

HomeAutoUser · 2023-01-02T20:21:55Z

Die Tests liefen ja hier nun wieder nicht durch. Woran es liegt, kann ich leider nicht finden.

Auf jeden Fall sind in der testData.json keine Daten für DC-1961-TG mehr enthalten. Im SIGNALduino_TOOL waren sie am 12.12.22 noch enthalten RFD-FHEM/SIGNALduino_TOOL@75d303b und wurden kurz darauf wieder entfernt RFD-FHEM/SIGNALduino_TOOL@306d256.

Da @sidey79 die Testdaten im testData.json haben möchte und im TOOL JSON diese nicht gewollt waren :-D grins so muss man nur die entfernten vom TOOL in die testData.json ergänzen.

sidey79 · 2023-01-02T22:20:12Z

Die Tests liefen ja hier nun wieder nicht durch. Woran es liegt, kann ich leider nicht finden.

Hab beim Mergen einen Konflikt übersehen. Der war schuld.

sidey79 · 2023-01-02T23:42:22Z

Die Tests liefen ja hier nun wieder nicht durch. Woran es liegt, kann ich leider nicht finden.

Habe beim Mergen einen Konflikt übersehen. Der war schuld.
Ich habe die Testdaten hinzugefügt. Sollte dann jetzt alles fertig sein hier oder?

elektron-bbs · 2023-01-03T19:40:11Z

Warum das jetzt bei mir wieder bockt, verstehe ich nicht.
Ich wollte eigentlich noch zweimal SD_BELL in den Metadaten ändern in SD_UT - übernimmst du das bitte?
Ansonsten können wir das so übernehmen.

sidey79 · 2023-01-03T21:09:12Z

Das liegt daran, dass Du hier 35 commits eingefügt hast :(
2c10645

Den Branch auf den zuletzt richtigen Stand zurücksetzen würde das Problem beseitigen.

sidey79 · 2023-01-04T10:27:08Z

@elektron-bbs

Ich hab den Branch zurückgesetzt und die Testdaten wieder eingecheckt. Sollte jetzt wieder passen.

elektron-bbs · 2023-01-04T16:00:42Z

Alles klar, danke.
Ich vergreife mich jetzt besser nicht nochmal daran, Github Desktop scheint da irgend etwas falsch zu machen.
Änderst du bitte noch die beiden Einträge in den Metadaten vom 14_SD_UT.pm:

    "x_commandref": {
      "web": "https://commandref.fhem.de/#SD_BELL"

    "x_wiki": {
      "web": "https://wiki.fhem.de/wiki/SD_BELL"

SD_BELL -> SD_UT

Dann könnten wir mergen.

Metadata fixed

added Testdata from RFD-FHEM/SIGNALduino_TOOL updated revision

sidey79 · 2023-01-04T17:41:47Z

Alles klar, danke. Ich vergreife mich jetzt besser nicht nochmal daran, Github Desktop scheint da irgend etwas falsch zu machen.

Naja falsch würde ich so nicht sagen, aber wenn man einen merge in einem branch macht in dem ich an der Historie rumgefuhrwerkt hat, dann kommt vielleicht nicht das gewünschte dabei heraus ;)

Da ich GH Desktop selbst nicht nutze, kann ich nicht exakt sagen wie ich die Option nennt, aber vermutlich würde sowas wie reset current branch to xxx helfen. xxx wäre dann der Stand vom remote branch oder ein früherer commit.

Änderst du bitte noch die beiden Einträge in den Metadaten vom 14_SD_UT.pm:
    "x_commandref": {
      "web": "https://commandref.fhem.de/#SD_BELL"

    "x_wiki": {
      "web": "https://wiki.fhem.de/wiki/SD_BELL"

Den wiki Eintrag habe ich entfernt, da es diese Wikiseite nicht gibt, Commandref habe ich angepasst.
Ich hoffe es stimmt nun alles.

elektron-bbs · 2023-01-04T19:37:04Z

Naja falsch würde ich so nicht sagen, aber wenn man einen merge in einem branch macht in dem ich an der Historie rumgefuhrwerkt hat, dann kommt vielleicht nicht das gewünschte dabei heraus ;)

So sieht es wohl aus...

Da ich GH Desktop selbst nicht nutze, kann ich nicht exakt sagen wie ich die Option nennt, aber vermutlich würde sowas wie reset current branch to xxx helfen. xxx wäre dann der Stand vom remote branch oder ein früherer commit.

Ich habe dann heute nochmal etwas gelesen - genau diesen reset scheint es bei Github-Desktop nicht zu geben.

Den wiki Eintrag habe ich entfernt, da es diese Wikiseite nicht gibt, Commandref habe ich angepasst. Ich hoffe es stimmt nun alles.

Ich denke ja, fehlt jetzt nur noch ein Review...

sidey79 force-pushed the master_SD_UT_DC-1961-TG branch from d7d3e3c to d973056 Compare December 11, 2022 21:42

sidey79 mentioned this pull request Dec 12, 2022

TEST - only Update 90_SIGNALduino_un.pm #1131

Closed

7 tasks

sidey79 force-pushed the master_SD_UT_DC-1961-TG branch from 09178ff to cc1f232 Compare December 12, 2022 21:10

sidey79 force-pushed the master_SD_UT_DC-1961-TG branch from 46d8d2c to 9c00a46 Compare January 2, 2023 22:15

sidey79 force-pushed the master_SD_UT_DC-1961-TG branch from 9bdadb3 to 00de346 Compare January 2, 2023 23:41

Imported Changes

c516c46

sidey79 force-pushed the master_SD_UT_DC-1961-TG branch 2 times, most recently from 5a0bd53 to 22bf73d Compare January 4, 2023 10:26

sidey79 force-pushed the master_SD_UT_DC-1961-TG branch from a8898a2 to 8165e4c Compare January 4, 2023 17:31

sidey79 added 2 commits January 4, 2023 18:33

14_SD_UT

c85484d

Metadata fixed

testData.json

4700818

added Testdata from RFD-FHEM/SIGNALduino_TOOL updated revision

sidey79 force-pushed the master_SD_UT_DC-1961-TG branch from 8165e4c to 4700818 Compare January 4, 2023 17:35

Update Versiondate

7d3da67

sidey79 approved these changes Jan 4, 2023

View reviewed changes

elektron-bbs merged commit 9eb0eee into master Jan 4, 2023

elektron-bbs deleted the master_SD_UT_DC-1961-TG branch February 20, 2023 11:59

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SD_UT remote control DC-1961-TG #1129

SD_UT remote control DC-1961-TG #1129

elektron-bbs commented Dec 10, 2022 •

edited by sidey79

Loading

codecov bot commented Dec 10, 2022 •

edited

Loading

elektron-bbs commented Dec 10, 2022

sidey79 commented Dec 10, 2022 •

edited

Loading

elektron-bbs commented Dec 11, 2022

sidey79 commented Dec 11, 2022

elektron-bbs commented Dec 13, 2022

sidey79 commented Dec 13, 2022

elektron-bbs commented Dec 14, 2022

sidey79 commented Dec 14, 2022

HomeAutoUser commented Dec 14, 2022

sidey79 commented Dec 14, 2022

HomeAutoUser commented Dec 14, 2022 •

edited

Loading

elektron-bbs commented Dec 14, 2022

sidey79 commented Dec 14, 2022

elektron-bbs commented Dec 14, 2022

sidey79 commented Dec 14, 2022

HomeAutoUser commented Dec 14, 2022

sidey79 commented Dec 14, 2022

HomeAutoUser commented Dec 14, 2022

sidey79 commented Dec 14, 2022

elektron-bbs commented Jan 2, 2023

HomeAutoUser commented Jan 2, 2023

sidey79 commented Jan 2, 2023

sidey79 commented Jan 2, 2023 •

edited

Loading

elektron-bbs commented Jan 3, 2023

sidey79 commented Jan 3, 2023

sidey79 commented Jan 4, 2023

elektron-bbs commented Jan 4, 2023

sidey79 commented Jan 4, 2023

elektron-bbs commented Jan 4, 2023

SD_UT remote control DC-1961-TG #1129

SD_UT remote control DC-1961-TG #1129

Conversation

elektron-bbs commented Dec 10, 2022 • edited by sidey79 Loading

codecov bot commented Dec 10, 2022 • edited Loading

Codecov Report

elektron-bbs commented Dec 10, 2022

sidey79 commented Dec 10, 2022 • edited Loading

elektron-bbs commented Dec 11, 2022

sidey79 commented Dec 11, 2022

elektron-bbs commented Dec 13, 2022

sidey79 commented Dec 13, 2022

elektron-bbs commented Dec 14, 2022

sidey79 commented Dec 14, 2022

HomeAutoUser commented Dec 14, 2022

sidey79 commented Dec 14, 2022

HomeAutoUser commented Dec 14, 2022 • edited Loading

elektron-bbs commented Dec 14, 2022

sidey79 commented Dec 14, 2022

elektron-bbs commented Dec 14, 2022

sidey79 commented Dec 14, 2022

HomeAutoUser commented Dec 14, 2022

sidey79 commented Dec 14, 2022

HomeAutoUser commented Dec 14, 2022

sidey79 commented Dec 14, 2022

elektron-bbs commented Jan 2, 2023

HomeAutoUser commented Jan 2, 2023

sidey79 commented Jan 2, 2023

sidey79 commented Jan 2, 2023 • edited Loading

elektron-bbs commented Jan 3, 2023

sidey79 commented Jan 3, 2023

sidey79 commented Jan 4, 2023

elektron-bbs commented Jan 4, 2023

sidey79 commented Jan 4, 2023

elektron-bbs commented Jan 4, 2023

elektron-bbs commented Dec 10, 2022 •

edited by sidey79

Loading

codecov bot commented Dec 10, 2022 •

edited

Loading

sidey79 commented Dec 10, 2022 •

edited

Loading

HomeAutoUser commented Dec 14, 2022 •

edited

Loading

sidey79 commented Jan 2, 2023 •

edited

Loading