search

RFD-FHEM / SIGNALduino_TOOL

FHEM Module for the SIGNALduino project.
GNU General Public License v3.0
4 stars 4 forks source link

save JSON as list #1

Closed HomeAutoUser closed 3 years ago

HomeAutoUser commented 5 years ago

Wie hier https://forum.fhem.de/index.php/topic,96951.msg918315.html#msg918315 beschrieben verstehe ich aber den bei der Codeumsetzung hapert es.

Hier https://github.com/RFD-FHEM/SIGNALduino_TOOL/blob/6ad68d0fd9bab9534e25a187738c2f9be34a5db5/FHEM/88_SIGNALduino_TOOL.pm#L1281 beginnt es.

Wenn ich das abändere in $ProtocolList{id} = $id_now;

überschreibe ich mir die Werte :-(

sidey79 commented 5 years ago

Ich hab das jetzt nicht mit Code direkt ausprobiert.

Die Oberste Ebene ist ein Array und kein Objekt. Am einfachsten ist es aber vermutlich das ganze einfach mal von JSON in eine Perl Variable zu konvertieren...

Die Online Perl Editoren haben leider das JSON Modul nicht. :(

use JSON;
use DATA;

my $perl_scalar = decode_json $jsonStr;
print Data::Dumper($perl_scalar);
HomeAutoUser commented 5 years ago

Hi, wäre das nicht die richtige Struktur? http://jsoneditoronline.org/?id=bb9513fab8044faa8f49014efc2fd70f

Bei deinem Bsp. war der Eintrag Modul doppelt drin und man kann dies ja als „Rubrikname nutzen“ damit sinngemäß folgendes heraus kommt.

Array -> Module als Array mit Daten Id und jeweils darunter das Array aus den Werten ??? Oder?

sidey79 commented 5 years ago

Ja, ich glaube wir nähern uns...

Id02 würde ich auch noch auf die gleiche Ebene wie Name setzen :)

HomeAutoUser commented 5 years ago

Ich teste soeben die Variante wo ich jedem Eintrag ne nr verpasste wie schön von mir anfangs gezeigt im Forum. Werde es bestimmt morgen mal übermitteln :)

HomeAutoUser commented 5 years ago

Ich habe mal was „gebaut“. Kannst ja mal testen. Bin der Meinung wir benötigen ne nr - Ebene.

Was unsere jetzigen Kommentare in der ProtokollDatei angeht, so werde ich bestimmt diese einheitlich überarbeiten.

sidey79 commented 5 years ago

Wieso meinst Du dass Du eine Bezeichnung für den Eintrag benötigst?

HomeAutoUser commented 5 years ago

Bei den bisherigen Tests habe ich mir entweder Einträge Überschrieben oder es muss ein anderer Bezeichner in der tieferen Ebene hinzugefügt werden. Ein Array in ein Hash zu integrieren habe ich bisher nicht erfolgreich geschafft.

Vorteil von einem Bezeichner im JSON wäre, das bei direkter Bearbeitung in der Datei, man einfacher einen Eintrag hinzufügen kann.

Gern bin ich auch offen für einen anderen Weg, nur da war ich bisher in eine Sackgasse gefahren. Struktur JSON ja ohne Bezeichner aber dann gelang es mir es nicht im Hash zu integrieren.

Ralf9 commented 5 years ago

Warum möchstest Du es mit der JSON so kompliziert machen, es reicht auch eine JSON Struktur. Die nr kannst Du beim zeilenweise einlesen der JSON Datei als key in den Hash schreiben. rawmsg json

Das automatische Einlesen der rawdaten aus der SD_ProtocolData.pm ist für mich nicht brauchbar. Ich habe mal angefangen bei einigen IDs rawmsg in die JSON Datei zu übernehmen, dabei ist mir aufgefallen, daß viele der rawmsg unbrauchbar sind z.B.

Ich finde es sinnvoller nur die rawmsg in die JSON Datei zu übernehmen, bei denen auch ein dispatch erfolgt. In das SIGNALduino_TOOL kann dann eingebaut werden, daß für eine ausgewählte ID die rawmsg und die Protokolldefinition angezeigt werden kann. Dabei wäre es hilfreich wenn bei one, zero, start und sync zu den Faktoren auch die Werte angezeigt würden.

z.B.:
            zero            => [-1,2],  -400, 800
            one         => [-2,1],  -800, 400
            start           => [-10,1],  -4000, 400
            clockabs        => 400,
HomeAutoUser commented 5 years ago

Warum möchstest Du es mit der JSON so kompliziert machen, es reicht auch eine JSON Struktur. Die nr kannst Du beim zeilenweise einlesen der JSON Datei als key in den Hash schreiben.

Gern bin ich auch bereit für deine Art. Da bräuchte ich nur einen Hinweis wie du es gelöst hast und ich würde es auf die Art einlesen. Würdest du mir bei dem Codeteil bitte behilflich sein, da ich da noch keine "reine" Variante gefunden habe.

Das automatische Einlesen der rawdaten aus der SD_ProtocolData.pm ist für mich nicht brauchbar.

Für dich nicht, aber für andere Entwickler ist das gewünscht, deswegen geht nur der Weg beides. RAWMSG Nachrichten sind auch wichtig, da es eine Phase gab, wo deine FW sich von Sideys abwich von der Verarbeitung. Genau aus diesem Grund möchte ich selbst auch die RAWMSG Option offen lassen weil es sonst nicht genauer prüfbar ist im Einzelfall. (Ich denke da bsp. spontan an das letzte Bit was fehlte ....)

Thema,

Ich finde es sinnvoller nur die rawmsg in die JSON Datei zu übernehmen, bei denen auch ein dispatch erfolgt.

Das wird sich mit der Zeit revisionieren von selbst :-)

In das SIGNALduino_TOOL kann dann eingebaut werden, daß für eine ausgewählte ID die rawmsg und die Protokolldefinition angezeigt werden kann. Dabei wäre es hilfreich wenn bei one, zero, start und sync zu den Faktoren auch die Werte angezeigt würden.

Das kann man einbauen.

sidey79 commented 5 years ago

Meine 5 Cent dazu: Anstatt eine Liste durch eine Zahl im Namen zu erzeugen würde ich gleich dazu übergehen die Werte als Liste zu erfassen. Konkret aufgefallen ist es mit bei rmsg und rmsg1, dmsg und dmsg1 sowie state und state1.

HomeAutoUser commented 5 years ago

:) nicht so viele Spenden bitte :D

Meine Einarbeitung in Perl ist noch nicht so weit vorgedrungen / oder ich sehe die Lösung vor dem Code nicht, so wäre ein Codebeispiel hilfreich.

Ralf9 commented 5 years ago

Bei dmsg1, rmsg1, dmsg2, rmsg2 wird die Zahl benötigt, daß jeder Eintrag eine Nr hat. z.B: 14 - dmsg 14.1 - dmsg1 14.2 - dmsg2

Code kommt heute Nachmittag.

sidey79 commented 5 years ago

