Ablage der RAW Daten im Wiki

[HomeAuto_User]

An welchen Aufbau hast Du bei der SD_ProtocolList.json gedacht, was soll alles rein?

Ich dachte an solch einen Aufbau:

Code Auswählen Erweitern

   "1" : {
      "clientmodule" : "SD_RSL",
      "comment" : "remotes and switches",
      "msg01_comment" : "msg01",
      "msg01_dmsg" : "-",
      "msg01_raw" : "MS;P1=1138;P2=-723;P3=583;P4=-1285;P5=-7166;D=351234341234341212341212123412343412341234341234343434343434343434;CP=3;SP=5;R=247;O;m2;",
      "msg01_user" : "-",
      "msg02_comment" : "msg02",
      "msg02_dmsg" : "-",
      "msg02_raw" : "MS;P1=1154;P2=-697;P3=559;P4=-1303;P5=-7173;D=351234341234341212341212123412343412341234341234343434343434343434;CP=3;SP=5;R=247;O;",
      "msg02_user" : "-",
      "msg03_comment" : "msg03",
      "msg03_dmsg" : "-",
      "msg03_raw" : "MS;P0=561;P1=-1291;P2=-7158;P3=1174;P4=-688;D=023401013401013434013434340134010134013401013401010101010101010101;CP=0;SP=2;R=248;m1;",
      "msg03_user" : "-",
      "name" : "Conrad RSL v1"
}

- Die Rubriken ... _raw | ... _dmsg sind selbsterklärend.
- ... _user , würde ich den Benutzer hinzufügen von wem Sie stammen wenn bekannt
- ..._comment , soll mit dem "state" versehen werden oder mit dem zu erwartenden Resultat (Bsp.: T:21,4 oder open ....) --> kann ggf auch aus mehreren Wörtern bestehen welche in der Ansicht für die Setlist mit Unterstrich "zusammengefügt werden" anstatt ein Leerzeichen.

[Ralf9]

Der name soll den Sensornamen enthalten, wie machst Du es bei den IDs bei den es mehrere Sensoren gibt, wie z.B. die ID 0

[Sidey]

Wofür ist die

