JSON schreiben Fehler - Githubissues

HomeAutoUser commented 1 year ago

Seit dem https://github.com/RFD-FHEM/SIGNALduino_TOOL/pull/84 funktioniert das schreiben nicht mehr korrekt nachdem mich @elektron-bbs im Gespräch darauf aufmerksam machte.

@sidey79 wie hier https://github.com/RFD-FHEM/SIGNALduino_TOOL/pull/84/files schonmal angefragt von mir, ist es nicht günstiger diese Erweiterungen für die Tests in eine "Rubrik" zu schieben oder direkt in die Tests zu verfrachten?

Es muss auf jedenfall das Schreiben als Bug behoben werden, aber das habe ich nocht nicht angegriffen, da ich nicht weiß wie weit du vielleicht mal noch was ergänzen möchtest in den vielen Tests ...

sidey79 commented 1 year ago

Was meinst Du mit Schreiben?

An eine Diskussion mit einer Rubrik erinnere ich mich auch nicht. Was wäre denn eine Rubrik und welche Auswirkung hat sie?

HomeAutoUser commented 1 year ago

Was meinst Du mit Schreiben?

Das TOOL hat die Möglichkeit via Set Befehl die eingelesene JSON selbst zu schreiben nachdem man diese geupdatet hatte. (Bsp. nach einem Dispatch oder weil sich ein Kommentar oder Reading verändert) Derzeit schreibt es die Struktur stur Zeile für Zeile. Ich würde das ggf. auf use JSON::MaybeXS (); umstellen. -> siehe https://perlmaven.com/json -> Encoding JSON in a human-readable way

An eine Diskussion mit einer Rubrik erinnere ich mich auch nicht. Was wäre denn eine Rubrik und welche Auswirkung hat sie?

Eine echte Diskussion war es nicht. Ich fragte dich nur, ob man die Ergänzungen nicht komplett in die geschriebenen Tests auslagern kann ODER ob wir für solche Fälle innerhalb der JSON den Schlüssel "Tests" erzeugen. Somit weiß man sofort, es handelt sich um Dinge welche für einzelne Tests benötigt werden und nicht zu einem Missverständnis kommen kann, das jemand denkt, es gibt das Reading setreading bzw. das es ein Befehl o.ä. wäre.

Vorschlag, Struktur dafür:

    {
      "dmsg":"W115#9104143025BE18FFFFFF2928925A97FFF0000000000000000003", "comment":"BRESSER 6-in-1 temp diff to high", "user":"elektron-bbs",
      "internals": {"DEF":"SD_WS_115_0", "NAME":"SD_WS_115_0"},
      "readings": {"state":"T: -7.5 H: 97 W: 0", "batteryChanged":"1", "batteryState":"ok", "channel":"0", "humidity":"97", "temperature":"-7.5", "type":"Bresser_6in1, new Bresser_5in1", "uv":"0", "windDirectionDegree":"292", "windDirectionText":"WNW", "windGust":"0", "windSpeed":"0"},
      "minProtocolVersion":"1.48", "revision_entry":"2022-11-20 20:27:05",
      "revision_modul":"14_SD_WS.pm v3.5.4 2022-11-14 20:37:55Z sidey79",
      "rmsg":"MN;D=9104143025BE18FFFFFF2928925A97FFF0000000000000000003;R=189;",
      "tests": {"setreadings":{"temperature":"-1.5", "humidity":"32"},"returns":{"ParseFn":""}}
    }

Ich muss das TOOL eh fixen, das der derzeitige "Schreibbug" behoben wird und so wollte ich dies vorher klären. Über die Bezeichnung 'tests' könnte man ggf auch anpassen in einen passenderen Namen. ( Bsp: 'testsOnline' ) ...

sidey79 commented 1 year ago

@HomeAutoUser Danke für deine Antwort.

Eine echte Diskussion war es nicht. Ich fragte dich nur, ob man die Ergänzungen nicht komplett in die geschriebenen Tests auslagern kann

Es ist möglich, das JSON (Testdaten) je Modul in die Tests zu hinterlegen. Für Spezialfälle machen wir das ja auch schon. Ich bin mir aber nicht mehr ganz sicher, wieso wir das ausgelagert haben, es gab da einen Grund, wenn es die Angelegenheit jedoch vereinfacht dann lass es uns tun. Prinzipiell könnte man das TOOL ja befähigen (sofern nötig) auch diese Testdaten verwenden zu können.

HomeAutoUser commented 1 year ago

@HomeAutoUser Danke für deine Antwort.

Kein Problem, gerne :-) @sidey79

Es ist möglich, das JSON (Testdaten) je Modul in die Tests zu hinterlegen. Für Spezialfälle machen wir das ja auch schon. Ich bin mir aber nicht mehr ganz sicher, wieso wir das ausgelagert haben, es gab da einen Grund, wenn es die Angelegenheit jedoch vereinfacht dann lass es uns tun. Prinzipiell könnte man das TOOL ja befähigen (sofern nötig) auch diese Testdaten verwenden zu können.

Ich bin gerade am überlegen was am sinnvollsten ist. Damals waren wir an die JSON Sammlung herangegangen mit der Zielsetzung das Modul zu testen bzw. DMSG´s zu besitzen. Da wären die Einträge für die Test´s "fremd" denke ich. Mit dem Hintergrund zu wissen, das wir eh in den Tests schon spezielle Fälle mit Testdaten ausgelagert haben in den jeweiligen Tests, so würde ich die zusätzlich hinzugefügten Werte ("setreading" ... "return ...) ja ebenso in die Testfiles integrieren.

Prinzipiell könnte man das TOOL ja befähigen (sofern nötig) auch diese Testdaten verwenden zu können.

Ich denke, da wäre eine ähnliche Struktur nur für Tests sinnvoll. Mit dem TOOL macht es wenig Sinn, die setreading Werte zu testen, weil ich nach dem Einlesen, das Ergebnis nur sehe. Da kommen deine selbst geschriebenen Tests mit Ist und Soll Wert schon besser zum tragen.

sidey79 commented 1 year ago

Um sicher zu gehen, dass wir vom gleichen reden. Das SIGNALDUINO_TOOL kommt mit dem erweiterten Schema nicht mehr zurecht.

a) Du schlägst daher vor, das Schema zu ändern und alles was nur für tests relevant ist in ein Objekt tests zu schieben. b) Die ganzen Datensätze würden wir allerdings auch in das jeweilige Modulrepo verschieben (bis auf Ausnahmen liegen die ja im gleichen repo). Wenn ja, dann brauchen wir das Schema nicht anpassen glaube ich.

Das wäre ein Datensatz, der zum Modul SD_WS verhoben werden würde:

