Seit Anpassung der WH3080 Daten kommt es zu einem Fehler

[sidey79]

Im commit 7d02962 wurden die Daten für die WH3080 angepasst:

SIGNALduino_TOOL/FHEM/lib/SD_Device_ProtocolList.json

Lines 177 to 184 in 6e6aa4b

	{"name":"WH3080", "id":"9", "data": [
	{
	"dmsg":"P9#FF7C845508D87403", "comment":"reconstructed bit 1", "user":"Ralf9",
	"internals": {"DEF":"WH1080", "NAME":"WH1080"},
	"readings": {"state":"UV: 4 Lux: 57970 ", "Lux":"57970", "UV":"4", "id":"200"},
	"rmsg":"MU;P0=-1424;P1=1417;P2=-1058;P3=453;P4=-24774;P6=288;P7=-788;D=01212121232343232323232323232123232323232121232121212123212121232123212321232121212123212121232321232321212121232323212321212121212121212323467323232323232323212323232323212123212121212321212123212321232123212121212321212123232123232121212123232321232121;CP=3;R=247;O;"
	}
	]

Diese Daten werden für den automatischen Test nun auch verwendet, da der Wert internals gesetzt ist.

Getestet wurde gegen den Modulstand commit 7c6e785456a1c105a7720e5f0b89c8d0566c8da1.

package lib::SD_ProtocolData;
	our $VERSION = '1.05';

Anbei das Log:

2019.07.02 21:26:42 5: Starting notify loop for dummyDuino, 1 event(s), first is dummyDuino 4: dummyDuino/msg get raw: \002MU;P0=-1424;P1=1417;P2=-1058;P3=453;P4=-24774;P6=288;P7=-788;D=01212121232343232323232323232123232323232121232121212123212121232123212321232121212123212121232321232321212121232323212321212121212121212323467323232323232323212323232323212123212121212321212123212321232123212121212321212123232123232121212123232321232121;CP=3;R=247;O;\003
2019.07.02 21:26:42 5: End notify loop for dummyDuino
2019.07.02 21:26:42 4: dummyDuino/msg get raw: �MU;P0=-1424;P1=1417;P2=-1058;P3=453;P4=-24774;P6=288;P7=-788;D=01212121232343232323232323232123232323232121232121212123212121232123212321232121212123212121232321232321212121232323212321212121212121212323467323232323232323212323232323212123212121212321212123212321232123212121212321212123232123232121212123232321232121;CP=3;R=247;O;�
2019.07.02 21:26:42 5: Starting notify loop for dummyDuino, 1 event(s), first is dummyDuino 4: dummyDuino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2019.07.02 21:26:42 5: End notify loop for dummyDuino
2019.07.02 21:26:42 4: dummyDuino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2019.07.02 21:26:42 5: Starting notify loop for dummyDuino, 1 event(s), first is dummyDuino 5: dummyDuino: 0. try, regex ((?:)((?:32|32){43,})) did not match
2019.07.02 21:26:42 5: End notify loop for dummyDuino
2019.07.02 21:26:42 5: dummyDuino: 0. try, regex ((?:)((?:32|32){43,})) did not match
2019.07.02 21:26:42 5: Starting notify loop for dummyDuino, 1 event(s), first is dummyDuino 4: dummyDuino: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2019.07.02 21:26:42 5: End notify loop for dummyDuino
2019.07.02 21:26:42 4: dummyDuino: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2019.07.02 21:26:42 5: Starting notify loop for dummyDuino, 1 event(s), first is dummyDuino 5: part is 323232323232323212323232323212123212121212321212123212321232123212121212321212123232123232121212123232321232121212121212121232 starts at position 13 and ends at 139
2019.07.02 21:26:42 5: End notify loop for dummyDuino
2019.07.02 21:26:42 5: part is 323232323232323212323232323212123212121212321212123212321232123212121212321212123232123232121212123232321232121212121212121232 starts at position 13 and ends at 139
2019.07.02 21:26:42 5: Starting notify loop for dummyDuino, 1 event(s), first is dummyDuino 5: dummyDuino: Starting demodulation ( regex: (?:)((?:32|12){60,}) Pos 0) length_min_max (60..120) length=63
2019.07.02 21:26:42 5: End notify loop for dummyDuino
2019.07.02 21:26:42 5: dummyDuino: Starting demodulation ( regex: (?:)((?:32|12){60,}) Pos 0) length_min_max (60..120) length=63
2019.07.02 21:26:42 5: Starting notify loop for dummyDuino, 1 event(s), first is dummyDuino 5: dummyDuino: dispatching hex: P9#FF7C845508D87402
2019.07.02 21:26:42 5: End notify loop for dummyDuino
2019.07.02 21:26:42 5: dummyDuino: dispatching hex: P9#FF7C845508D87402

[sidey79]

@HomeAutoUser

Ich weiss nicht, ob Du eine Benachrichtigung bekommst wenn ich das issue aufmache, daher schreibe ich dich sicherheitshalber direkt an

[HomeAutoUser]

@sidey79

Ich hab’s gerade gelesen.
Was möchtest du mir damit sagen bzw ich sehe hier mit dem MobilPhone noch nicht durch beim den Logausgaben.

Die Daten des Internals hatte ich bestimmt mit dem reconstruct Bit erzeugt. Das würde erklären wieso es bei dir nicht klappt. Oder verstehe ich den Sachverhalt falsch?

[sidey79]

@HomeAutoUser

In #8 hatten wir festgelegt, dass die Angaben "rmsg" und "dmsg" validiert sind, wenn internals mit angegeben sind.

Der Test läuft unter dem angegebenen commit. Die Protokolldaten sind aktuell (version 1.05) und deutlich neuer als die Testdaten. Dennoch kommt es hier zu einer Abweichung.

Ich kann mir nicht vorstellen, mit welcher Version der Protokolldaten die Validierung vorgenommen wurde, aber das Soll Ergebnis des Tests weicht definitiv vom Ist Stand ab, wenn mit 1.05 der Test durchlaufen wird.
Sieht für mich so aus, als ob bei der Validierung etwas "schief" gelaufen ist und der angegeben Wert in dmsg mit keiner Protokolldatenversion erreicht werden kann, die bislang in dev-r34 eingeflossen ist.

[HomeAutoUser]

Moin Moin, ich schaue es mir an.
Ich denke @sidey79 das ich einen Schritt voraus war und sollte es so gewesen sein, dann "cleare" ich es auf die "Protokolldaten (version 1.05)" zurecht damit dein Test die richtigen Ergebnisse liefert.

Ich bin eben dran, "schnellstmöglich" jede RAWMSG / DMSG welche bei "uns" nicht klappt, als Fehler behandeln zu wollen um einen Stand anzustreben, das erstmal alle Daten darin ohne Fehler durchlaufen.
Diesen Stand würde ich als Master in SIGNALduino_TOOL dann mergen.

[sidey79]

Mach dir keine Vorwürfe,

Wir sind Menschen und es passieren Fehler.
Ich wollte einfach nur darauf hinweisen, da dies aktuell der einzigste Test ist, der noch Fehler Produziert.

Wenn das Ergebnis für dieses Gerät angepasst wurde, dann laufen die Tests rmsg / dmsg alle mit einem OK durch.

Wie wir das grundsätzlich in Zukunft handhaben weiss ich leider auch noch nicht.

Die Schwierigkeit besteht ja darin, dass sich der Stand der Testdaten ändern kann, ohne dass ein Test automatisch durchgeführt wird.
Die Lösung habe ich noch nicht.

Vielleicht hilft es, wenn wir mit Tags arbeiten.
Dann wäre es zumindest eine bewusste Entscheidung die Testbedingungen zu verändern.

[HomeAutoUser]

Alles gut :)

