Update SD_Device_ProtocolList.json

[sidey79]

• removed rmsg, because as comment, rmsg does not match to get dmsg

• fix number of dispatch repeats for X 70372

[HomeAutoUser]

Hier ist es bestimmt angebracht die entfernte rmsg im comment erstmal zu verankern, oder?

[sidey79]

Hier ist es bestimmt angebracht die entfernte rmsg im comment erstmal zu verankern, oder?

Ich habe die rmsg gelöscht, da die schon sehr lange in dem json file steckt und uns der Kommentar, dass die rmsg nicht zu dieser dmsg führt nicht interessiert hat Die passt einfach nicht zu dem Datensatz. Warum auch immer.

Wer es unbedingt such, könnte es ja über git blame finden oder in prelease da ist es auch noch enthalten.

Wenn Du eine sinnvolle Verwendung für diese korrupte rmsg findest dann her damit :)

[sidey79]

@HomeAutoUser Muss jetzt noch was angepasst werden oder sollen wir mergen?

[HomeAutoUser]

@sidey79

die Anzahl der repeats habe ich korrigiert bzw auf dem Schirm. (Bisher nur auf dem Lokalen Pc korrigiert)

Was die rmsg angeht, so würde ich vorschlagen dem comment zu ändern in no decode (MC;LL=-1018;LH=914;SL=-539;SH=436;D=A8E4F45AEDF40AF97595766;C=484;L=91;R=7;) somit kannst du sie heraus nehmen aber sie bleibt erhalten um auf den Grund zu gehen, wieso sie bei unsere FW nicht funktioniert aber bei anderer Forks.

Wenn du nur noch die rmsg in den comment verlagerst, so können wir diesen Patch durchwinken.

[sidey79]

Dass die rmsg nicht zur besagten DMSG konvertiert werden kann liegt nicht an der Firmware, das liegt an der Verarbeitung im Modul und der Protokoll Definition.

Wenn wir das ergründen wollen, wäre dann ein issue nicht angebrachter als nur ein Kommentar?

[HomeAutoUser]

Das ist eine Nachricht welche „gesammelt oder übernommen“ wurde. Da sie aus der Zeit stammt, wo viel eintrudelte ... so bin ich erstmal schneller diese dort zu ergänzen mit der Hardware, weil dort geht es nicht unter ;) Da hat man es vor Augen als das ein Issues vielleicht auf Seiten nach hinten verschoben wird oder nach xZeit einer nicht Lösung geschlossen wird.

Kurzgesagt, so habe ich schnelleren Zugriff drauf, deswegen auch die rmsg darin zum Testen.

Idee: kannst du deinen Test nicht so schreiben, das überall wo eine rmsg existiert ABER im comment steht „no decode“ das dies übersprungen wird?

[sidey79]

Das ist eine Nachricht welche „gesammelt oder übernommen“ wurde. Da sie aus der Zeit stammt, wo viel eintrudelte ... so bin ich erstmal schneller diese dort zu ergänzen mit der Hardware, weil dort geht es nicht unter ;) Da hat man es vor Augen als das ein Issues vielleicht auf Seiten nach hinten verschoben wird oder nach xZeit einer nicht Lösung geschlossen wird.

Kurzgesagt, so habe ich schnelleren Zugriff drauf, deswegen auch die rmsg darin zum Testen.

Idee: kannst du deinen Test nicht so schreiben, das überall wo eine rmsg existiert ABER im comment steht „no decode“ das dies übersprungen wird?

Könnte ich, aber auf Kommentar gibt es keine feste Syntax, weil es ein Kommentar ist.

Ich scheine die Sache auch irgendwie anders zu sehen.

Die besagte RMSG führt nicht zur besagten DMSG. Mag ja durchaus sein, dass es mal so war. Irgendwas wurde geändert und es ist nicht mehr so. Das ist auch kein Fehler im SIGNALDuino_Tool das ist ein Verhalten aus Signalduino oder SD_ProtocolData.pm.

Ich pack es ins Kommentar, werde mich mit ziemlicher Wahrscheinlichkeit vergessen, dass im Kommentar ein Fehler dokumentiert ist. :(

[HomeAutoUser]

@sidey79 danke. Wenn wir zeitnah dran bleiben das Verhalten zu analysieren um den Fehler zu finden / beheben kommt, wird der comment mit der fehlerhaften rmgs bald gesäubert :)

Der Fall, das keine rmsg Vorhaben ist, kann ich auch somit bei der Umsetzung im Tool noch einmal testen das keine Fehler auftreten in der Bedienung.

[sidey79]

Ich hab den Bug als Bug erfasst:

https://github.com/RFD-FHEM/RFFHEM/issues/944