Wie man einen Array in JSON macht, hatte ich bereits in einigen Beispielen geteilt. Hier noch mal eine Referenz: https://www.w3schools.com/js/js_json_arrays.asp

Das Einlesen des JSON Strings macht das Modul JSON. Da gibt es decode_json als Befehl und bekommst eine Variable.

Mehr als zwei Zeilen Code brauchst Du da eigentlich nicht.

HomeAutoUser commented 5 years ago

Bei dmsg1, rmsg1, dmsg2, rmsg2 wird die Zahl benötigt, daß jeder Eintrag eine Nr hat. ... Code kommt heute Nachmittag.

Das sehe ich auch so Ralf. Danke schon vorab für den Code @Ralf9

Das Prinzip ist schon klar @sidey79

{"name":"Ford", "models":["Fiesta", "Focus", "Mustang"]},

nur muss ich da vermutlich den String selbst "bauen" ? Es geht ja darum, aus dem Hash den String bauen zu lassen. Ich werde erstmal auf den Code von Ralf warten und dann drüber schauen.

sidey79 commented 5 years ago

Dafür gibt es die Funktion encode_JSON :)

Ralf9 commented 5 years ago

In dem array sind die Felder in der Reihenfolge gespeichert wie sie in dem Returnfenster ausgegeben werden sollen. Für die Syntaxprüfung werden die Felder auch in einem hash gespeicht.

my @rawmsg_fields        = qw(name id module dmsg user state repeat model comment rmsg);
my %rawmsg_fields_hash = ();
if ($cmd eq "rawmsg_list") {
    %rawmsg = ();
    %rawmsg_ids = ();                                   ';
    my $nr = 0;
    my $id;
    my $field;
    my $l;

    my $fieldNoDigit;
    my $json;
    my $jsonFlag = 0;
    my $file = RAWMSG_FILE;
    open my $info, $file or return "ERROR: No file ($file) exists!";
    while( my $line = <$info>)  {
        last if ($line =~ m/^{}/);      # Ende der json Daten
        if (substr($line,0,1) eq "{") {     # Begin json
            $nr++;
            $jsonFlag = 1;
            $json = $line;
        }
        elsif (substr($line,0,1) eq "}") {  # Ende json
            $jsonFlag = 0;
            $json .= $line;
            my $decoded = eval { decode_json($json) };
            foreach $field (keys %{$decoded}) {
                $fieldNoDigit = $field;
                $fieldNoDigit =~ s/\d+$//;      # Zahl am Ende entfernen
                if (!exists($rawmsg_fields_hash{$fieldNoDigit})) {
                    Log3 $name,3,"$name rawlist: json=$json";
                    Log3 $name,3,"$name rawlist: nr=$nr field=$field not found";
                }
                else {
                    $rawmsg{$nr}{$field} = $decoded->{$field};
                    #Log3 $name,3,"$name rawlist: nr=$nr field=$field val=$decoded->{$field}";
                }
            }
            if (exists($rawmsg{$nr}{id})) {
                $id = $rawmsg{$nr}{id};
                if (!exists($rawmsg{$nr}{module})) {        # clientmodule eintragen
                    if (exists $ProtocolListSIGNALduino->{$id}{clientmodule}) {
                        $rawmsg{$nr}{module} = $ProtocolListSIGNALduino->{$id}{clientmodule};
                    }
                    else {
                        $rawmsg{$nr}{module} = "";
                    }
                }
                if (!exists($rawmsg_ids{$id})) {    # ID hash erstellen
                    $rawmsg_ids{$id} = $nr;
                }
            }
        }
        elsif ($jsonFlag == 1) {
            $json .= $line;
        }
    }

    return $returnList;
}
sidey79 commented 5 years ago

Also die JSON Datei solltet nicht zeilenweise eingelesen werden, denn ein Zeilenumbruch kann an jedem Ende eines Bezeichners vorkommen. Die Klammer { und } als Start / Ende Erkennung stimmen meiner Meinung nach auch nicht, denn diese Klammern bedeuteten nur, dass in diesem Bereich ein Objekt existiert.

Um die Datei auf einen Rutsch einzulesen un zu dekodieren reichen ein paar Zeilen:

my $json;
{
  local $/; #Enable 'slurp' mode
  open my $fh, "<", "data.json";
  $json = <$fh>;
  close $fh;
}
my $data = decode_json($json);
Ralf9 commented 5 years ago

Momentan wird in dem $rawmsg_ids hash nur die erste nr pro id gespeichert, es muss noch erweitert werden, daß pro ID in einem array die nr aller Einträge mit der selben ID gespeichert werden. z.B.

(
"0" => [1,2,3],
"0.1" => [4],
"0.3" => [5,6],
"35" => [14,14.1]
)

Ich verwende {} als Ende, dahinter sind leere Beispieleinträge

{}
{"name":"", "id":"", "dmsg":"", "state":"", "user":"", "comment":"",
"rmsg":""
}
{"name":"", "id":"", "dmsg":"", "state":"", "user":"", "comment":"",
"rmsg":"",
"dmsg1":"", "state1":"", "comment1":"",
"rmsg1":"",
"dmsg2":"", "state2":"", "comment2":"",
"rmsg2":"",
}
Ralf9 commented 5 years ago

Also die JSON Datei solltet nicht zeilenweise eingelesen werden, denn ein Zeilenumbruch kann an jedem Ende eines Bezeichners vorkommen.

Ich habe festgestellt, daß die Zeilenumbrüche beim zeilenweise einlesen keine Probleme machen. Wenn ich die Datei in einem Rutsch einlese, kann ich beim Einlesen keine Syntaxprüfung der Feldnamen durchführen. Ich kann dann auch nicht den key mit der Nummer ergänzen. Wenn die {} fehlen, meckert die Syntaxprüfung im Editor

sidey79 commented 5 years ago

Für mich sieht das ziemlich kompliziert aus. Ich hatte gedacht, man speichert die Daten im JSON Format und hat dann eine Datenstrukturen in einer Variable mit der man arbeitet. Z.B. in einer Schleife.

Wozu hier Keys benötigt werden weiss ich leider nicht. Da stecke ich vermutlich nicht tief genug in den Details was ihr mit der Variable macht.

Ralf9 commented 5 years ago

Die JSON Daten werden in einem Texteditor eingegeben und dann commitet. Es können in den JSON Daten Syntax Fehler sein oder die Feldnamen falsch geschrieben sein.

Wenn Du die JSON Datei auf einen Rutsch einliest, wie kannst Du dann bei einem decode_json Abbruch feststellen in welchem Eintrag ein Fehler ist?

Wie willst Du ohne eindeutige keys auf die einzelnen Einträge zugreifen.

Ich möchte damit auch alle Einträge von einem bestimmten Namen, ID oder Modul ausgeben können.

Es soll auch möglich sein automatisiert für alle oder ein Teil der Einträge mit den rawmsg ein get dummysduino raw zu machen und dann die demodulierte dmsg mit der dmsg der json Daten zu vergleichen. Dazu wird beim get dummysduino raw in einem internal des dummysduino die nr des Eintrags gespeichert. Die nr wird dann per dispatch zusammen mit der dmsg an das SIGNALduino_TOOL übergeben. In der parse Routine kann dann mit der nr die übergebene dmsg mit der dmsg aus den JSON Daten verglichen werden.