{
      "dmsg":"W115#9104143025BE18FFFFFF2928925A97FFF0000000000000000003", "comment":"BRESSER 6-in-1 temp diff to high", "user":"elektron-bbs",
      "internals": {"DEF":"SD_WS_115_0", "NAME":"SD_WS_115_0"},
      "readings": {"state":"T: -7.5 H: 97 W: 0", "batteryChanged":"1", "batteryState":"ok", "channel":"0", "humidity":"97", "temperature":"-7.5", "type":"Bresser_6in1, new Bresser_5in1", "uv":"0", "windDirectionDegree":"292", "windDirectionText":"WNW", "windGust":"0", "windSpeed":"0"},
      "minProtocolVersion":"1.48", "revision_entry":"2022-11-20 20:27:05",
      "revision_modul":"14_SD_WS.pm v3.5.4 2022-11-14 20:37:55Z sidey79",
      "rmsg":"MN;D=9104143025BE18FFFFFF2928925A97FFF0000000000000000003;R=189;",
      "tests": {"setreadings":{"temperature":"-1.5", "humidity":"32"},"returns":{"ParseFn":""}}
    }

Ich bin gespannt, ob ich das richtig verstanden habe.

HomeAutoUser commented 1 year ago

Hallo @sidey79, sorry für die verstätete Antwort.

Ich bin gespannt, ob ich das richtig verstanden habe.

Ja, du hast es richtig verstanden.

Ich denke, es wäre das vernünftigste, wenn die Variante a)

a) Du schlägst daher vor, das Schema zu ändern und alles was nur für tests relevant ist in ein Objekt tests zu schieben.

umgesetzt wird. Der einzige "Schönheitsfehler" ist, das die Datei etwas länger wird. Die Bibliothek schreibt es so strukturiert zusammen.

Wäre eine solche Anwordnung für dich okay?

[
         {
            "comment" : "BRESSER 6-in-1 temp diff to high",
            "dmsg" : "W115#9104143025BE18FFFFFF2928925A97FFF0000000000000000003",
            "internals" : {
               "DEF" : "SD_WS_115_0",
               "NAME" : "SD_WS_115_0"
            },
            "minProtocolVersion" : "1.48",
            "readings" : {
               "batteryChanged" : "1",
               "batteryState" : "ok",
               "channel" : "0",
               "humidity" : "97",
               "state" : "T: -7.5 H: 97 W: 0",
               "temperature" : "-7.5",
               "type" : "Bresser_6in1, new Bresser_5in1",
               "uv" : "0",
               "windDirectionDegree" : "292",
               "windDirectionText" : "WNW",
               "windGust" : "0",
               "windSpeed" : "0"
            },
            "revision_entry" : "2022-11-20 20:27:05",
            "revision_modul" : "14_SD_WS.pm v3.5.4 2022-11-14 20:37:55Z sidey79",
            "rmsg" : "MN;D=9104143025BE18FFFFFF2928925A97FFF0000000000000000003;R=189;",
            "tests" : {
               "returns" : {
                  "ParseFn" : ""
               },
               "setreadings" : {
                  "humidity" : "32",
                  "temperature" : "-1.5"
               }
            },
            "user" : "elektron-bbs"
         }
]

Somit sind alle Daten an einer Position. (keine doppelte Datenpflege) Für zukünfige Tests ist der Bereich "tests". Somit weiß jeder sofort was los ist.

sidey79 commented 1 year ago

Für welchen Zweck lassen wir die Daten in diesem Repo. Ich dachte wir sollen die verschieben.

HomeAutoUser commented 1 year ago

Verschieben in ein anderes Repo nicht. Da habe ich mich vermutlich falsch ausgedrückt. Mit verschieben meinte ich, aus dem JSON https://github.com/RFD-FHEM/SIGNALduino_TOOL/blob/master/FHEM/lib/SD_Device_ProtocolList.json in die zugehörige "Testsdatei" des Modules. Bsp.: https://github.com/RFD-FHEM/RFFHEM/blob/master/t/FHEM/14_SD_WS/testData.json oder https://github.com/RFD-FHEM/RFFHEM/blob/master/t/FHEM/14_SD_UT/testData.json

Da kommt mir die Frage auf, wenn ich die beiden testData.json´s sehe, wieso im TOOL dann ebenso Werte sind welche für Tests benötigt werden? Dazu fehlt mir glaube ich, der Zusammenhang wie und wo welche Tests ihre Daten nehmen.

sidey79 commented 1 year ago

Wir haben das gleiche Verständnis von Verschieben, denn die Module liegen ja in einem anderen Repo.

Nur wozu dann das Schema anpassen, wenn die Daten umziehen.

HomeAutoUser commented 1 year ago

Meinst du mit

Nur wozu dann das Schema anpassen, wenn die Daten umziehen.

das hier?

von:

    {
      "setreadings":{"temperature":"-1.5", "humidity":"32"},      
      "dmsg":"W115#9104143025BE18FFFFFF2928925A97FFF0000000000000000003", "comment":"BRESSER 6-in-1 temp diff to high", "user":"elektron-bbs",
      "internals": {"DEF":"SD_WS_115_0", "NAME":"SD_WS_115_0"},
      "readings": {"state":"T: -7.5 H: 97 W: 0", "batteryChanged":"1", "batteryState":"ok", "channel":"0", "humidity":"97", "temperature":"-7.5", "type":"Bresser_6in1, new Bresser_5in1", "uv":"0", "windDirectionDegree":"292", "windDirectionText":"WNW", "windGust":"0", "windSpeed":"0"},
      "minProtocolVersion":"1.48", "revision_entry":"2022-11-20 20:27:05",
      "revision_modul":"14_SD_WS.pm v3.5.4 2022-11-14 20:37:55Z sidey79",
      "rmsg":"MN;D=9104143025BE18FFFFFF2928925A97FFF0000000000000000003;R=189;",
      "returns":{"ParseFn" : ""}
    }

in:

         {
            "comment" : "BRESSER 6-in-1 temp diff to high",
            "dmsg" : "W115#9104143025BE18FFFFFF2928925A97FFF0000000000000000003",
            "internals" : {
               "DEF" : "SD_WS_115_0",
               "NAME" : "SD_WS_115_0"
            },
            "minProtocolVersion" : "1.48",
            "readings" : {
               "batteryChanged" : "1",
               "batteryState" : "ok",
               "channel" : "0",
               "humidity" : "97",
               "state" : "T: -7.5 H: 97 W: 0",
               "temperature" : "-7.5",
               "type" : "Bresser_6in1, new Bresser_5in1",
               "uv" : "0",
               "windDirectionDegree" : "292",
               "windDirectionText" : "WNW",
               "windGust" : "0",
               "windSpeed" : "0"
            },
            "revision_entry" : "2022-11-20 20:27:05",
            "revision_modul" : "14_SD_WS.pm v3.5.4 2022-11-14 20:37:55Z sidey79",
            "rmsg" : "MN;D=9104143025BE18FFFFFF2928925A97FFF0000000000000000003;R=189;",
            "tests" : {
               "returns" : {
                  "ParseFn" : ""
               },
               "setreadings" : {
                  "humidity" : "32",
                  "temperature" : "-1.5"
               }
            },
            "user" : "elektron-bbs"
         }