Wir sind Menschen und es passieren Fehler.
Ich wollte einfach nur darauf hinweisen, da dies aktuell der einzigste Test ist, der noch Fehler Produziert.

Du meinst sicherlich, Fehler wenn die RAWMSG nicht das Ergebnis vom Internal produziert? Liege ich da richtig?

[sidey79]

Wo Fehler passieren ist doch egal.
Das kann überall passieren.

In dem konkreten Fall stimmt dmsg nicht.
Das Vorhandensein des Internals ist nur ein Trigger, dass der Testfall rmsg zu dmsg prüfen durchgeführt wird.

Die Werte in internal werden derzeit in keinem Test automatisch verifiziert.
Das ist für mich ein To-Do für die Zukunft. Ebenso das festlegen ob wir repeats oder Anzahl Dispatches angeben.

[HomeAutoUser]

Wenn ich das richtig verstehe, prüfst du DMSG zur RAWMSG?

Meine Überlegung auf die Schnelle war soeben, ob man an einer „Kennung“ herausbekommt, hier ist noch Handlungsbedarf.

Der Gedanke dahinter ist, das ich ja eine Parallele Aufzeichnung habe wo Fehler / Differenzen vorhanden sind.

[sidey79]

Was soll anhand einer Kennung herauszubekommen sein?