sidey79 commented 5 years ago

Decode_JSON gibt eine Fehlercodes zurück . Darin ist Zeilennummer und auch der Fehler enthalten. Die können, abgefragt und ausgegeben werden. Ein eval hilft an dieser Stelle.

Wenn Feldnamen falsch geschrieben werden, dann wird das Feld bei der Verarbeitung ignoriert.

Ohne Key kann weiterhin auf die Einträge über einen Array zugegriffen werden. Die sind nebenbei auch sortiert.

Die Anforderung an Get raw und anschließend das Ergebnis vergleichen stelle ich mir nicht kompliziert vor. Wenn die Einträge in einer Liste stehen, kann auf jedes Element über einen Index zugegriffen werden. Merkt man sich den Index, kann Problemlos immer auf den gleichen Eintrag zugegriffen werden.

Wieso das SIGNALDUINO_Tool per Dispatch an sich selbst etwas weitergib verstehe ich gerade nicht. Wird aber womöglich auch funktionieren nehme ich an.

Wenn jemand ganz sicher gehen will, könnte er sich auch einen md5 Hash auf bestimmte Werte errechnen und den als eindeutigen Identifier verwenden. Wäre aber nur sinnvoll, wenn doubletten erkannt werden sollen

Ralf9 commented 5 years ago

Ohne Key kann weiterhin auf die Einträge über einen Array zugegriffen werden. Die sind nebenbei auch sortiert.

Demnach gefällt es Dir nicht so wie ich es mache. Ich kann mir nicht vorstellen wie es ohne einen eindeutigen key funktionieren soll. Wenn Du es ohne einen key haben willst, mußt Du es selbst programmieren.

sidey79 commented 5 years ago

Wenn der Key nicht benötigt wird, würde ich ihn weglassen. Ich gehe bislang davon aus, dass dieser key nicht notwendig ist. Woher weiss denn die Person die einen Eintrag hinzufügt, was für einen Namen sie dem key geben soll?

Eigentlich wollte ich erst mal das Datenformat erarbeiten, bevor hier gecoded wird.

Aber gut, ich hab mal ein Gist angelegt mit einem kleinen codesnippet zur Veranschaulichung eines Arrays bzw. dessen Abarbeitung: https://gist.github.com/sidey79/6b04dc5b7732b49acc75d541cd2b2f09

Wenn man den Index braucht, kann man dies mit der for schleife ganz gut machen. Alternativ geht es aber auch mit einer while Schleife.

Die foreach Variante verrät einem erst mal nicht die Position, an der es steht,

HomeAutoUser commented 5 years ago

Hallo, ich habe mir nun nochmal alles hier durchgelesen uns angesehen. Ich denke wir sollten erstmal einen Schritt vor den anderen machen. Erneut werde ich mal versuchen Schritt für Schritt erneut erläutern um mein evenuell flasch ausgedrückte Denkweise zu vermitteln.

Wie man einen Array in JSON macht, hatte ich bereits in einigen Beispielen geteilt. Hier noch mal eine Referenz: https://www.w3schools.com/js/js_json_arrays.asp Das Einlesen des JSON Strings macht das Modul JSON. Da gibt es decode_json als Befehl und bekommst eine Variable. Mehr als zwei Zeilen Code brauchst Du da eigentlich nicht.

Das habe ich vernommen und auch selbst so schon umgesetzt. In dem Kommando "ProtocolList_from_file_SD_ProtocolData" wird unsere bisherige ProtokollDefiniton auseinander genommen um bisher ALLE informationen aufzufassen. Ob diese noch gültig sind oder nicht, dies möchte ich hier nicht in Frage stellen. Diese Informationen werden Zeilenweise eingelesen mit den Codezeilen welche hier beginnen.

https://github.com/RFD-FHEM/SIGNALduino_TOOL/blob/98ad5309491433218f42ce65905beee3d316e92b/FHEM/88_SIGNALduino_TOOL.pm#L1154

Bei dem Einlesen werden die Informationen im Hash gespeichert.

if ($comment ne "") {
        $ProtocolList{$cnt_RAWmsg}{$NameOnJSON[0]} = $comment;
        #Log3 $name, 4, "$name: Get $cmd - id:$id_now comment = $comment";
    } else {
        $cnt_id_same++;
        $ProtocolList{$cnt_RAWmsg}{$NameOnJSON[0]} = "unknown_$cnt_id_same";        ## state from message
    }

    $ProtocolList{$cnt_RAWmsg}{$NameOnJSON[1]} = "-";                           ## dmsg
    $ProtocolList{$cnt_RAWmsg}{$NameOnJSON[2]} = $RAWMSG;                   ## raw

    if ($device_user ne "") {
        $ProtocolList{$cnt_RAWmsg}{$NameOnJSON[3]} = $device_user;      ## user
    } else {
        $ProtocolList{$cnt_RAWmsg}{$NameOnJSON[3]} = "unknown";             ## user
    }
    #$ProtocolList{$cnt_RAWmsg}{$NameOnJSON[4]} = "$id_name";

    if ($device_name ne "") {
        $ProtocolList{$cnt_RAWmsg}{$NameOnJSON[5]} = $device_name;  ## sensor_name
    } else {
        $ProtocolList{$cnt_RAWmsg}{$NameOnJSON[5]} = "generic";         ## sensor_name
    }

    #$ProtocolList{$cnt_RAWmsg}{$NameOnJSON[6]} = "$id_comment";
    $ProtocolList{$cnt_RAWmsg}{$NameOnJSON[9]} = "$id_now";

    if (defined $id_clientmodule) {
        $ProtocolList{$cnt_RAWmsg}{$NameOnJSON[7]} = lib::SD_Protocols::getProperty($id_now,"clientmodule");
    } else {
        $ProtocolList{$cnt_RAWmsg}{$NameOnJSON[7]} = "not assigned";
    }

    ## flag from where ##
$ProtocolList{$cnt_RAWmsg}{$NameOnJSON[8]} = "x";

Nun sollen diese Informationen in einer JSON Datei gespeichert werden weil das auch mal die Datei um Austausch werden soll.

Der jetzige Fehler bei mir @sidey79 ist, das ich die Daten, welche von einer ID kommen und aber mehrere RAWMSG oder DMSG vorhanden wären, nicht richtig geschrieben erhalte im Hash um dann auf deine gewünschte Struktur https://www.w3schools.com/js/js_json_arrays.asp oder http://jsoneditoronline.org/?id=bb9513fab8044faa8f49014efc2fd70f zu kommen.

Das Decodieren machen dann die Zeilen

#### JSON write to file ####
## fix -> to optimum without PERL WARNING: Argument ...$JSON::PP::a <=> $JSON::PP::b, $JSON::PP::a cmp $JSON::PP::b
my $json = JSON::PP->new()->pretty->utf8->sort_by( sub { $JSON::PP::a <=> $JSON::PP::b or $JSON::PP::a cmp $JSON::PP::b })->encode(\%ProtocolList);                 # lesbares JSON | Sort numerically