Der Unterschied liegt darin, das ich im Zuge des Umziehens, das Schreiben in die Datei auf eine Bibliothek umstelle um Zukunft nicht bei div. Änderungen auf einmal nicht wieder einen Bug im Schreiben der Daten habe. Bisher verläuft das Schreiben nach einer manuell erstellten Struktur mit "print Eintrag1" , "print Leerzeichen + Komma", print "Eintrag2" .... und dann mit Bibliothek "print Komplettdaten" ;-)

Um genau zu sein,

einmal Umzug der Daten nach "tests"zur besseren Übersicht und Eindeutigkeit
zusätzlich der Umstieg auf Datei schreiben via Bibliothek um Code zu sparen + zukünfig "sicher" zu sein, das alles richtig geschrieben wird.

sidey79 commented 1 year ago

Okay, ziehen wir erst 1:1 um und verändern dann das Schema?

HomeAutoUser commented 1 year ago

So machen wir es :-) Das geht Einfach mit der neuen Version.

Ich würde so vorgehen, 1) Datei 88_SIGNALduino_TOOL.pm hochladen inklusive 1:1 SD_Device_ProtocolList.json nur mit neuem Schema 2) in RFHEM ein Test PR erstellen um alle Tests anzuschubsen, welche mit i.O durchlaufen müssen 3) verändertes Schema (Eintrag "test" ...) der SD_Device_ProtocolList.json hochladen im TOOL Repro 4) die Tests von dir anpassen, das das in RFHEM alles Tests i.O durchlaufen

Oder müssen wir das anders angehen?

sidey79 commented 1 year ago

Folgende Anmerkungen zu

In einem Feature Branch erstellen.
Ja, allerdings befindet sich ein Testdatensatz in den Testdaten den das Modul noch nicht kann(@elektron-bbs war da etwas zu früh dran mit dem Master), ggf. einfach den vorherigen commit verwenden.
Verstehe ich nicht, das Schema ist doch schon in Schritt 1. angepasst:)
Klingt wieder schlüssig, wobei das in 2. schon angepasst ist.

Kann ich bei irgendwas helfen? Sobald der erste Datensatz mit neuem Schema verfügbar ist, kann ich das Modul schon mal anpassen.

HomeAutoUser commented 1 year ago

Kann ich bei irgendwas helfen? Sobald der erste Datensatz mit neuem Schema verfügbar ist, kann ich das Modul schon mal anpassen.

Sobald das Testergebnis da ist, könnte ich die JSON wie hier https://github.com/RFD-FHEM/SIGNALduino_TOOL/issues/87#issuecomment-1347080655 ändern und hochladen. Dann wärest du am Part um die Tests, welche dann auf neue Positionen zeigen zu ändern von BRESSER 6-in-1 temp diff to high -> https://github.com/RFD-FHEM/SIGNALduino_TOOL/commit/4c8df7704e69f7cf275f64382226adb0f60940d1

HomeAutoUser commented 1 year ago

Scheinbar ging das doch nicht so einfach wie gedacht. Da muss ich erstmal stöbern wo nun die Tests stolpern. Im Grunde habe ich an den einzelnen Datensätzen der JSON nichts geändert. Die Struktur ist nur umgestellt im JSON.

HomeAutoUser commented 1 year ago

Wir haben den ersten Schritt geschafft. Nun wäre die Verschiebung dran. Wie machen wir es? Ich das JSON und du die Tests oder machst du alles zusammen?

sidey79 commented 1 year ago

Sollen wir die Tests mit dem aktuellen Stand verschieben und danach das Schema anpassen?

HomeAutoUser commented 1 year ago

Das Schema habe ich angepasst hier https://github.com/RFD-FHEM/SIGNALduino_TOOL/commit/c3a1504219e0c764ecbf4fcf6eee9a92014a4be8 und ich rechne eigendlich mit einem Test der fehl schlägt hier https://github.com/RFD-FHEM/RFFHEM/pull/1131. Sollte das nicht der Fall sein, so weiß ich nicht, wovon die Werte im JSON genutzt werden.

Die Tests könnte man in dem Branch hier https://github.com/RFD-FHEM/RFFHEM/tree/master_fix_tests_JSON anpassen und dann einen PR zum master vollziehen. Dann sollte das ganze abgeschlossen sein denke ich.

PS: Wieso geht der Test mit dem schon umgestellten JSON im master? Waren die Werte wirklich genutzt? https://github.com/RFD-FHEM/SIGNALduino_TOOL/commit/c3a1504219e0c764ecbf4fcf6eee9a92014a4be8

sidey79 commented 1 year ago

Testdaten kommen von hier: https://github.com/RFD-FHEM/RFFHEM/blob/master_fix_tests_JSON/lib/Test2/SIGNALduino/RDmsg.pm#L19

Hast Du das jetzt schon im master branch umgestellt? Für heute ist für mich hier Ende :)

HomeAutoUser commented 1 year ago

Hast Du das jetzt schon im master branch umgestellt?