Ich hatte verstanden, dass wir die Felder internal nur pflegen, wenn dieser Zustand auch mit dem SIGNALduino Modul im master oder development Branch erzeugt werden kann.
Solange internal nicht gesetzt ist, findet auch kein Test statt.

Wenn internal Werte gesetzt sind gehe ich davon aus, dass sie mit dem Modul aus dev-r34 (derzeit) erreicht werden können.

Wir können auch gerne ein anderes Flag dafür einbauen.

[sidey79]

@HomeAutoUser

Wie sollen wir den Fehler beheben?

Option 1: Internal entfernen
Option 2: dmsg anpassen?

[sidey79]

@HomeAutoUser

Ich habe Option 1 umgesetzt: 37cc1be

Ist eher ein Workaround aber mit einer fehlerhaften Angabe macht es wenig Sinn dagegen zu testen.

[HomeAutoUser]

Hallo, bin gerade meist nur mobil zwecks Urlaub und sportlichen Höhepunkt.

Wie sollen wir den Fehler beheben?
Option 1: Internal entfernen
Option 2: dmsg anpassen?

Ich hätte auch Option 1 gewählt ;) und zusätzlich passe ich die Kommentare an um zu sehen, hier ist noch Handlungsbedarf aber deine Tests laufen erstmal durch.

[HomeAutoUser]

@sidey79
etwas unpassend zum Thema aber dennoch die Frage an dich zum Verständnis.

Was passiert wenn ich in die JSON Datei Daten eingebe als Ergebnis wenn ich das model manuell richtig gesetzt habe im Modul SD_UT Bsp.

Bisherigen Daten:
(das model wurde nocht nicht gesetzt, da es der Zustand nach dem Empfang ist, bevor der User selbst definieren muss)

{"name":"Roto TX-nM-HCS", "id":"88", "data": [
    {
      "dmsg":"P88#9451E57890EAFEF24", "comment":"encoded", "user":"bruen985",
      "internals": {"DEF":"F7F5709", "NAME":"SD_Keeloq_F7F5709"},
      "readings": {"state":"Please change your model via attribut!", "button":"0100", "serial_receive":"F7F5709", "user_info":"Please input KeeLoq_NLF, MasterMSB and MasterLSB Key!", "user_modus":"only_limited"},
      "rmsg":"MS;P0=-16052;P1=363;P2=-437;P3=-4001;P4=-829;P5=755;D=131452521452145252521452145252521414141452521452145214141414525252145252145252525214141452145214521414141414141452141414145252145252101212121212121212121212;CP=1;SP=3;R=51;O;m1;"
    }
  ]
},
{"name":"Waeco MA650-TX", "id":"88", "data": [
    {
      "dmsg":"P88#55D6D6EFCD9422044", "comment":"encoded", "user":"elektron-bbs",
      "internals": {"DEF":"04429B3", "NAME":"SD_Keeloq_04429B3"},
      "readings": {"state":"Please change your model via attribut!", "button":"0010", "serial_receive":"04429B3", "user_info":"Please input KeeLoq_NLF, MasterMSB and MasterLSB Key!", "user_modus":"only_limited"},
      "rmsg":"MS;P1=-425;P2=348;P3=-3925;P4=748;P5=-816;P6=-15724;D=234125412541254125252541254125254125254125412525412525254125252525252541412525412525414125412541414141254141412541414141414125414141262121212121212121212121;CP=2;SP=3;R=12;O;m1;"
    }
  ]
},

Korrekte Daten, nach dem definieren des Models vom User manuell um die Auswertung richtig zu erhalten:

{"name":"Roto TX-nM-HCS", "id":"88", "data": [
    {
      "dmsg":"P88#9451E57890EAFEF24", "comment":"encoded, button up", "user":"bruen985",
      "internals": {"DEF":"F7F5709", "NAME":"SD_Keeloq_F7F5709"},
      "readings": {"state":"receive", "batteryState":"ok", "button":"up", "repeat_message":"yes", "serial_receive":"F7F5709", "user_info":"Please input KeeLoq_NLF, MasterMSB and MasterLSB Key!", "user_modus":"only_limited"},
      "rmsg":"MS;P0=-16052;P1=363;P2=-437;P3=-4001;P4=-829;P5=755;D=131452521452145252521452145252521414141452521452145214141414525252145252145252525214141452145214521414141414141452141414145252145252101212121212121212121212;CP=1;SP=3;R=51;O;m1;"
    }
  ]
},
{"name":"Waeco MA650-TX", "id":"88", "data": [
    {
      "dmsg":"P88#55D6D6EFCD9422044", "comment":"encoded, button blue", "user":"elektron-bbs",
      "internals": {"DEF":"04429B3", "NAME":"SD_Keeloq_04429B3"},
      "readings": {"state":"receive", "batteryState":"ok", "button":"blue", "repeat_message":"yes", "serial_receive":"04429B3", "user_info":"Please input KeeLoq_NLF, MasterMSB and MasterLSB Key!", "user_modus":"only_limited"},
      "rmsg":"MS;P1=-425;P2=348;P3=-3925;P4=748;P5=-816;P6=-15724;D=234125412541254125252541254125254125254125412525412525254125252525252541412525412525414125412541414141254141412541414141414125414141262121212121212121212121;CP=2;SP=3;R=12;O;m1;"
    }
  ]
},