readingsSingleUpdate($hash, "state" , "file $jsonFile created", 0);

open(SaveDoc, '>', $path.$jsonFile) || return "ERROR: file ($jsonFile) can not open!";
    print SaveDoc $json;
close(SaveDoc);

Bis dahin sollte eine Datei geschaffen werden, welche man austauschen könnte. Diese Datei soll nicht gedacht werden um direkt zu bearbeiten. (Das könnte aber SOLL nicht)

Wenn die Datei die passende Struktur hat, so soll diese auch wieder einlesbar werden um nach einem Tausch bsp. den selbigen Stand in den Hash zu laden. Wenn das alles gegeben ist, so flücke ich mir die Daten heraus um eine Setliste zu bauen.

WENN das alles geschaffen ist, so kann @Ralf9 seine Funktionen integrieren ABER die Anpassung in der 00_SIGNALduino.pm muss nicht unbedingt sein. Das Tool soll zum Dispatchen genutzt werden und mit der internen Funktion (Auswahl Clientmodul) werden die Informationen Bereitgestellt.

Die Meiungen und Funktionen neigen isch vielleicht auseiander aber um Zukunfsorientiert zu blicken, benötigen wir etwas, was die Arbeit erleichert wenn man Zwischenfälle prüfen möchte oder einfach Module erweitern möchte.

MfG

Ralf9 commented 5 years ago

Anscheinend reden wir hier von verschiedenen json Dateien. Bei der json Datei um das es mir und Harst geht, sollen die Daten im Texteditor zugefügt und dann in den Github commitet werden. Ablage der RAW Daten im Wiki Es sollen dort die raw Daten von Sensoren gesammelt werden, wegen den Toleranzen sind Daten von verschiedenen Anwenderen wünschenswert. Es sollen da nur Daten von einer aktuellen firmware reinkommen. Ein automatisches einlesen von rawdaten von der protokollhash Datei halte ich nicht sinnvoll, da dort viele alte und fehlerhafte raw Daten drin sind

HomeAutoUser commented 5 years ago

Wir reden hier nicht um 2 verschiedene Dateien oder Funktionen. Wenn wir erst den einen Schritt machen würden, dann kommen wir auch zu deiner Funktion @Ralf9.

Das ganze Thema Dokumentation habe ich in das Tool eingebaut weil mir da noch viel mehr Ideen vorliegen zur Nutzung.

ZIEL ist es, nach dem Einlesen, die BESTANDSinformationen zu erhalten und auch zu revisionieren bzw. abzuändern mit dem TOOL.

Ein automatisches einlesen von rawdaten von der protokollhash Datei halte ich nicht sinnvoll, da dort viele ...

Von einem automatischen einlesen war NIE die Rede. Alles muss der User schon selbst machen via "Klick". Die Weiterverarebitung soll auch später so erfolgen, das man die Informationen vergleichen kann.

Anfangs warst du sehr angetan wenn sich jemand um die Dokumentation und Überarbeitung kümmert und nun scheint es mir, als würde man mit Hürden argumentieren obwohl selbst ALLE aus dem Resultat protieren.

Ich bekunde noch einmal erneut, ich möchte gern die Arbeit erleichtern und Wege finden, welche UNS aber auch neuen Usern die Zuarbeit oder Mitarbeit erleichern. Bitte lasst uns ziehen an EINEM Strang @sidey79 @Ralf9 @elektron-bbs @MoskitoHorst Dokumentation / Hilfsmittel sind wichtig.

@Ralf9 gehen wir Schritt 1 zusammen an bitte um dann Eure Vorstellung zu integrieren bitte. Es bringt nichts, wenn wir etwas integrieren und Ihr nicht mit einbezogen werdet oder den Schritt 1 eh umbaut.

Ralf9 commented 5 years ago

ABER die Anpassung in der 00_SIGNALduino.pm muss nicht unbedingt sein. Das Tool soll zum Dispatchen genutzt werden und mit der internen Funktion (Auswahl Clientmodul) werden die Informationen Bereitgestellt.

Da das automatische parsen und demodulieren der rawmsg über get dummysduino raw und anschließendem vergleichen der dispatchen dmsg anscheinend nicht in das SIGNALduino_TOOL Modul dazupasst, ist es wahrscheinlich besser, wenn ich dafür ein eigenes modul mache.

Ich habe inzwischen ein Teil der rawmsg in meine lokale json Datei übernommen. Ich habe dabei festgestellt, daß viele rawmsg nicht brauchbar sind.

Das get dummysduino raw und vergleichen der dispatchen dmsg funktioniert inzwischen bis auf einige Kleinigkeiten und die Ausgabe des Ergebnisses

HomeAutoUser commented 5 years ago

@Ralf9 WIE sicher bist DU, das die Nachrichten BEI DIR nicht gehen und bei @sidey79 nicht? Bitte pauschalisiere das nicht. Es gibt genügend Beispiele im Forum wo aufgrund der Version von Dir und @sidey79 "Konflikte" auftreten. Das ganze wollen wir vermeiden und steuern mit der Durcharbeitung von allem.

Ein neues Modul wäre sehr schade weil wir nicht mehrere Dinge verteilen müssen obwohl wir den selbigen Ansatz vertreten. Gern möchte ich die Zusammenarbeit fördern und ermöglich mit den kleinen Hilfsmitteln weil ein solches Projekt immer wieder neue Wissende findet welche sehr zufrieden sind, wenn sie Kleinigkeiten übernehmen können.

Ralf9 commented 5 years ago

@Ralf9 WIE sicher bist DU, das die Nachrichten BEI DIR nicht gehen und bei @sidey79 nicht?

Ich habe es leider nicht aufgeschrieben, bei welchen IDs ich fehlerhafte rawmsg gefunden habe. Auf die schnelle habe ich nur bei den IDs 5,64 und 74 fehlerhafte rawmsg gefunden. Wenn man die von den IDs 5 und 74 anschaut, sieht man daß diese von einer alten Firmware sind und nicht gehen können. Bei der ID 64 die die rawmsg z.T. zu kurz

elektron-bbs commented 5 years ago

Mhmm, die eine RAWMSG bei Protokoll 74 funktioniert hier wunderprächtig. Bei Protokoll 64 können die ersten beiden wegen der Länge nicht passen, die 3. ist OK. Das sieht man aber auch jetzt schon im TOOL anhand der Readings. Es dürfte kein Problem sein, RAWMSG, die nicht weiter verarbeitet werden, dann auch nicht weiter zu verarbeiten. Noch besser wäre es, sie gleich aus der SD_ProtocolData.pm zu entfernen.

Vorerst geht es aber m.E. um ein sinnvolles Ausgabeformat in eine Datei. Dieses sollte möglichst unviversell weiter zu verarbeiten sein, zur Not auch in einem Texteditor. Wir haben zuerst auch mit etwas csv-ähnlichem probiert, dann aber schnell bemerkt, das das extrem unübersichtlich ist, sobald mehrere Felder in einer Zeile sind.