Ja habe ich (https://github.com/RFD-FHEM/SIGNALduino_TOOL/commit/c3a1504219e0c764ecbf4fcf6eee9a92014a4be8). Es wundert mich nur sehr, wieso hier https://github.com/RFD-FHEM/RFFHEM/pull/1131 kein Fehler kommt? ;-)

Kann es sein, das die beiden Einträge "nur Überreste vom BresserVersuch" sind und sämtliche Testdaten wo du setreading benutzt von hier (https://github.com/RFD-FHEM/RFFHEM/commit/9c5dc2d7ccd4b79bacd4eeaaf8819a1a5a08eb4f#diff-aad10fe36ef94ae3b1849906b9d5d7b57b0794f5e4b1615ef01c9ef48843355b) genommen werden?

Wenn JA, dann kostet das ein Weihnachtsgeschenk :-D

sidey79 commented 1 year ago

Im Moment werden drei Quellen angezapft. Der Test läuft jeweils mit den Daten aus diesem Repo (insgesamt zwei mal) und dann noch mit den lokal hinterlegten Daten.

HomeAutoUser commented 1 year ago

Hallo @sidey79 ich habe mir das heute nochmal angesehen. Ich denke nun durchzusehen in dem Falle SD_WS.

Scheinbar ich bin ich über deine "Codeleichen" gestolpert welche du nicht entferntest im JSON des TOOL´s.

Commits on Nov 26, 2022 / https://github.com/RFD-FHEM/SIGNALduino_TOOL/commit/4c8df7704e69f7cf275f64382226adb0f60940d1 --> hinzugefügt Daten von setreadings & return in ./FHEM/lib/SD_Device_ProtocolList.json
Commits on Nov 27, 2022 / https://github.com/RFD-FHEM/RFFHEM/commit/9c5dc2d7ccd4b79bacd4eeaaf8819a1a5a08eb4f --> Datei entfernt ./t/FHEM/14_SD_WS/09_parseDatat.t -> Datenquelle für Tests von https://raw.githubusercontent.com/RFD-FHEM/SIGNALduino_TOOL/pre-release/FHEM/lib/SD_Device_ProtocolList.json --> Datei entfernt ./t/FHEM/14_SD_WS/09_parseDatat.t -> Datenquelle für Tests von https://raw.githubusercontent.com/RFD-FHEM/SIGNALduino_TOOL/master/FHEM/lib/SD_Device_ProtocolList.json --> Datei hinzugefügt ./t/FHEM/14_SD_WS/09_parseData.t -> Datenquelle umverlegt auf ./t/FHEM/14_SD_WS/testData.json
seither nutzt du nicht mehr für das Modul die Daten vom Commits on Nov 26, 2022 / https://github.com/RFD-FHEM/SIGNALduino_TOOL/commit/4c8df7704e69f7cf275f64382226adb0f60940d1 --> Leiche worüber ich stolperte und mitbekam, das das TOOL einen Bug im Schreiben hat

Vorschlag:

Da in https://github.com/RFD-FHEM/RFFHEM/blob/9c5dc2d7ccd4b79bacd4eeaaf8819a1a5a08eb4f/t/FHEM/14_SD_WS/testData.json jeweils die Daten zu 85% aus dem JSON - TOOL kopiert wurden und für Testzwecke du Attribute setzt, Setreading nutzt und return .... das man die Struktur so schafft, das alles nur mit minimalem Aufwand an einer Stelle gepflegt wird. So stelle ich mir das vor ....

   {
      "data" : [
         {
            "comment" : "Temp. / Humidity sensor",
            "dmsg" : "W115#9104143025BE18FFFFFF2928925A97FFF0000000000000000003",
            "internals" : {
               "DEF" : "SD_WS_115_0",
               "NAME" : "SD_WS_115_0"
            },
            "minProtocolVersion" : "1.48",
            "readings" : {
               "batteryChanged" : "1",
               "batteryState" : "ok",
               "channel" : "0",
               "humidity" : "97",
               "state" : "T: -7.5 H: 97 W: 0",
               "temperature" : "-7.5",
               "type" : "Bresser_6in1, new Bresser_5in1",
               "uv" : "0",
               "windDirectionDegree" : "292",
               "windDirectionText" : "WNW",
               "windGust" : "0",
               "windSpeed" : "0"
            },
            "revision_entry" : "2022-11-20 20:27:05",
            "revision_modul" : "14_SD_WS.pm v3.5.4 2022-11-14 20:37:55Z sidey79",
            "rmsg" : "MN;D=9104143025BE18FFFFFF2928925A97FFF0000000000000000003;R=189;",
            "tests" : [
               {
                 "attributes": {"max-deviation-hum":"65"},
                 "comment":"BRESSER 6-in-1 temp diff ok with attr",
                 "returns" : {
                   "ParseFn" : ""
                 },
                 "setreadings" : {
                    "humidity" : "32",
                    "temperature" : "-1.5"
                 }
               },
               {
                 "attributes": {"max-deviation-temp":"50"},
                 "comment":"BRESSER 6-in-1 temp diff ok with attr",
                 "returns" : {
                    "ParseFn" : ""
                 },
                 "setreadings" : {
                    "humidity" : "92",
                    "temperature":"-1.5"
                 }
               }
            ],
            "user" : "elektron-bbs"
         }
      ],
      "id" : "115",
      "module" : "SD_WS",
      "name" : "BRESSER 6-in-1"
   }

Somit vereinen wir alles und es ist kompakt zusammen ohne doppel an stellen zu pflegen. --> die Datei testData.json wäre dann hinfällig --> keine doppelten Keys wie dmsg, internals, readings, rmsg ... Das Interesse verfolgt ebenso @elektron-bbs weil man so mit einem Blick sieht, was los ist. Wenn man den Key "tests" sieht, so siehst du mit wenigen Blicken, was gesetzt wird an Attributen, Setreadings ...

Kannst du mir folgen? Wie denkst du darüber und liege ich richtig mit der "Codeleiche" ? Wenn ja, dann grrrrrrrrrr ;-)

sidey79 commented 1 year ago

Ich kann dir nur halb folgen.

09_parseDatat.t würde umbenannt weil ein t zu viel im Namen.

In 09_parseData.t sind keine Datenquellen spezifiziert, somit können da auch keine entfernt werden

Die Daten in testData.json sind für das Modul nicht geeignet, da hier spezifische Verhaltensweisen geprüft werden.

Die Idee mit mehrern Szenarien in Tests gefällt mir gut. Warum nun aber TestData.json überflüssig sein soll verstehe ich nicht. Hier sollen doch die Daten vom Prinzip hinterlegt werden. Dann gelangen sie auch immer mit dem richtigen Merge in den Master und wir haben einen konsistent Stand.

HomeAutoUser commented 1 year ago

09_parseDatat.t würde umbenannt weil ein t zu viel im Namen.

ja das ist plausibel :-)

In 09_parseData.t sind keine Datenquellen spezifiziert, somit können da auch keine entfernt werden

... bei den vielen Standorten sehe ich wirklich nicht mehr durch und ich spreche da auch für @elektron-bbs

Die Idee mit mehrern Szenarien in Tests gefällt mir gut. Warum nun aber TestData.json überflüssig sein soll verstehe ich nicht. Hier sollen doch die Daten vom Prinzip hinterlegt werden. Dann gelangen sie auch immer mit dem richtigen Merge in den Master und wir haben einen konsistent Stand.

Dann behalten wir das so bei.

Wofür hast du dann aktuell im JSON https://github.com/RFD-FHEM/SIGNALduino_TOOL/commit/4c8df7704e69f7cf275f64382226adb0f60940d1 diese Zeilen. Wer ruft diese auf? Sind diese in Benutzung? Bisher schlug von den Test PR´s keiner fehl weil die Struktur schon auf tests: ... umgestellt ist. https://github.com/RFD-FHEM/SIGNALduino_TOOL/commit/c3a1504219e0c764ecbf4fcf6eee9a92014a4be8

sidey79 commented 1 year ago