BEEINFLUSST das deine Tests, das diese fehl schlagen oder prüfst du nur die

• "internals": {"DEF":"F7F5709", "NAME":"SD_Keeloq_F7F5709"},
• "dmsg":"P88#55D6D6EFCD9422044",
  ob diese mit der
• "rmsg":"MS;P1=-425;P2=348;P3=-3925;P4=748;P5=-816;P6=-15724;D=234125412541254125252541254125254125254125412525412525254125252525252541412525412525414125412541414141254141412541414141414125414141262121212121212121212121;CP=2;SP=3;R=12;O;m1;"

gleich bleiben?

Nicht das ich mit unserer Genauigkeit deine Test´s erstmal fehl schlagen lassen ;-)

[sidey79]

@HomeAutoUser
Danke dieser Nachfrage.

Im Moment läuft nur ein Basistest der das Ergebnis von DMSG verifiziert.
Selbst die Wiederholungen lassen sich derzeit nicht testen.
Somit kannst Du mit Änderungen an den readings oder den interals noch nichts kaputt machen.

Die Auswertung der Daten zu testen, würde die Qualität der Module allerdings noch verbessern und das sollten wir auch angehen.
So wie ich den Fall jetzt verstehe, würde diese Änderung dazu führen, dass die Sollwerte nicht anhand der Testdaten erreicht werden, da eine Änderung der angelegten Definition notwendig wäre.

Wäre folgendes Vorstellbar?

Der Testdatensatz wie er bislang vorliegt bleibt erhalten.
Es wird ein 2. Testdatensatz angelegt, der auf Basis des gesetztes Modelles die Sollwerte darstellt.
Zusätzlich wird der notwendige Perlcode in einer Bezeichnung hinterlegt die vor dem Test ausgeführt wird.

Ich hab jetzt noch keinen exakten Plan, woher man weiss, wann man das ganze aufrufen soll, aber vielleicht findet sich da ja noch was.

[HomeAutoUser]

Im Moment läuft nur ein Basistest der das Ergebnis von DMSG verifiziert.
Selbst die Wiederholungen lassen sich derzeit nicht testen.
Somit kannst Du mit Änderungen an den readings oder den interals noch nichts kaputt machen.

Da bin ich ja beruhigt ;-) und weis den Stand wie es derzeit abläuft.

So wie ich den Fall jetzt verstehe, würde diese Änderung dazu führen, dass die Sollwerte nicht anhand der Testdaten erreicht werden, da eine Änderung der angelegten Definition notwendig wäre.

Das ist richtig. Betreffs dem SD_UT Modul, so wird beim ersten anlegen wie folgt belegt ist
DEF | unknown

Erst nach einem manuellen auswählen des Modelles und erneutem Empfang wäre es dann so belegte
DEF | Buttons_five E

Alles ist von der selben DMSG bzw. selben RAWMSG. Der User muss nur bei 80% der Modelle selbst auswählen. Bei den anderen 20% wird das Modell direkt angelegt mit dem dazugehörigen DEF. Da würde es ja nicht stören. (eine automatische Modellzuordnung ist nur da vorgesehen wo auch eine Prüfung integriert ist in Form von einer CRC)

Wäre folgendes Vorstellbar?
Der Testdatensatz wie er bislang vorliegt bleibt erhalten.
Es wird ein 2. Testdatensatz angelegt, der auf Basis des gesetztes Modelles die Sollwerte darstellt.
Zusätzlich wird der notwendige Perlcode in einer Bezeichnung hinterlegt die vor dem Test ausgeführt wird.

Ich könnte mir nur das so vorstrellen, das im Comment Feld Bsp "model:Trabi" drin steht. Sowas in der Art?

Was meinst du mit PerlCode in einer Bezeichnung?

Prinzipiell wenn wir es "doppelt" eintragen geht es. Die "Mehrarbeit" führt dazu, das wir alle Fälle abdecken.

1. RAWMSG ohne modelauswahl automatisch
2. RAWMSG mit manuellen gesetzen model