exprected dmsg is wrong about signalduino_tool HOT 10 CLOSED

@HomeAutoUser

Mir ist noch nicht klar, wie wir das mit den Tests machen wollen. Also welche Version der JSON Liste passt zu welchem Stand von einem Modul.
Davon gibt es grob drei:
Master, development und einzelne Features.

from signalduino_tool.

@sidey79

es gibt hierfür nun wieder 2 simple Erklärungen.

1. entweder es ist beim erstellen ein Copy&Paste Fehler
2. beim Ersteller wurde es unter einer anderen ID Decodiert

Richtig für deine Version wäre "P91.1#80306644B".

Gegenfrage, wie möchtest du das Unterscheiden wenn wie schon im anderen Post, genannte Funktionsweisen & Decodierungen ggf. nicht gleich laufen?

Also welche Version der JSON Liste passt zu welchem Stand von einem Modul.

Das wirst du nicht untescheiden können. Man müsste diesbezüglich das Modul auslesen und die Version dokumentieren.

from signalduino_tool.

@sidey79

Richtig für deine Version wäre "P91.1#80306644B".

Gegenfrage, wie möchtest du das Unterscheiden wenn wie schon im anderen Post, genannte Funktionsweisen & Decodierungen ggf. nicht gleich laufen?

Ich habe selbst leider noch keine Idee, wie wir das unterscheidbar machen könnten. Wir müssten einen Pflegeprozess für die Daten verankern.

Also welche Version der JSON Liste passt zu welchem Stand von einem Modul.

Das wirst du nicht untescheiden können. Man müsste diesbezüglich das Modul auslesen und die Version dokumentieren.

Das stellt mich vor ein größeres Problem.
Ich habe einen test (der läuft automatisch) aufgesetzt, welcher alle RMSG absendet und mit dem erwarteten Ergebnis DMSG vergleicht.

Von welchem System die RMSG stammt, können wir zunächst mal kurz ausblenden. Spannender sind die DMSG Einträge, da gegen die getestet wird.

1. Aktuell ist es so, dass Werte aus DMSG veraltet sind, da z.B. die preamble verändert wurde.

2. Dann haben wir im json File Daten, dazu gibt es in dev-r34 die Protokolle nicht. Das kann so also nicht klappen.

3. Gibt es eventuell auch Fehler im Modul, die dazu führen dass der DMSG Wert nicht mehr stimmt.

Ich stelle mal folgende szenario auf:

Bei jedem PR gegen das RFDFHEM Repo wird ein Test aller RMSG angestoßen. Aktuell wird die Datei aus dem SD_TOOL Repo heruntergeladen.
Wird nun etwas in die JSON Datei eingetragen, was vom SIGNALduino Modul nicht verarbeitet werden kann, kommt es zu einem Fehler. Die Lösung könnte hierbei sein, alle Daten aus der JSON zu ignorieren, zu denen es keine ID in der Protokollversion gibt. Fall 2 wäre damit im großen und ganzen abgedeckt.

Schauen wir uns nun aber Fall #1 an. Nehmen wir an, im master Branch hatten wir ein Protokoll 99 als u99 angelegt und wir hatten damals auch Testdaten erfasst.
Jetzt ändern wir das Protokoll 99 auf p99. Im Master branch schlagen die Tests ab sofort fehl, da diese Version noch auf u99 dispatcht in der JSON Datei wäre das erwartete Ergebnis nun aber p99.
Vermutlich haben wir zur gleichen zeit auch dev-r34 (was ebenfalls noch auf u99) dispatcht und einen neuen Branch z.B. dev-r34_p99 und hier passt es.

Ziemlich verzwickte Situation finde ich, da in jedem Branch ein anderes Ergebnis das richtige sein könnte, alle aber auf die identische Quelle verweisen.

from signalduino_tool.

Sauberer wäre es im Protokollhash bei der ID 91.1 die preamble auf P91# zu ändern.
Mir ist nicht klar welche Vorteile es haben soll, wenn bei gleichem Sensor bei der preamble zwischen 91 und 91.1 unterschieden wird. Im SD_UT Modul wird dieser Unterschied nicht ausgewertet, im Modul wird es dadurch nur aufwändiger.
Z.B. bei der ID 33 gibt es auch keine unterschiedlichen preamble.
Dies ist momentan nicht einheitlich gelöst

from signalduino_tool.

Alternativ können wir es natürlich auch in der JSON Liste in "P91.1#80306644B" ändern.

Damit dann bei mir die erwartete dmsg weiterhin passt muss ich nur mit einer regex das .1 entfernen.
$dmsg =~ s/\.1#/#/;

from signalduino_tool.

Ich denke mal, die 91.1 war damals nur wegen zu genauer Änderung entstanden.

Da wir bei dem Protokoll nicht senden und die Auswertung ja innerhalb auf P91 geschrieben ist, wäre ich für Änderung auf Preamble P91 in der ProtDef.

from signalduino_tool.

Meinetwegen kann es auf P91 geändert werden. :)

from signalduino_tool.

Den Fehler mit der 91 haben wir nun behoben. Ich stelle mir aber noch die Frage wie wir Version der Testdaten und vom Modul zusammenbringen.

from signalduino_tool.

Kann das vielleicht ein Ansatz / Idee sein?
Diese Infos kannst du gern als ein bzw. 2 Addeds auch in die JSON Speichern.

1. Version auslesen SIGNALduino

2. über den clientmodulname die 2 Zeile von dem modul auslesen worin die ID verankert ist mit Version.
   # $Id: 14_Hideki.pm 14395 2017-12-03 21:00:00Z v3.3.3-dev $

from signalduino_tool.

Handelt es sich hierbei dann um die mindest Version, die max Version oder die exakte Version?
Ziemlich kompliziert das ganze,

Vielleicht sollten wir die JSON Datei die zum automatisierten Testen verwendet wird in das RFFHEM Repo legen. Bei jeder Änderung wäre die dann dort zu aktualisieren / beachten.

Erstellst Du die aktuell manuell oder automatisiert?

from signalduino_tool.