sidey79 commented 5 years ago

@HomeAutoUser

Ich bin auch dafür, erst mal die Datenablage zu bestimmen und dann die Funktionalitäten dazu bauen.

Das habe ich vernommen und auch selbst so schon umgesetzt. In dem Kommando "ProtocolList_from_file_SD_ProtocolData" wird unsere bisherige ProtokollDefiniton auseinander genommen um bisher ALLE informationen aufzufassen. Ob diese noch gültig sind oder nicht, dies möchte ich hier nicht in Frage stellen. Diese Informationen werden Zeilenweise eingelesen mit den Codezeilen welche hier beginnen.

Bei dem Einlesen werden die Informationen im Hash gespeichert.

Wenn ich das Richtig verstehe soll aus der Variable ProtocolList das JSON welches wir gemockt haben erstellt werden. Dann darf ProtocolList kein Hash sein, sondern müsste als Liste definiert werden, denn ein Hash bzw. ein Hashref wird in JSON in ein Objekt gewandelt. Eine Liste wird auch in JSON zu einer Liste. Die 1. Ebene waren in meinem Beispiel eine Liste:

Ich habe die JSON Decodierte Liste mal gedumpt, damit wird es glaube ich visibler:

$VAR1 = {
          'data' => [
                      {
                        'raw' => 'MS;P1=-2140;P2=309;P3=-4690;P4=-9695;D=2421232323232121232123232321212121212121212123212121232121;CP=2;SP=4;R=211;m1;',
                        'dmsg' => '-',
                        'user' => 'unknown',
                        'protocol_info' => 'x',
                        'state' => 'no info'
                      }
                    ],
          'name' => 'generic',
          'id' => '0.2'
        };
$VAR2 = {
          'id' => '0',
          'data' => [
                      {
                        'protocol_info' => 'x',
                        'state' => 'no info',
                        'dmsg' => '-',
                        'user' => 'unknown',
                        'raw' => 'MS;P1=-7949;P2=492;P3=-1978;P4=-3970;D=21232423232424242423232323232324242423232323232424;CP=2;SP=1;R=245;O;'
                      }
                    ],
          'name' => 'generic'
        };
$VAR3 = {
          'id' => '0',
          'data' => [
                      {
                        'raw' => 'MS;P1=-7949;P2=492;P3=-1978;P4=-3970;D=21232423232424242423232323232324242423232323232424;CP=2;SP=1;R=245;O;',
                        'state' => 'no info',
                        'protocol_info' => 'x',
                        'user' => 'unknown',
                        'dmsg' => '-'
                      },
                      {
                        'raw' => 'MS;P1=-7949;P2=492;P3=-1978;P4=-3970;D=21232423232424242423232323232324242423232323232424;CP=2;SP=1;R=245;O;',
                        'user' => 'unknown',
                        'dmsg' => '-',
                        'state' => 'no info',
                        'protocol_info' => 'x'
                      }
                    ],
          'name' => 'generic'
        };

Um also das dmsg in der passenden Form zu speichern, wäre folgendes notwendig:

$ProtocolList[$index]{data}[$cnt_RAWmsg]{dmsg} = $dmsg; (Ungetesteter code,)

Der jetzige Fehler bei mir @sidey79 ist, das ich die Daten, welche von einer ID kommen und aber mehrere RAWMSG oder DMSG vorhanden wären, nicht richtig geschrieben erhalte im Hash um dann auf deine gewünschte Struktur https://www.w3schools.com/js/js_json_arrays.asp oder http://jsoneditoronline.org/?id=bb9513fab8044faa8f49014efc2fd70f zu kommen.

Die Strukut erreichst Du nur, wenn Du Listen bzw. Hashrefs an der richigen Stelle einsetzt. Bei jsoneditoronline wird das im rechten Fenster ganz anschaulich dargestellt.


#### JSON write to file ####
## fix -> to optimum without PERL WARNING: Argument ...$JSON::PP::a <=> $JSON::PP::b, $JSON::PP::a cmp $JSON::PP::b
my $json = JSON::PP->new()->pretty->utf8->sort_by( sub { $JSON::PP::a <=> $JSON::PP::b or $JSON::PP::a cmp $JSON::PP::b })->encode(\%ProtocolList);                   # lesbares JSON | Sort numerically

Das sortieren würde ich weglassen. Bei Verwendung einer Liste ist das auch nicht mehr notwendig.

HomeAutoUser commented 5 years ago

Das mit der Listenübernahme habe ich nun verstanden und auch die Neuigkeit das mit dem qw( ) war für mich neu. Die Struktur erreiche ich leider dennoch noch nicht.

Was diese Struktur http://jsoneditoronline.org/?id=bb9513fab8044faa8f49014efc2fd70f angeht, so komme ich leider noch nicht weiter.

Mir geht noch nicht in den Kopf, wie ich ohne Angabe von einen Key 2 selbige Daten nicht überschreibe.

#$ProtocolList = Hash
#$id_now = id

$ProtocolList{$id_now} = "?";               ## id
$ProtocolList{$id_now}{daten}{$NameOnJSON[1]} = "-";                ## dmsg
$ProtocolList{$id_now}{daten}{$NameOnJSON[2]} = "2"             ## raw

"id": "0.2",
"name": "generic",
"data": [

"id": "0",
"name": "generic",
"data": [

rüffel ... Ich schaffe es nur einen Wert immer "zuzuweisen"

sidey79 commented 5 years ago

Was diese Struktur http://jsoneditoronline.org/?id=bb9513fab8044faa8f49014efc2fd70f angeht, so komme ich leider noch nicht weiter.

Mir geht noch nicht in den Kopf, wie ich ohne Angabe von einen Key 2 selbige Daten nicht überschreibe.

$ProtocolList{$id_now} = "?"; ## id Du bist schon wieder dabei eine Hash Struktur aufzubauen. Das JSON haben wir aber so nicht definiert. Dort ist das Element auf der obersten Ebene ein arrayelement. Was nun genau in $id_now steht habe ich nicht recherchiert, wenn das Feld id damit befüllt werden soll dann so:

$ProtocolList[0]{id} = "0.2"; ## id

$ProtocolList[0]{name} = "generic";

dmsg muss dann in eine array Struktur unterhalb daten:

$ProtocolList[0]{daten}[0]{dmsg} = "-";             ## dmsg
$ProtocolList[0]{daten}[0]{rmsg} = "-";             ## rmsg

Ein 2. data Datensatz wird dann wie folgt ergänzt:

 $ProtocolList[0]{daten}[1]{dmsg} = "-";                ## dmsg
 $ProtocolList[0]{daten}[1]{rmsg} = "-";                ## rmsg

Und das Nächste Protokoll über einen neuen Index.

$ProtocolList[1]{id} = "0.3"; ## id

Für das Hinzufügen von Werten in einen Array gibt es auch die push Funktion. Du musst es nicht über den Index machen.

$ProtocolList[\]{\<schlüssel>}

Je nach Schlüssel wird dann ein scalar zugewiesen oder im Falle von data ein array: $ProtocolList[\]{data}[\]{\<data schlüssel>}

Ralf9 commented 5 years ago

Mir ist noch nicht so richtig klar was Ihr vorhabt, wenn ich das richtig sehe wollt Ihr die Comments von der Protokollhash Datei einlesen und u.a. die rawmsg in eine json Datei speichern. Wenn nun von Anwendern weitere Rawmsg von Sensoren dazukommen sollen, wie sollen die dazukommen? Wollt Ihr diese weiterhin als Comment in die Protokollhash Datei eintragen?

sidey79 commented 5 years ago

Ich denke, das Eintragen der Daten sollte nur an einer Stelle erfolgen. Das wäre nach meinem Verständnis die JSON Datei.

Die Daten benötigen wir an einer zentralen Stelle. Einsenden von Nachrichten sollten für den Endanwender einfach und möglichst ohne Hürden möglich sein.

HomeAutoUser commented 5 years ago

Guten Abend, ich habe nun einen Zwischenstand, 1) die Informationen aus der SD_ProtocolData.pm Datei gelesen 2) Übersicht der bisher bekannten Zustände und User 3) derzeit als "Hilfe" exportiert wird als JSON mit der gewünschten Struktur 4) Informationen der SD_ProtocolData.pm Datei eingelesen werden und via der Attribut Dispatchmodul selektiert werden und somit die bekannten Zustände in die Setlist zum Dispatchen genommen werden. 5) "Gerneralübersicht" wieviele Protokolle und bekannte Frequenzen .... als Statistic für einen Überblick.