"1" : {


gut?

Grüße Sidey

[HomeAuto_User]

Wofür ist die

"1" : {

gut?

Grüße Sidey

Diese steht für die ID nummer vom Protokoll.

Der name soll den Sensornamen enthalten, wie machst Du es bei den IDs bei den es mehrere Sensoren gibt, wie z.B. die ID 0

Der Sensorname muss im comment hinterlegt werden.

Grund dafür ist, das auf Basis unsere SD_ProtocolData.pm Datei alle Nachrichten eingelesen werden. Überalle wo davor oder dahinter ein Kommentar ist, wende ich diesen als Comment aber ersetze Leerzeichen durch Unterstriche bzw. mache aus 2 Unterstrichen nur einen .... Also ich passe die bereits vorhanden Texte an.
Nachdem diese als Vorlage gilt, kann man Eigenhändig die Comments. Bei keinem Comment aber einer RAWMSG habe ich msg + Counter stur geschrieben. Dies ist über das Menü änderbar. (soll es werden)

.... wenn die Berarbeitung fertig ist, so wird die Datei gespeichert und jeder kann diese Einlesen ggf. ergänzen. Bei neuen Protokollen sollen dann die Einträge welche ggf. in die SD_ProtocolData.pm Datei kommen, automatisch hinten dran kommen. Ich denke das Prinzip sollte erstmal klar sein von meiner Vorstellung 

EDIT: Ich möchte ungern Informationen welche schon vorhanden sind, einfach doppelt eintragen müssen oder vernachlässigen. Eine weitere Zusatzdatei soll auch nicht zum tragen kommen, das wir nur 2 Punkte haben.

[Sidey]

Diese steht für die ID nummer vom Protokoll.

Pack das doch auf die gleiche Ebene wir       "clientmodule" : "SD_RSL",


Da passt es dann doch auch hin oder?

[HomeAuto_User]

Guten Abend und gute Nacht 

hier ist mal ein Screenshot wie ich mir das denke mit Liste.
Es ist die Gesamtübersicht. Man könnte das nun koppel mit dem DispatchModul Eintrag, das man nur diese sieht welches Modul eingetragen wurde.

Wie denkt Ihr darüber?

Pack das doch auf die gleiche Ebene wir       "clientmodule" : "SD_RSL",

Was meinst du damit?

[Ralf9]

Das der Name des Sensors/Fernbedienung nur im Kommentar steht, finde ich nicht so gut.
Ich dachte wir wollen mit der Liste aktuelle rawdaten von Sensoren (nach Möglichkeit von verschiedenen usern) erfassen.
In der SD_ProtocolData.pm hat es auch ältere rawdaten, die fehlerhaft sind da eine ältere firmware verwendet wurde.

[HomeAuto_User]

Ich denke wir bekommen alles in eine Liste Ralf. Wir sind eben nur noch in der Findungsphase.

Die existierenden RAWs würde ich auch nicht weglassen wollen.

Die Namen können wir ja auch anpassen. Die Sortierung beginnend mit Modul fände ich schon am besten.

Die Spalte ID, okay könnten wir weglassen und somit zusätzlichen Platz für Namen schaffen.


Gesendet von iPhone mit Tapatalk Pro

[Sidey]

Ich meinte mit meinem Kommentar, dass man dem Wert 1 einen Namen gibt:

So wie der Wert SD_RSL einen Namen Clientmodul trägt.


Und da mehrere Einträge macht man am besten über Listen und nicht über die Namen der Keys

Code Auswählen Erweitern


"Data" : [
{ "protocol":"value1", "clientmodule":"value2" },
{ "Protocol":"value3", "clientmodule":"value4" }
]


Selbiges kann man auch für die RAw Nachrichten usw machen.

Gesendet von meinem Moto Z (2) mit Tapatalk

[HomeAuto_User]

Die Frage stellt sich, mit welcher Struktur kommen wir am besten?

Wenn ich das richtig deute, dann mit der von dir dargestellten Option via Listen @Sidey79.

Code Auswählen Erweitern


"Data" : [
{ "protocol":"value1", "clientmodule":"value2" },
{ "Protocol":"value3", "clientmodule":"value4" }
]


Was die Verarbeitung der existierenden Infos bzw RAWs in der ProtokollDatei geht, bin ich auch bereit diese zu überarbeiten um dort ein bestmögliches Syntaxverhalten zu haben. Die Infos dann zusammenführen mit den ,,gesammelten Zusatzinfos" schafft uns eine umfassende Dokumentation.

Ist es machbar, Einträge aus dem Hash zu vergleichen dann? Ich denke an den Fall, das Änderungen vorgenommen werden.


Gesendet von iPhone mit Tapatalk Pro

[Harst]

Ich muss mich Ralf wegen des Sensornamen anschließen. Kommentar sollte ein Kommentar sein und nicht notwendige Infos enthalten. Aus meiner Sicht brauchen Wir als Felder den Sensornamen und die Funktion (Ein/Aus,...). Ihr denkt bisher von der Sicht des Modulbetreibers aus. Ein Tester würde z.B. die Meldungen eines Sensors suchen und durch die Module laufen lassen.

Ich würde auch die Tags nicht numerieren:

Code Auswählen Erweitern

"1" : {
      "clientmodule" : "SD_RSL",
      "comment" : "remotes and switches",
      "messages" : {
         {
            "name": "Bosch Wallswitch",
            "function": "On" ,
            "comment" : "msg01",
            "dmsg" : "-",
            "raw" : "MS;P1=1138;P2=-723;P3=583;P4=-1285;P5=-7166;D=351234341234341212341212123412343341234343434343434343434;CP=3;SP=5;R=247;O;m2;"
         },
         {
            "name": "Bosch Wallswitch",
            "function": "Off",
            "comment" : "msg01",
            "dmsg" : "-",
            "raw" : "MS;P1=1138;P2=-723;P3=583;P4=-1285;P5=-7166;D=351234341234341212341212123412343341234343434343434343434;CP=3;SP=5;R=247;O;m2;"
         },
         {
            "name": "Bosch Wallswitch",
            "function": "Off",
            "comment" : "msg01",
            "dmsg" : "-",
            "raw" : "MS;P1=1138;P2=-723;P3=583;P4=-1285;P5=-7166;D=351234341234341212341212123412343341234343434343434343434;CP=3;SP=5;R=247;O;m2;"
         },
     }
      "name" : "Conrad RSL v1"
}


Man kann ja für eine Reihenfolge noch ein Feld einfügen.

Wichtiger: Was machen wir mit Neueintragungen ohne Protokoll?
Ganz ohne Hintergrund hätte ic deshalb die Infos in die oberste Ebene gesetzt, die da ist, also
Sensor
  Funktion
    Daten hierzu
  Funktion
    Daten hierzu
Sensor
  Funktion
    Daten

Horst

[HomeAuto_User]

Ich verstehe eure Meinungen und Ansichten und mit dem Namen des Sensors.

Sagt mir bitte, wie wollen wir die bisherigen Infos aber weiterverarbeiten welche schon gesammelt wurden in der ProtokollDatei? Dort haben wir nur Modulnamen und Kommentare was es war bzw die SensorenBezeichnungen.
Diese Informationen runterfallen zu lassen + neu pflegen bedeutet 2 Stellen was ungern gemacht werden soll.

Wir als Entwickler erstellen eine Protokolldefinition in der ProtokollDatei mit Kommentaren der Namen/Bezeichnungen + RAWMSG. Genau das soll auch sofort in der Liste mit auftauchen um NICHT 2 Stellen zu bearbeiten. Diesen Ansatz möchte ich gern vereinen und eine Lösung finden mit Euch.


Gesendet von iPhone mit Tapatalk Pro

[Harst]

Wie wäre es, diese als generic einzutragen: generic-IT für einen Standard Intertechno Sensor.

Wer mehr weiss trägt es ein.

Horst

[HomeAuto_User]

Ich denke wir kommen am besten voran, wenn wir wiefolgt gliedern ohne uns im Kreise zu drehen:

1) Schaffung bzw. Grundgerüst formen der Datenstruktur im Hash.

Code Auswählen Erweitern

{"name":"GT-WT-02", "id":"0", "dmsg":"s5410AC5F9800", "state":"T: 17.2 H: 47", "user":"Ralf9",
"rmsg":"MS;P1=-4129;P2=550;P3=-2100;P4=-9055;D=2423212321232123232323232123232323212321232121232323212321212121212123232121;CP=2;SP=4;R=241;O;s=4;m1",
}

2) Klärung ob wir den Hash mit fortlaufenden Nummern definieren, das dies so aussehen könnte wie Ralf schon vorschlug!

Code Auswählen Erweitern


"1" =>
{
name         => "GT-WT-02",
id              => "0",
dmsg      => "...",
...
}
"2" =>
{
name         => "Ventus W044",
id              => "0",
dmsg      => "...",
...
}

3) Wenn die Struktur mit allen Wünschen "geformt" ist, so würde ich als "Rohdaten" unsere Informationen aus der SD_ProtocolData.pm darin ablegen.

4) Schaffung Möglichkeit zum Bearbeiten ohne direkten Eingriff in den Hash via Befehl übers TOOL

5) Export / Import des Hash um diesen auch anderen zur Verfügung zu stellen ...

MfG

EDIT: zu 1) Wie denkt Ihr drüber? Ralf, Harst, Sidey?

[Harst]

sieht gut aus.