In 09_parseData.t sind keine Datenquellen spezifiziert, somit können da auch keine entfernt werden

... bei den vielen Standorten sehe ich wirklich nicht mehr durch und ich spreche da auch für @elektron-bbs

Es gibt nur eine Stelle an denen die Quelle definiert ist: https://github.com/RFD-FHEM/RFFHEM/blob/master/lib/Test2/SIGNALduino/RDmsg.pm#L16

Sollte es noch abweichende Implementierungen geben, dann passe ich die auf den Standard an.

Wofür hast du dann aktuell im JSON 4c8df77 diese Zeilen. Wer ruft diese auf? Sind diese in Benutzung? Bisher schlug von den Test PR´s keiner fehl weil die Struktur schon auf tests: ... umgestellt ist. c3a1504

Glück gehabt. Der Test wird ausgeführt, mit dem was die Struktur hergibt. :) Allerdings müsste die Testabdeckung sinken, denn setreading wird nicht ausgeführt. Sobald das Reading temperature auf -1,5 stehen würde, hätten wir seitens parseFn einen anderen Rückgabewert, weil die Temperatur nicht aktualisiert worden wäre. So ist in der Tat alles schick für den Test, da die besondere Situation gar nicht hergestellt ist, dass die Differenz zu hoch ist.

    ok 125 - Checking parseFN for module: SD_WS device: BRESSER 6-in-1 TestNo: 3 (BRESSER 6-in-1 temp diff to high) {
        # device will be defined temporary
        ok 1 - Verify device return from defmod 
        ok 2 - verify parseFn return equal internal NAME
        ok 3 - Verify readings {
            1..12
            ok 1 - check reading windGust
            ok 2 - check reading windDirectionText
            ok 3 - check reading batteryChanged
            ok 4 - check reading temperature
            ok 5 - check reading humidity
            ok 6 - check reading windSpeed
            ok 7 - check reading batteryState
            ok 8 - check reading type
            ok 9 - check reading uv
            ok 10 - check reading state
            ok 11 - check reading windDirectionDegree
            ok 12 - check reading channel
        }
        ok 4 - Verify internals {
            1..2
            ok 1 - check internal DEF
            ok 2 - check internal NAME
        }
        1..4
    }

HomeAutoUser commented 1 year ago

Glück gehabt. Der Test wird ausgeführt, mit dem was die Struktur hergibt. :)

Aus deiner Antwort heraus entnehme ich, wir lassen es so, wie es derzeit ist. Keine Fehler treten auf. Oder Einsprüche?

https://github.com/RFD-FHEM/RFFHEM/blob/946f0df13924188df79f6b9cd88e8770c213830a/lib/Test2/SIGNALduino/RDmsg.pm#L96 wird das wirklich in dem Test berücksichtigt? Ich sehe in deinem o.g. Testergebnis kein note("readings will be set to defaults"); obwohl hier eines definiert ist. https://github.com/RFD-FHEM/SIGNALduino_TOOL/blob/b50f74adf4ba8f641607cd3b15bcca058bfc6643/FHEM/lib/SD_Device_ProtocolList.json#L7354:L7356

sidey79 commented 1 year ago

Glück gehabt. Der Test wird ausgeführt, mit dem was die Struktur hergibt. :)

Aus deiner Antwort heraus entnehme ich, wir lassen es so, wie es derzeit ist. Keine Fehler treten auf. Oder Einsprüche?

Du wolltest doch das Schema unterhalb von Tests noch auf eine Liste anpassen.

https://github.com/RFD-FHEM/RFFHEM/blob/946f0df13924188df79f6b9cd88e8770c213830a/lib/Test2/SIGNALduino/RDmsg.pm#L96 wird das wirklich in dem Test berücksichtigt? Ich sehe in deinem o.g. Testergebnis kein note("readings will be set to defaults"); obwohl hier eines definiert ist. https://github.com/RFD-FHEM/SIGNALduino_TOOL/blob/b50f74adf4ba8f641607cd3b15bcca058bfc6643/FHEM/lib/SD_Device_ProtocolList.json#L7354:L7356

Du hast doch das Schema verändert, für den Tests gibt es das setreading nicht an der erwarteten Stelle. Dafür muss ich ja das Testmodul erst auf das neue Schema anpassen. Da wollte ich jetzt aber warten bis das final ist :)

HomeAutoUser commented 1 year ago

Da wollte ich jetzt aber warten bis das final ist :)

Wenn du mir sagen kannst, wie weit das mal noch ergänzt wird :-)

Hauptgrund war, alles was für deine tests ist, in die eigene tests: { ... } zu bringen. <--- das ist dann für dich zum ausleben :-)

sidey79 commented 1 year ago

Da wollte ich jetzt aber warten bis das final ist :)

Wenn du mir sagen kannst, wie weit das mal noch ergänzt wird :-)

Du hattest doch weiter oben das Beispiel:

            "tests" : [
               {
                 "attributes": {"max-deviation-hum":"65"},
                 "comment":"BRESSER 6-in-1 temp diff ok with attr",
                 "returns" : {
                   "ParseFn" : ""
                 },
                 "setreadings" : {
                    "humidity" : "32",
                    "temperature" : "-1.5"
                 }
               },
               {
                 "attributes": {"max-deviation-temp":"50"},
                 "comment":"BRESSER 6-in-1 temp diff ok with attr",
                 "returns" : {
                    "ParseFn" : ""
                 },
                 "setreadings" : {
                    "humidity" : "92",
                    "temperature":"-1.5"
                 }
               }
            ],

Hauptgrund war, alles was für deine tests ist, in die eigene tests: { ... } zu bringen. <--- das ist dann für dich zum ausleben :-)

Ja verstehe ich ;)

HomeAutoUser commented 1 year ago

Du hattest doch weiter oben das Beispiel:

Das ist richtig. Ich kann den bisherigen Eintrag im File noch abändern in "tests:" [ {...}, {...} ] . Was dann aber alles hineinkommt hängt von deinen Tests ab.

Ich war der Annahme das

Die Daten in testData.json sind für das Modul nicht geeignet, da hier spezifische Verhaltensweisen geprüft werden.

das somit nicht viel weitere Werte darin kommen in "tests: ...."

Ich drehe mich irgendwie im Kreise .... Irgendwie sind die vielen Orte der Tests scheinbar schwer kommunizierbar und ich weiß nicht auf was du noch wartest oder erwartest von mir. hm

Es ist schon dunkel, werde mal G8 sagen ;-)

sidey79 commented 1 year ago

Du hattest doch weiter oben das Beispiel:

Das ist richtig. Ich kann den bisherigen Eintrag im File noch abändern in "tests:" [ {...}, {...} ] . Was dann aber alles hineinkommt hängt von deinen Tests ab.