Mir ist noch nicht so richtig klar was Ihr vorhabt,

Das Vorhaben ist, das man mit Hilfe dieser Erleichterung die Protokolldatei einfacher "testen" kann mit den bisher dortigen Informationen. Somit kann man diese einfacher revisionieren bzw. bereinigen wenn alte RAWMSG drin sind, aber diese mit der Firmware nicht mehr ausgewertet werden oder sogar die Nachrichten eh falsch reinkopiert wurden. ---> Somit erhalten wir eine gepflegte Protokolldatei welche ständig beim erweitern durchgepflegt werden kann.

Der nächste Schritt ist nun, das man mit Hilfe der Datenstruktur, Informationen einlesen kann um gesammelte Werke einzeln zu dispatchen ggf zu erweitern. Das ist praktisch das, was die Nachrichtendokumentation angeht. Dafür benötigten wir erstmal eine Basis.

Zur Info: 1) Zum Dispatchen der Nachrichten muss keine Anpassung vorgenommen werden in der 00_SIGNALduino.pm 2) Das Dispatchen ist weiterhin aus einer wie bisher TXT Datei (siehe Github) möglich / via der Informationen im Speicher wenn man diese läd ...

Dateistruktur JSON:

   {
      "clientmodule" : "CUL_TCM97001",
      "comment" : "temperature / humidity or other sensors",
      "data" : {
         "rawmsg" : [
            "MS;P1=-7949;P2=492;P3=-1978;P4=-3970;D=21232423232424242423232323232324242423232323232424;CP=2;SP=1;R=245;O;",
            "MS;P0=-9298;P1=495;P2=-1980;P3=-4239;D=1012121312131313121313121312121212121212131212131312131212;CP=1;SP=0;R=223;O;m2;",
            "MS;P0=531;P1=-9027;P3=-4126;P4=-2078;D=0103040304040403030404040404040404040404030303040303040304030304030304040403;CP=0;SP=1;R=249;O;m2;",
            "MS;P0=-4152;P1=643;P2=-2068;P3=-9066;D=1310121210121212101210101212121212121212121212121010121012121212121012101212;CP=1;SP=3;R=220;O;m2;",
            "MS;P0=-4149;P2=-9098;P3=628;P4=-2076;D=3230343430343434303430303434343434343434343434343030343030343434343034303434;CP=3;SP=2;R=218;O;m2;"
         ],
         "state" : [
            "unknown_1",
            "unknown_2",
            "unknown_3",
            "unknown_4",
            "unknown_5"
         ]
      },
      "id" : "0",
      "name" : "weather (v1)"
   },
   {
      "clientmodule" : "CUL_TCM97001",
      "comment" : "temperature / humidity or other sensors",
      "data" : {
         "rawmsg" : [
            "MS;P1=416;P2=-9618;P3=-4610;P4=-2036;D=1213141313131313141313141314141414141414141313141314131414;CP=1;SP=2;R=220;O;m0;",
            "MS;P1=397;P2=-2033;P3=-4627;P4=-9630;D=1413121313131313121313121312121212121212121313121312131212;CP=1;SP=4;R=221;",
            "MS;P0=-9690;P3=354;P4=-4662;P5=-2107;D=3034343434343535343534343435353535353535353434353535343535;CP=3;SP=0;R=209;O;m2;",
            "MS;P1=367;P2=-2077;P4=-9415;P5=-4014;D=141515151515151515121512121212121212121212121212121212121212121212;CP=1;SP=4;O;"
         ],
         "state" : [
            "unknown_1",
            "unknown_2",
            "unknown_3",
            "unknown_4"
         ]
      },
      "id" : "0.1",
      "name" : "weather (v2)",
      "user" : "localhosthack0r"
   },

Ich denke, nun können wir weiter hantieren für den Weg der Dokumentation um eine austauschbare Datei zu erstellen und weitere Ideen welche mir ggf noch vorschweben.

HomeAutoUser commented 5 years ago

@Ralf9 bitte deine JSON Datei mal zur Verfügung stellen, das ich mich dem einlesen widmen kann ggf sehen kann wo noch Verbesserungen notwendig sind.

Ralf9 commented 5 years ago

Hier ist die JSON Datei in dem Format wie von @sidey79 vorgeschlagen. Sie ist sortiert nach IDs, das Modul wird nach dem Einlesen ergänzt. Es sind nur rawmsg drin bei denen der dispatch funktioniert. Es macht wahrscheinlich keinen Sinn IDs wie z.B. die 6 mit aufzunehmen wo nur sehr wenig bekannt ist.

rawmsg_list.json.txt

HomeAutoUser commented 5 years ago

@Ralf9 vielen Dank.

Hier ist die JSON Datei in dem Format wie von @sidey79 vorgeschlagen.

Kann es sein, das dennoch eine Verschiebung darliegt?

