Diskussionen / Neuerungen / Hinweise

[HomeAutoUser]

Für das o.g. habe ich das Thema erstellt.

Neuerung welche ins Pre-Release kommt demnächst. Die JSON möchte ich ergänzen mit „revision_modul“ und „revision_entry“.

revision_modul: speichert den Modulstand (Version) vom verarbeitenden Modul revision_entry: speichert das Datum / Zeit wo der Eintrag geupdatet/erstellt wurde

Die Eintragungen bringen uns bei einer Bewertung oder Fehlersuche weiter. So wird die Sprungmarke ersichtlich wo es funktionierte.

@sidey79 @elektron-bbs spricht da von Euch was dagegen? Die Erläuterung erfolgt kurz und knapp weil vom Handy schreibe.

[sidey79]

Grundsätzlich spricht nichts dagegen. Toll wäre, wenn wir es programmatisch gegen die Version eines Moduls auswerten könnten.

[HomeAutoUser]

Toll wäre, wenn wir es programmatisch gegen die Version eines Moduls auswerten könnten.

Wie stellst du dir das vor @sidey79

Es wäre auf jedenfall falsch, wenn durch ein Fremdmodulfehler deine Tests fehl schlagen. Das würde nur Sinn machen bei eigenen Modulen.

[sidey79]

@HomeAutoUser Irgendwie so:

if $version_from_module >= $version_from_json {

Hab es nicht näher durchdacht :)

[elektron-bbs]

@sidey79

Was soll dann passieren, wenn die Bedingung (nicht) zutrifft?

[sidey79]

@elektron-bbs Ich würde in diesem Fall den Test auf den Datensatz überspringen.

[elektron-bbs]

Dann werden im Laufe der Zeit sicher die meisten Tests übersprungen :-)

[HomeAutoUser]

Das einfache überspringen ist denke ich nicht Sinnvoll auf die Dauer.

Solltest du dies so anstreben, so macht es nur Sinn, das übersprungene Tests registriert werden mit einem Hinweis. Daraus resultiert, wer oder was geht dem übersprungenem Ergebnis nach? Da würde man sich zusätzliche Arbeit verschaffen.

Die Grundsatzfrage ist, wie weit geht man oder lehnt sich aus dem Fenster. Die Registrierung der Modulrevision und das Datum vom „Check / added / updated Eintrag“ verhilft uns um eine Bewertung und bessere Einsortierung der Timeline bei Fehlern. Die grundsätzliche Aufgabe liegt ja beim Maintainer es nicht zu verschlimmbessern :)

Natürlich kannst du bei freier Zeit und Wille dir die Arbeit verschaffen um fremdes zu prüfen aber dazu gehört dann auch die Pflege der Daten / Weitergabe bzw. Bekanntgabe der Eventuell auftretenden Daten.

Da fällt mir ein, was wertet man als Fehler? Da kann ggf auch nur eine Umbenennung einen Fehler verursachen was aber kein „richtiger Fehler ist“.

[sidey79]

@HomeAutoUser Vielleicht reden wir hier aneinander vorbei?

Du wolltest "revision_modul“ und „revision_entry" hinterlegen.

Ich versuche mein Verständnis darzustellen:

"revision_modul“ = Versionsnummer des logischen Modules, welches die Daten verarbeitet. Beim Verifizieren eines Datensatzes können Datensätze die für eine neuere als die installierte Modulversion gedacht sind nicht funktionieren und werden daher übersprungen.
Welche Module werden getestet? Nur die, für die ein solcher Test auch hinterlegt ist. Das kann je Modul entschieden werden.

Um das einfach mal grafisch zu Zeigen: Für 14_SD_AS ist kein Test hinterlegt, der die Daten aus dem JSON prüft. Für 14_SD_BELL ist ein Test hinterlegt, der die Daten aus dem JSON prüft. Quasi ein einfacher ein / aus Schalter :)

"revision_entry“ = Das ist programmatisch vermutlich nicht auszuwerten.

Wünschen würde ich dann aber noch eine 3. Information.

"minProtocolVersion" = Die Versionsnummer von SD_ProtocolData ab dem die RMSG ausgewertet werden kann.