Ja wäre nett, wenn Du das vorbereitest bevor wir die Daten überführen.

Die Daten in testData.json sind für das Modul nicht geeignet, da hier spezifische Verhaltensweisen geprüft werden.

das somit nicht viel weitere Werte darin kommen in "tests: ...."

Es gibt in den lokalen Testdaten mindestens einen Fall, in dem ist die dmsg korrupt um z.B. die CRC Prüfung zu testen.

Ich drehe mich irgendwie im Kreise .... Irgendwie sind die vielen Orte der Tests scheinbar schwer kommunizierbar und ich weiß nicht auf was du noch wartest oder erwartest von mir. hm

Geht mir auch so. Ich habe allerdings das Gefühl, dass wir immer ein kleines Stückchen weiter kommen. Am Ende haben wir alle Testdaten neben den Modulen liegen und eine skalierbare Struktur.

HomeAutoUser commented 1 year ago

Ja wäre nett, wenn Du das vorbereitest bevor wir die Daten überführen.

Das ist vollzogen. https://github.com/RFD-FHEM/SIGNALduino_TOOL/blob/c12fdeaab3fcd689e1b74f870bc1471f79a44c6c/FHEM/lib/SD_Device_ProtocolList.json#L7389:L7426

Ein erster lokaler Test mit Auflösung der https://github.com/RFD-FHEM/RFFHEM/blob/master/t/FHEM/14_SD_WS/testData.json war mir nur zum Teil gelungen. Ich versuche / stochere noch an der https://github.com/RFD-FHEM/RFFHEM/blob/master/t/FHEM/14_SD_WS/09_parseData.t welche dann alle Daten verarbeitet. Du schaust da bestimmt schneller durch.

sidey79 commented 1 year ago

Ich habe einige Anpassungen vorgenommen, jetzt haben wir die bisher vermissten Fehler:

https://github.com/RFD-FHEM/RFFHEM/tree/master_fix_tests_JSON

Bei den Tests für das SIGNAlduino Modul habe ich noch eine alte Baustelle (Anzahl an dispatches) gefunden. Weiterhin sind hier noch die Quellen der Testdaten zu hinterlegen. Mir schwebt ja vor, dass lokal liegende Daten automatisch gefunden werden und weitere remote Quellen eingebunden werden können.

HomeAutoUser commented 1 year ago

Ich habe mir deinen Branch angesehen.

Bei den Tests für das SIGNAlduino Modul habe ich noch eine alte Baustelle (Anzahl an dispatches) gefunden.

Ja da gibt es noch einige sicherlich und aus diesem Grund wollte @elektron-bbs zum Bsp. nicht Daten in den pre-release Branch schieben, da dort die Fehler nur als note ausgegeben werden. Im Master Branch werden diese als Fehler ausgegeben und man sieht dies sofort. Darauf muss man sofort handeln um den Fehler zu beseitigen und er wird sofort bearbeitet.

Weiterhin sind hier noch die Quellen der Testdaten zu hinterlegen. Mir schwebt ja vor, dass lokal liegende Daten automatisch gefunden werden und weitere remote Quellen eingebunden werden können.

Das kann man machen bzw. es ist eine gute Idee.

Frage: (am Bsp. SD_WS Modul) Wieso legst du Testdaten in die Datei https://github.com/RFD-FHEM/RFFHEM/blob/master_fix_tests_JSON/t/FHEM/14_SD_WS/testData.json obwohl diese Daten hier https://github.com/RFD-FHEM/SIGNALduino_TOOL/blob/master/FHEM/lib/SD_Device_ProtocolList.json#L7386:L7436 hinterlegt sind. Die Datei testData.json wäre somit überflüssig. Kommt es noch?

Umsetzung: Da eh schon eine Schleife läuft um im JSON das passende Modul zu filtern, könnte man diese erweitern. Sobald der Eintrag "tests" gefunden, dann läuft die nächste Schleife mit den Arrayeinträgen durch. Wenn darin Attributes gefunden wurde, dann setze Attribute usw.... Das ganze kannst du dann soweit erweitern, wenn dort ein "dmsg" Einträg gefunden wird (Bsp. um eine falsch Chk-Sum zu prüfen), dann nutze diesen ansonsten nutze den von der übergeordneten Struktur.

So ist doch alles beisammen und der Pflegeaufwand ist für alle Beteiligen einfacher bzw. Wartungsfreundlicher. ;-)

Vorschlag, wir können gern auch mal einen persönlichen Kontakt (Bsp. Telefon) herstellen um darüber zu reden.

elektron-bbs commented 1 year ago

Ich habe einige Anpassungen vorgenommen, jetzt haben wir die bisher vermissten Fehler: https://github.com/RFD-FHEM/RFFHEM/tree/master_fix_tests_JSON

Bei diesem Branch habe ich den Eindruck, das das Attribut "model" nicht gesetzt wurde:

    not ok 9 - Checking parseFN for module: SD_WS device: TX-EZ6 DataNr: 0 (fuer Wetterstation TZS First Austria) {
        # device will be defined temporary
        ok 1 - Verify device return from defmod 
        ok 2 - verify parseFn return equal internal NAME
        not ok 3 - Verify readings {
            1..9
            ok 1 - check reading temperature
            ok 2 - check reading channel
            not ok 3 - check reading sendmode
            ok 4 - check reading type
            ok 5 - check reading state
            ok 6 - check reading humidity
            not ok 7 - check reading temperatureTrend
            not ok 8 - check reading humidityTrend
            not ok 9 - check reading batteryState
        }
        ok 4 - Verify internals {
            1..2
            ok 1 - check internal DEF
            ok 2 - check internal NAME
        }
        1..4
    }

Die Readings

            not ok 7 - check reading temperatureTrend
            not ok 8 - check reading humidityTrend
            not ok 9 - check reading batteryState

gibt es nur, wenn das Attribut "model" auf "TX-EZ6" gesetzt wurde.

sidey79 commented 1 year ago

interlegt sind. Die Datei testData.json wäre somit überflüssig. Kommt es noch?

Die Datei wird nicht überflüssig, die braucht es doch je Modul das getestet wird um die Daten zu hinterlegen.

Um die Fehler muss ich mich noch kümmern, sind halt doch mehr Detailarbeiten als angenommen.

HomeAutoUser commented 1 year ago

Nur kurz, da ich unterwegs bin.

Die Datei wird nicht überflüssig, die braucht es doch je Modul das getestet wird um die Daten zu hinterlegen.

Die dortigen Daten sind auch im JSON (derzeit nur SD_WS). Das geht auch daher hervor.

Siehe Umsetzung https://github.com/RFD-FHEM/SIGNALduino_TOOL/issues/87#issuecomment-1352763119

sidey79 commented 1 year ago