Variante RALF
[
    {   "name":"GT-WT-02",
        "id":"0", 
        "data": [
      {
       "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;"
      }
    ]
},

VARIANTE HomeAutoUser
[
   {
      "clientmodule" : "CUL_TCM97001",
      "comment" : "temperature / humidity or other sensors",
      "data" : {
         "rawmsg" : [
            "MS;P1=-7949;P2=492;P3=-1978;P4=-3970;D=21232423232424242423232323232324242423232323232424;CP=2;SP=1;R=245;O;",
            "MS;P0=-9298;P1=495;P2=-1980;P3=-4239;D=1012121312131313121313121312121212121212131212131312131212;CP=1;SP=0;R=223;O;m2;",
            "MS;P0=531;P1=-9027;P3=-4126;P4=-2078;D=0103040304040403030404040404040404040404030303040303040304030304030304040403;CP=0;SP=1;R=249;O;m2;",
            "MS;P0=-4152;P1=643;P2=-2068;P3=-9066;D=1310121210121212101210101212121212121212121212121010121012121212121012101212;CP=1;SP=3;R=220;O;m2;",
            "MS;P0=-4149;P2=-9098;P3=628;P4=-2076;D=3230343430343434303430303434343434343434343434343030343030343434343034303434;CP=3;SP=2;R=218;O;m2;"
         ],
         "state" : [
            "unknown_1",
            "unknown_2",
            "unknown_3",
            "unknown_4",
            "unknown_5"
         ]
      },
      "id" : "0",
      "name" : "weather (v1)"
   },

@Ralf9, würde was dagegen sprechen, wenn ich deine Liste auf die Struktur bringe wie ich sie einlese von der PM Datei? Es wäre Unsinn, wenn wir 2 verschiede hätten.

@sidey79 wie denkst du darüber?

Ralf9 commented 5 years ago

@HomeAutoUser, ja bei Deiner Variante hast Du gegenüber der von Sidey einiges abgeändert, sie ist so für mich nicht brauchbar. Ich möchte damit die rawmsg der sensoren erfassen, bei Dir fehlen u.a. der Name des Sensors, die dmsg und der user

HomeAutoUser commented 5 years ago

@Ralf9, BITTE, es geht nicht darum etwas zu haben und nicht. DU WIR IHR ...

Es geht um die Funktion und das WIR deine Schablone in die unsere Struktur einbringen. Die einzelnen Namen von dir kommen hinzu aber das Schema muss erstmal gleich sein. Du siehst nur die einzelnen DSMG vermutlich wie du es derzeit nutzt, ABER diese sind nur wichtig mit der RAWMSG, so muss ich beides zusammenfügen.

Ich möchte damit die rawmsg der sensoren erfassen, bei Dir fehlen u.a. der Name des Sensors, die dmsg und der user

Ich wiederhole mich gern, die einzelnen Namen sind nicht erfasst in der ProtokollDatei weil diese damals lässig geführt wurde. All die Nachrichten sollen erhalten bleiben und auch die RAWMSG. Das die einzelnen Namen erst hinzukommen können, ist klar, wenn man die testet. Mir kommt es vor, als ob du die RAWMSG herunterfallen lassen möchtest.

PS: @sidey79 + @Ralf9 überdenkt den Versionsname. Vorschlag dev_+ euren Kürzel einheitlich um auch Versionen von Euch überall unterscheiden zu können ;-) ... Ich stolpere öferts im Forum über solche Stolpersteine welche wir den Usern doch mal "asphaltieren" sollten. (am Besten im Rundschlag, SVN + DEV überall)

sidey79 commented 5 years ago

Ich finde, wir sollten Informationen welche zusammen gehören auch zusammen erfassen.

Bei der Variante von Homeautouser wird rmsg und dmsg in getrennten Listen erfasst. Das empfinde ich als unlogisch und der Zusammenhang ist nicht offensichtlich.

Was die ganzen Varianten angeht, sollten wir uns auf eine Version einigen die passt. Mehrere Versionen machen es nur unübersichtlich.

Den Hinweis mit dem Versionsnamen verstehe ich im Zusammenhang leider nicht. :(

HomeAutoUser commented 5 years ago

Ich sehe es ein Daten zusammenzufassen welche zusammen gehören , was auch das Ziel darstellt bei meiner Umsetzung.

Es ist nur nicht möglich, stur auf 2 Wege zu schauen wenn man etwas offenherzig schaffen möchte.

Egal ob Struktur nun falsch oder nicht, mit zugeworfenen Bruchteilen ist es schwierig umzugehen. Wie setzt Ihr bzw wollt ihr das Füllen in Data vornehmen wenn ich mehrere RAWMSG besitze? Das hin und her Liste /Array stellt eine Herausforderung dar wo ich scheinbar noch nicht vollständig Einblick habe.

Wie füllst du die Daten denn, wenn es nicht in getrennte Listen soll?

Ps: der WinkeWinke mit der dev_Bezeichnung war zu verstehen, das wir noch eine Bezeichnung Version in der JSON_Datei benötigen. :)

HomeAutoUser commented 5 years ago

Hallo @Ralf9 und @sidey79, nachdem ich mich nun mehrfach nochmal mit dem Code beschäftigte heute und meine Fehler sah, so denke ich die Lösung für die Struktur gefunden zu haben.

Bsp:

[
   {
      "clientmodule" : "CUL_TCM97001",
      "comment" : "temperature / humidity or other sensors",
      "data" : [
         {
            "RAWMSG" : "MS;P1=-7949;P2=492;P3=-1978;P4=-3970;D=21232423232424242423232323232324242423232323232424;CP=2;SP=1;R=245;O;",
            "state" : "unknown_1"
         },
         {
            "RAWMSG" : "MS;P0=-9298;P1=495;P2=-1980;P3=-4239;D=1012121312131313121313121312121212121212131212131312131212;CP=1;SP=0;R=223;O;m2;",
            "state" : "unknown_2"
         },
         {
            "RAWMSG" : "MS;P0=531;P1=-9027;P3=-4126;P4=-2078;D=0103040304040403030404040404040404040404030303040303040304030304030304040403;CP=0;SP=1;R=249;O;m2;",
            "state" : "unknown_3"
         },
         {
            "RAWMSG" : "MS;P0=-4152;P1=643;P2=-2068;P3=-9066;D=1310121210121212101210101212121212121212121212121010121012121212121012101212;CP=1;SP=3;R=220;O;m2;",
            "state" : "unknown_4"
         },
         {
            "RAWMSG" : "MS;P0=-4149;P2=-9098;P3=628;P4=-2076;D=3230343430343434303430303434343434343434343434343030343030343434343034303434;CP=3;SP=2;R=218;O;m2;",
            "state" : "unknown_5"
         }
      ],
      "id" : "0",
      "name" : "weather (v1)"
   },
   {
      "clientmodule" : "CUL_TCM97001",
      "comment" : "temperature / humidity or other sensors",
      "data" : [
         {
            "RAWMSG" : "MS;P1=416;P2=-9618;P3=-4610;P4=-2036;D=1213141313131313141313141314141414141414141313141314131414;CP=1;SP=2;R=220;O;m0;",
            "state" : "unknown_1"
         },
         {
            "RAWMSG" : "MS;P1=397;P2=-2033;P3=-4627;P4=-9630;D=1413121313131313121313121312121212121212121313121312131212;CP=1;SP=4;R=221;",
            "state" : "unknown_2"
         },
         {
            "RAWMSG" : "MS;P0=-9690;P3=354;P4=-4662;P5=-2107;D=3034343434343535343534343435353535353535353434353535343535;CP=3;SP=0;R=209;O;m2;",
            "state" : "unknown_3"
         },
         {
            "RAWMSG" : "MS;P1=367;P2=-2077;P4=-9415;P5=-4014;D=141515151515151515121512121212121212121212121212121212121212121212;CP=1;SP=4;O;",
            "state" : "unknown_4",
            "user" : "localhosthack0r"
         }
      ],

Als ich von Ralf die Datei einlesen wollte, so stolperte ich über einen nächsten Punkt wo wir Einigkeit finden sollten.

Neben der Bezeichnung

würde ich auch noch folgende Bezeichnungen vorsehen wollen.

Da im ganzen FHEM Programm DMSG und RAWMSG groß gehalten wird, so würde ich dies ebenso groß halten für eine Einheitlichkeit. Wie seht Ihr das? Ohne einen NENNER wird das Programm beim Austausch von Daten sonst nicht vollzähig sein.

Desweiteren bräuchte ich bitte Mithilfe, wie ich aus der Ebene data

[
   {
      "clientmodule" : "CUL_TCM97001",
      "comment" : "temperature / humidity or other sensors",
      "data" : [
         {
            "RAWMSG" : "MS;P1=-7949;P2=492;P3=-1978;P4=-3970;D=21232423232424242423232323232324242423232323232424;CP=2;SP=1;R=245;O;",
            "state" : "unknown_1"
         },
         {

mit Hilfe einer Schleife an RAWMSG und state gelange ohne festen Bezug.

@Ralf9 wärest du mir einem festen DateiNamen SD_ProtocolList.json vereinbar?

sidey79 commented 5 years ago

Hallo @Ralf9 und @sidey79, nachdem ich mich nun mehrfach nochmal mit dem Code beschäftigte heute und meine Fehler sah, so denke ich die Lösung für die Struktur gefunden zu haben.

Die Struktur kommt mir bekannt vor. Sieht gut aus finde ich. Alles was zusammen gehört ist auch zusammen :)

  • comment, DMSG, RAWMSG, user, testdate, state

Wir sollten bei der Schreibweise (groß, klein, camel) bei allen Bezeichnungen gleich bleiben oder glaubst Du DMSG und RAWMSG müssen wir hier groß schreiben damit es mit anderen Stellen nicht kollidiert?

Was den Inhalt angeht: Was genau kommt in state rein? Und auf was exakt bezieht sich testdate? Wie wird der bestimmt.

Desweiteren bräuchte ich bitte Mithilfe, wie ich aus der Ebene data

[
   {
      "clientmodule" : "CUL_TCM97001",
      "comment" : "temperature / humidity or other sensors",
      "data" : [
         {
            "RAWMSG" : "MS;P1=-7949;P2=492;P3=-1978;P4=-3970;D=21232423232424242423232323232324242423232323232424;CP=2;SP=1;R=245;O;",
            "state" : "unknown_1"
         },
         {

mit Hilfe einer Schleife an RAWMSG und state gelange ohne festen Bezug.

Hilft dir dabei nicht mein kleines demoscript ?

https://gist.github.com/sidey79/6b04dc5b7732b49acc75d541cd2b2f09

HomeAutoUser commented 5 years ago

Wir sollten bei der Schreibweise (groß, klein, camel) bei allen Bezeichnungen gleich bleiben oder glaubst Du DMSG und RAWMSG müssen wir hier groß schreiben damit es mit anderen Stellen nicht kollidiert?

Gleich bleiben auf jedenfall! Ich habe nur mal in die Logs geschaut und Zentral im System wie wir oder das System diese immer schreibt.

Ich wies auf das Thema Unterschiede hin weil bei dem Testfile von @Ralf9 mir Bsp: "rmsg" aufgefallen war, wo wir sonst immer rawmsg schreiben.

Eine Kollidierung mit der Scchreibweise sonst im System bzw. der Logfiles sollte es nicht geben.

Was genau kommt in state rein? Und auf was exakt bezieht sich testdate? Wie wird der bestimmt.

Hilft dir dabei nicht mein kleines demoscript ?

Danke :-) 👍 Ich habe mit viel lesen und forschen an Testfiles local es hinbekommen. Die aktuelle Version beinhaltet schon die Änderung.

Ralf9 commented 5 years ago

Ich finde es auch besser, wenn alle Feldnamen klein sind. @sidey79 lässt sich per regex testen ob alle Feldnamen ("name": ) klein sind

Ich habe bei mir die folgenden Felder vorgesehen qw(name id module dmsg user state repeat model comment rmsg);

wärest du mir einem festen DateiNamen SD_ProtocolList.json vereinbar?

SD_Device_ProtocolList.json ist passender. Die json Liste so u.a. zum erfassen von rawmsg von Sensoren und Fernbedienungen verwendet werden. Dazu soll sie nach https://github.com/RFD-FHEM/SIGNALduino_TOOL/tree/master/FHEM/lib gelegt werden. rawmsg von Sensoren und Fernbedienungen werden dann direkt dorthin commited. Das Clientmodul muß nicht erfasst werden, da es beim Einlesen ergänzt werden kann.

@HomeAutoUser mir ist nicht klar wie Du mit Deiner json Liste, das erfassen von rawmsg von Sensoren und Fernbedienungen machen willst?

Ich habe angefangen die brauchbaren rawmsg in die json Liste zu übernehmen. Bei Bedarf kann ich zur Kennzeichnung der unbrauchbaren rawmsg, die ich bis jetzt gefunden habe, einen PR machen.

sidey79 commented 5 years ago
  • In den state kommt Bsp herein "T: 6.3 H: 62" oder "on" bzw "off"

Okay, bei dem state finde ich es immer etwas gruselig, da es state und STATE gibt. Eines von beiden kann mittels stateformat verändert werden. Hauptsache wir nehmen das richtige... welches auch immer das ist.

  • testdate ist ein Punkt wo ich gern automatisch den Testzeitpunkt oder die aktuelle Version der Firmware festhalten möchte weil es geringer maßen auch noch unterschiede bei den Versionen von Dir und @Ralf9 geben kann. (Das sind die Erfahrungen aus dem Forum) Dies soll erleichtern wenn es Unterschiede gibt, den Fehler zu finden bzw. in welcher Firmware wir "sicherstellen" können das es funktionierte. Die Bestimmung habe ich erst als nächstes auf der ToDoListe. Priorität hatte die Struktur, das wir die Datei einlesen können, sowohl Ralfs als auch die ausgelesende von der ProtoCol.pm.

Können wir hier die Namen und auch die Inhalte der entsprechenden internals für Firmwareversion und Modulversion hinterlegen?

sidey79 commented 5 years ago

Ich finde es auch besser, wenn alle Feldnamen klein sind. @sidey79 lässt sich per regex testen ob alle Feldnamen ("name": ) klein sind

Ich glaube nicht. Sollte aber auch nicht nötig sein. "name" ist nicht das gleiche Element wie "NAME" und wenn es nicht in der richtigen Schreibweise hinterlegt wird, dann wird es einfach ignoriert.