[HomeAutoUser]

@sidey79 ich denke dich verstanden zu haben.

"revision_entry“ = Das ist programmatisch vermutlich nicht auszuwerten.

Soll eher als Zusatzinformation dienen um zu sehen von wann dies stammt bzw. um bei update des Eintrages (weil vielleicht das Modul sich änderte) den Moment festzuhalten.

"minProtocolVersion" = Die Versionsnummer von SD_ProtocolData ab dem die RMSG ausgewertet werden kann.

Deine Überlegung verstehe ich. Da würde mir als Umsetzung einfallen, das man nur bei „Ersteinträgen“ der Wert geschrieben wird. Alle Werte welche jetzt drin sind erhalten „unknown“. Da könnte man mit Fleiß in den Commits wühlen wann es dazu kam und manuell ergänzen.

[sidey79]

Die Arbeit, bei allen herauszufinden mit welcher Version das Protokoll aufgenommen wurde, würde ich auch niemandem zumuten.

Anstelle von unknown würde ich eher die aktuelle hinterlegen. Maximal vielleicht von der im SVN hinterlegten, aber seit dem sind es einige Erweiterungen gewesen :)

[HomeAutoUser]

@sidey79 ich habe mal eine freie halbe Stunde genutzt.

{"name":"GT-WT-02", "id":"0", "module":"CUL_TCM97001", "data": [
    {
      "dmsg":"s5410AC5F9800", "comment":"Temp / Hum sensor for GT-WS-11-CH + WS08 + WS09 new", "user":"Ralf9",
      "internals": {"DEF":"CUL_TCM97001_84", "NAME":"GT_WT_02_84"},
      "readings": {"state":"T: 17.2 H: 47", "battery":"ok", "batteryState":"ok", "channel":"2", "humidity":"47", "mode":"normal", "temperature":"17.2"},
      "attributes": {"model":"GT_WT_02"},
      "minProtocolVersion":"1.27", "revision_entry":"2021-02-16 13:25:35",
      "revision_modul":"14_CUL_TCM97001.pm 20839 2019-12-28 09:41:47Z bjoernh",
      "rmsg":"MS;P1=-4129;P2=550;P3=-2100;P4=-9055;D=2423212321232123232323232123232323212321232121232323212321212121212123232121;CP=2;SP=4;R=241;O;s=4;m1;"
    }
  ]
},
{"name":"Prologue", "id":"0", "module":"CUL_TCM97001", "data": [
    {
      "dmsg":"s916001A0A000", "comment":"Channel 0 right?", "user":"SD_Protocol",
      "internals": {"DEF":"CUL_TCM97001_145", "NAME":"Prologue_145"},
      "readings": {"state":"T: 2.6", "battery":"ok", "batteryState":"ok", "channel":"0", "mode":"normal", "other":"2.6", "temperature":"2.6"},
      "attributes": {"model":"Prologue"},
      "revision_entry":"unknown",
      "revision_modul":"unknown",
      "rmsg":"MS;P0=-4152;P1=643;P2=-2068;P3=-9066;D=1310121210121212101210101212121212121212121212121010121012121212121012101212;CP=1;SP=3;R=220;O;m2;"
    }
  ]
},

Ich würde es so einpflegen und bei jedem Eintrag der hinzu kommt, wird der Punkt minProtocolVersion gesetzt auf die aktuelle Version und bei Protokollen, welche geupdatet werden, bleibt dieser unangetastet.

[sidey79]

minProtocolVersion wäre nur zu ändern, wenn es mit einer vorherigen Version nicht mehr funktioniert denke ich.

Was ist der Hintergrund als revision mehrere Angaben (Dateiname, SVN Commit, Zeitstempel und Author) zu erfassen?

[HomeAutoUser]

Hintergrund die Daten revision_modul mit den Syntax zu füllen entspricht der Ausgabe von der Versionsausgabe vom Modul ;)

Gib doch mal version 14_SD_UT.pm ein ;) So sehen wir, mit welchem genauen Stand das Ergebnis erzielt wurde. Grund hierfür ist auch, das Readings sich ändern können und ich möchte ungern Readings drin lassen was nicht mehr existent ist.