Umsetzung: Da eh schon eine Schleife läuft um im JSON das passende Modul zu filtern, könnte man diese erweitern. Sobald der Eintrag "tests" gefunden, dann läuft die nächste Schleife mit den Arrayeinträgen durch. Wenn darin Attributes gefunden wurde, dann setze Attribute usw.... Das ganze kannst du dann soweit erweitern, wenn dort ein "dmsg" Einträg gefunden wird (Bsp. um eine falsch Chk-Sum zu prüfen), dann nutze diesen ansonsten nutze den von der übergeordneten Struktur.

Hmm, das dachte ich gestern Abend auch noch, dann habe ich es wieder verworfen, denn wenn Tests nicht vorhanden ist, dann hat die Schleife überhaupt keinen Durchlauf und der darin liegende code wird nicht aufgerufen. Somit keine Tests.

dmsg und rmsg würde ich in der Schleife auch nicht aufrufen, denn das bringt dann keinen Vorteil mehr gegenüber der aktuellen Umsetzung dass ein neuer Datensatz in data angelegt wird. Bei den erwarteten readings hingegen, würde es sich anbieten diese in jedem Test definieren zu können. Diese allerdings Zusätzlich im data Eintrag zu hinterlegen sehe ich als nicht vorteilhaft.

Folgende Beispiele habe ich gerade. Es wird die gleiche dmsg verwendet, allerdings durch das Setzen des Attributes kommt es zu unterschiedlichen Ergebnissen (readings):

        {
          "dmsg":"P109#083122FD29D5648A8E", "comment":"P109# Kanal 9 - status 100%", "user":"Hofyyy",
          "internals": { "NAME": "SD_Rojaflex_3122FD2_9", "DEF": "3122FD2_9" },
          "readings": { "motor": "stop", "state": "closed", "cpos": "100" },
          "minProtocolVersion":"1.39", "revision_entry":"2021-11-21 20:33:59Z",
          "revision_modul":"10_SD_Rojaflex.pm 100 2021-11-21 20:33:59Z elektron-bbs",
          "rmsg":"P109#083122FD29D5648A8E;R=196;",
          "tests": [
            {
              "comment": "P109# Kanal 9 - status 100%",
              "setreadings": { "motor": "stop", "cpos": "0", "tpos": "0"  }
            }
          ]
        },
        {
          "dmsg":"P109#083122FD29D5648A8E", "comment":"P109# Kanal 9 - status 100% (inversePosition)", "user":"Hofyyy",
          "internals": { "NAME": "SD_Rojaflex_3122FD2_9", "DEF": "3122FD2_9" },
          "readings": { "motor": "stop", "state": "closed", "cpos": "0" },
          "minProtocolVersion":"1.39", "revision_entry":"2021-11-21 20:33:59Z",
          "revision_modul":"10_SD_Rojaflex.pm 100 2021-11-21 20:33:59Z elektron-bbs",
          "rmsg":"P109#083122FD29D5648A8E;R=196;",
          "tests": [
            {
              "comment": "P109# Kanal 9 - status 100% (inversePosition)",
              "attributes": {"inversePosition": "1"},
              "setreadings": { "motor": "stop", "cpos": "100", "tpos": "0"  }
            }
          ]
        }

Eine Option wäre wie folgt:

        {
          "dmsg":"P109#083122FD29D5648A8E", "comment":"P109# Kanal 9 - status 100%", "user":"Hofyyy",
          "internals": { "NAME": "SD_Rojaflex_3122FD2_9", "DEF": "3122FD2_9" },
          "readings": { "motor": "stop", "state": "closed", "cpos": "100" },
          "minProtocolVersion":"1.39", "revision_entry":"2021-11-21 20:33:59Z",
          "revision_modul":"10_SD_Rojaflex.pm 100 2021-11-21 20:33:59Z elektron-bbs",
          "rmsg":"P109#083122FD29D5648A8E;R=196;",
          "tests": [
            {
              "comment": "P109# Kanal 9 - status 100%",
              "setreadings": { "motor": "stop", "cpos": "0", "tpos": "0"  }
            },
            {
              "comment": "P109# Kanal 9 - status 100% (inversePosition)",
              "attributes": {"inversePosition": "1"},
              "setreadings": { "motor": "stop", "cpos": "100", "tpos": "0"  },
              "readings": { "motor": "stop", "state": "closed", "cpos": "0" },   (2) Overwrite des erwarteten Ergebnisses
            },
          ],
        }
       ]
      }

Eine andere, klarerer wäre folgendes:

        {
          "dmsg":"P109#083122FD29D5648A8E", "comment":"P109# Kanal 9 - status 100%", "user":"Hofyyy",
          "minProtocolVersion":"1.39", "revision_entry":"2021-11-21 20:33:59Z",
          "revision_modul":"10_SD_Rojaflex.pm 100 2021-11-21 20:33:59Z elektron-bbs",
          "rmsg":"P109#083122FD29D5648A8E;R=196;",
          "tests": [
            {
              "comment": "P109# Kanal 9 - status 100%",
              "setreadings": { "motor": "stop", "cpos": "0", "tpos": "0"  }
              "readings": { "motor": "stop", "state": "closed", "cpos": "100" },
              "internals": { "NAME": "SD_Rojaflex_3122FD2_9", "DEF": "3122FD2_9" },
        },
            {
              "comment": "P109# Kanal 9 - status 100% (inversePosition)",
              "attributes": {"inversePosition": "1"},
              "setreadings": { "motor": "stop", "cpos": "100", "tpos": "0"  },
              "readings": { "motor": "stop", "state": "closed", "cpos": "0" },   
              "internals": { "NAME": "SD_Rojaflex_3122FD2_9", "DEF": "3122FD2_9" },
            },
          ],
        }
       ]
      }

Damit wäre es strukturell immer ein Teil unterhalb tests und immer wenn etwas getestet werden soll gibt es den Abschnitt tests

sidey79 commented 1 year ago

Um die Fehler muss ich mich noch kümmern, sind halt doch mehr Detailarbeiten als angenommen.

Vom Prinzip her bin ich mit den Anpassungen der Testmodule fertig. Dem autocreate Fehler der aktuell noch vorliegt bin ich noch nicht nachgegangen. Vermutlich habe ich ein Testdevice zu viel in der fhem.cfg.

Jetzt müssten noch die Testdaten migriert werden.

HomeAutoUser commented 1 year ago

Jetzt müssten noch die Testdaten migriert werden.

Meinst du damit die Überführung der Daten aus dem testData.json in das JSON vom TOOL?

sidey79 commented 1 year ago

Jetzt müssten noch die Testdaten migriert werden.

Meinst du damit die Überführung der Daten aus dem testData.json in das JSON vom TOOL?

Nein, genau in die andere Richtung, sonst sind ja die Daten wieder nicht mit dem Stand des Modules verknüpft.

HomeAutoUser commented 1 year ago

Nein, genau in die andere Richtung, sonst sind ja die Daten wieder nicht mit dem Stand des Modules verknüpft.

@sidey79 , bitte ein Beispiel benennen. Ich habe das Gefühl oder Verständnis gerade, das es den falschen Weg einschlug. Aus diesem Grund frage ich überall dazwischen smile

sidey79 commented 1 year ago

Das Hideki Modul liegt im RFFHEM Repo.

Also liegen zukünftig auch die Testdaten im gleichen Repo:

https://github.com/RFD-FHEM/RFFHEM/blob/master_fix_tests_JSON/t/FHEM/14_Hideki/testData.json

Wird was am Modul geändert, können die Testdaten direkt mit angepasst werden und es kommt zu keinen Konflikten mehr.

HomeAutoUser commented 1 year ago

Da andere Fragen, an anderer Stelle offen blieben, so noch einmal komplett ;-)

@sidey79 dann haben wir den Stand, das wir an 2 Stellen pflegen müssen.

1) Frage, da fangen wir wohl an, sämtliche DMSG aus dem JSON in den Test zu kopieren?

2) Benötigst du das JSON vom Tool überhaupt noch?

@elektron-bbs und ich dachten, du verstehst das Ansinnen, nur eine Stelle zu pflegen. Also wenn ein neues Modul mit dem SIGNALduino als funktionstüchtig deklariert wird, dmsg in JSON um auch die Nachricht jederzeit zu dispatchen ... zu revisionieren und fertig. Sollten dann Tests notwendig werden um deine CoverPAth-Abdeckung (oder wie dies heißt) zu erhöhen, so käme der Abschnitt

          "tests": [
            {
              "comment": "...",
              "setreadings": { ...  } ...
        },

zum tragen. Kurzum, @elektron-bbs und ich haben uns bisher nur am JSON vom Tool zuschaffen gemacht.

Wird was am Modul geändert, können die Testdaten direkt mit angepasst werden und es kommt zu keinen Konflikten mehr.

Der Fall wird auch abgedeckt, indem die Handlung von @elektron-bbs darin bestand, erst das JSON zu erweitern und dann den PR zu erstellen.

Ich persönlich finde es unsinnig, Daten aus dem JSON 1:1 in die testData.json zu kopieren wenn ich davon nicht alle Einträge benötige. Im Grunde machst du derzeit nichts anderes als das JSON mit dem tests-Abschnitt zu durchlaufen wenn es hinterlegt ist. Zusätzlich durchläufst du noch die testData.json um diese in den Testbestand zu pushen.

Sollte mal ein Fall hinzukommen das ungültige dsmg´s oder Ähnliches geprüft werden sollten, so käme im Abschnitt tests, ein neuer Key hinzu und deine Schleife in der RDmsg.pm würde ergänzt werden um die Handlung bei dmsg.

@elektron-bbs, welche Meinung vertrittst du um das Handling und die Pflegearbeit unnötig aufzublähen?

elektron-bbs commented 1 year ago

Nun ja, so ganz durchschaue ich die Aktion noch nicht: Werden nur zusätzliche Testdaten in die Verzeichnisse der Module gepackt und das JSON im Tool bleibt wie vorher schon für "normale" Tests? Dann würde sich ja für uns nichts ändern.

sidey79 commented 1 year ago

Puuh, das ist ja jetzt ein Durcheinander.

Ich hatte es so verstanden, dass das SIGNAlduino_Tool kein eigenen Daten im JSON braucht und wir diese Daten zu den zu testenden Modulen packen. Also verschieben.

Was ich nicht verstehe, wie die Verknüpfung zwischen Modul und Testdaten sonst hergestellt werden soll. Aktuell bestes Beispiel: Die RFFHEM Module sind von den Testdaten im SIGNALduino_Tool abhängig. Das Schema würde im Tool verändert, die Tests im RFFHEM Repo sind noch auf das alte Format ausgelegt. Beim Umstellen auf das neue Schema sind weitere Anpassungen identifiziert worden, welche wiederum nicht im Schema vom Tool abgebildet werden.

HomeAutoUser commented 1 year ago

Puuh, das ist ja jetzt ein Durcheinander.

;-) Sowas entsteht wenn viele Fragen offen sind und man ein Vorhaben nur bedingt erahnen kann.

Was ich nicht verstehe, wie die Verknüpfung zwischen Modul und Testdaten sonst hergestellt werden soll.

Das geht nur auf deine Weise.

Wenn du es so für am vernünftigsten hällst, so akzeptiere ich es und nun sehe ich durch. Diese Daten https://github.com/RFD-FHEM/SIGNALduino_TOOL/blob/master/FHEM/lib/SD_Device_ProtocolList.json#L7389:L7433 würde ich dann entfernen wieder weil diese ja nicht an der Stelle benötigt werden. richtig?

Zusätzliche Frage noch, möchtest du dennoch die Unterscheidung master und pre-release beibehalten?

sidey79 commented 1 year ago

Puuh, das ist ja jetzt ein Durcheinander.

;-) Sowas entsteht wenn viele Fragen offen sind und man ein Vorhaben nur bedingt erahnen kann.

Tia, was soll ich sagen. Klassisch aneinander vorbei geschrieben ;)

Wenn du es so für am vernünftigsten hällst, so akzeptiere ich es und nun sehe ich durch. Diese Daten https://github.com/RFD-FHEM/SIGNALduino_TOOL/blob/master/FHEM/lib/SD_Device_ProtocolList.json#L7389:L7433 würde ich dann entfernen wieder weil diese ja nicht an der Stelle benötigt werden. richtig?

Ja, die können dann entfernt werden.

Zusätzliche Frage noch, möchtest du dennoch die Unterscheidung master und pre-release beibehalten?

pre-release ist nicht notwendig, da diese ja ausschließlich zum fehlerfreien Testen verwendet wurden.

elektron-bbs commented 1 year ago

Dann hake ich aber auch gleich nochmal nach: Wir erstellen die Testdaten weiterhin mit dem SIGNALduino_TOOL, packen die Änderungen in die Datei SD_Device_ProtocolList.json im Branch "master" und du sortierst das dann ein, wo du es gerade brauchst?

sidey79 commented 1 year ago

Naja die Testdaten müssen dann in das Repository in dem das Modul liegt was geändert wird und sollten im gleichen PR mit bereitgestellt werden.

Was passiert denn mit den Testdaten die in SD_Device_ProtocolList.json liegen noch, wenn kein Test diese mehr verwendet?

RFD-FHEM / SIGNALduino_TOOL

JSON schreiben Fehler #87

Vorschlag: