Ablage der RAW Daten im Wiki

[Harst]

Hallo,

ja, da brauche ich wirklich Hilfe. Ich bekomme hier zwar die Formatierung hin, im Wiki finde ich abr kein Äquivalent zu <Code></Code>
Hier sind die beiden Seiten, sieht zwar nicht toll aus, könnte aber hilfreich sein.
@HomeAuto_User: Die Seiten sind jetzt frei verfügbar, bitte tobe Dich bei der Formatierung aus. Für Tipps bin ich dankbar.

https://wiki.fhem.de/wiki/Geprüfte_Geräte
https://wiki.fhem.de/wiki/Signalduino_Rawdaten#NC-3911-675

[Harst]

So, jetzt bin ich mit dem Stand zufrieden.

Jetzt kommt der Testbetrieb

Horst

[Ralf9]

Hier sind 2 Sensoren von mir. Ich finde eine Liste in einer Textdatei besser. Die Liste könnte man auch im Github ablegen.

Code Auswählen Erweitern

# ID 0.4, @Ralf9, s248FE4EF0000,  T: -2.8 # Auriol
MS;P0=-3946;P1=448;P2=-1998;P3=-9309;P4=284;D=131212101212101212101212121010101010101012121012121010101210101010124;CP=1;SP=3;e;m3;

# ID 0, @Ralf9, s5410AC5F9800, T: 17.2 H: 47  # GT-WT-02 Temperatur sensor
MS;P1=-4129;P2=550;P3=-2100;P4=-9055;D=2423212321232123232323232123232323212321232121232323212321212121212123232121;CP=2;SP=4;R=241;O;s=4;m1;

Gruß Ralf

[HomeAuto_User]

Wie ist die Variante, das man RAWMSG auf Github in dem Ordner SDTool und der dazugehörigen Datei hinterlegt nach dem dortigen Schema. So sammelt man passend zum Modul und kann ggf Zustände registrieren um dem ,,Bearbeiter" Infos zu liefern.

Somit wäre die Sammlung an einem Ort und kann diese dortigen Informationen auch mit dem Tool verarbeiten auf einfache Weise.

[Harst]

Für mich ist das egal. Ich muss nur wissen, wie und welche Links

[HomeAuto_User]

Hallo Ralf,
ich habe deinen Sensor mal soeben versucht zu dispatchen aber es erfolgt nichts, bei Sidey seiner Version.
Hast du bei dir noch eine Modifikation drin, die vielleicht diesen Sensor zurückhalt bei der Version oder ggf. ne fehlerhafte Nachricht?

Code Auswählen Erweitern

2019.02.17 21:42:46 5: sduino_dummy/msg adding start and endmarker to message
2019.02.17 21:42:46 4: sduino_dummy/msg get raw: MS;P0=-3946;P1=448;P2=-1998;P3=-9309;P4=284;D=131212101212101212101212121010101010101012121012121010101210101010124;CP=1;SP=3;e;m3;
2019.02.17 21:42:46 4: sduino_dummy: Matched MS Protocol id 0.4 -> weather (v5)
2019.02.17 21:42:46 5: sduino_dummy: Starting demodulation at Position 2
2019.02.17 21:42:46 5: sduino_dummy: Found wrong signalpattern, catched 33 bits, aborting demodulation

Mfg

Hier sind 2 Sensoren von mir. Ich finde eine Liste in einer Textdatei besser. Die Liste könnte man auch im Github ablegen.

Code Auswählen Erweitern

# ID 0.4, @Ralf9, s248FE4EF0000,  T: -2.8 # Auriol
MS;P0=-3946;P1=448;P2=-1998;P3=-9309;P4=284;D=131212101212101212101212121010101010101012121012121010101210101010124;CP=1;SP=3;e;m3;
...
Gruß Ralf
[/quote]


[HomeAuto_User]

Für mich ist das egal. Ich muss nur wissen, wie und welche Links

Sobald wir wieder einen aktuellen PR in Github erhalten, so würde ich die bisherigen Dateien dort aktualisieren im SD_Tool Verzeichnis.
Da sind die RAWMSG in den einzelnen Dateien, zu welchen Modul auch sie jeweil gehören.

@Harst, wieviele Water Melder hast du von Atlantic bzw. wieviele von den Vibrationsmeldern? Ich frage aus dem Grund, vielleicht ist mir noch ein Muser aufgefallen wie die beiden sich unterscheiden könnten, aber da wäre es nur hilfreich mindestens von jedem Device 2 Stück, RAWMSG zu erhalten.

MfG

[Harst]

Ich habe jeweils einen. Nur von den Fenstersensoren MD-210R habe ich 2.
Wenn Du keine Unterscheidung hast, wie wäre es mit einer Liste zum selbst auswählen.

[Ralf9]

so würde ich die bisherigen Dateien dort aktualisieren im SD_Tool Verzeichnis

Das SD_Tool Verzeichnis finde ich nicht so gut, dies ist ein protected branch, da sind keine einfachen commits möglich.
Ich würde es besser finden dafür ein eigenes Repository anzulegen mit einem eigenen Team. Wer in die RAWMSG Liste commiten möchte, kann dann dem Team zugefügt werden.

Am liebsten wäre mir eine Liste in einer Textdatei, pro RAWMSG 2 Zeilen

z.B.

Code Auswählen Erweitern

;NAME=Auriol Z31743B; ID=0.4; USER=Ralf9; DMSG=s248FE4EF0000; STATE=T: -2.8; COMMENT=Auriol;
MS;P0=-3946;P1=448;P2=-1998;P3=-9309;P4=284;D=131212101212101212101212121010101010101012121012121010101210101010124;CP=1;SP=3;e;m3;

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

;name=TFA 30.3208.0; id=58; dmsg=W58#45C8142445DB0; user=Ralf9; repeat=2;
MC;LL=-981;LH=964;SL=-480;SH=520;D=002BA37EBDBBA24F0015D1BF5EDDD127800AE8DFAF6EE893C;C=486;L=194;R=34;

;name=WH3080; id=9; dmsg=P9#FA3C1BD4400000CA50051; user=Ralf9; comment=reconstructed bit 1;
MU;P0=2120;P1=-5736;P2=496;P3=-1024;P4=1467;CP=4;R=16;D=0123232323234323434343232323234343434343232343232323234323432343434323434343434343434343434343434343434343434343432323434323432343432343234343434343434343432343234343432;e;

;name=Ventus W044; id=0; dmsg=s8505301CC000;user=Harst; state=T: 20.2 H: 38
MS;P0=-1957;P1=573;P2=-3961;P3=-8913;D=13121010101012101210101010101210121010121210101010101010121212101012121010;CP=1;SP=3;e;m1;

;name=Ventus W132; id=0.3; dmsg=sD66EE1603000; user=dirigent; comment=windGuest: 1.2 winddir:0
MS;P1=492;P2=-4005;P3=-8937;P4=-2023;D=13121214121412121414121214121212141212121414141412141212141414141414141212;CP=1;SP=3;s6;e;m1;

;name=Ventus W132; id=0.3; dmsg=sD6680020C000; user=dirigent; comment=windSpeed: 0.8
MS;P1=492;P2=-4005;P3=-8937;P4=-2023;D=13121214121412121414121214121414141414141414141414141412141414141412121414;CP=1;SP=3;s6;e;m2;

;name=Hama TS33C; id=12; dmsg=P12#7536BA8A82BFC151AB6401; state=T: 18.6 H: 43; user=Ralf9;
MC;LL=-1018;LH=914;SL=-539;SH=436;D=A8E4F45AEDF40AF97595766;C=484;L=91;R=7;


STATE und COMMENT sind optional

Die RAWMSG Infos können dann von einem Modul eingelesen werden und mit "get dummysduino raw ..." ein Parse und dispatch durchgeführt werden.
Die dispatch msg kann dann mit der DMSG verglichen werden.

Gruß Ralf

[Harst]

Ich würde eine dritte Zeile mit den erwarteten Ergebnis einbauen

[HomeAuto_User]

Ist es nicht von Vorteil Harst, wenn wir erstmal die Endlösung finden zwecks Dokumentation. Deine Tabelle wird sehr groß und die RAWMSG Liste wird die reinste Flut auf der Page.

@Ralf, wie wäre die Lösung das Tool auszulagern und dann die Files pflegen?
Alle RAWMSG in eine Datei würde ich verneinen wollen aufgrund des Umfangs.

Eher die Mittellösung 2 Zeilen pro MSG und in die Datei des jeweiligen Modules halte ich für besser.


Gesendet von iPhone mit Tapatalk Pro

[Harst]

Bis die Tabelle der Geräte zu groß wird dauert es noch. Dann können wir sie teilen. Ich finde es wichtig, überhaupt anzufangen.

Die RAW Daten sind da anders. Das ist intern für Entwickler. Riecht eigentlich nach Datenbank oder Excel.

[Ralf9]

In der ersten Zeile ist auch das erwartete Ergebnis enthalten, es lässt sich so recht einfach per split in einen hash einlesen.
Eine Datei hat den Vorteil, das man dann alles in einem Hash hat und bei Bedarf auch alle RAWMSG testen kann. Die Hasheinträge werden dann fortlaufend durchnummerirt.
Man kann dann auch ein array sortiert nach ids und ein array sortiert nach name erstellen

[HomeAuto_User]

Hallo,
was haltet Ihr von dem Vorschlag.

1) Wir lagern die RAWMSG´s in eine Datei aus, welche auf Github liegt. (ähnlich der jetzigen SD_Tool_RAWMSG Dateien im SD_TOOL Ordner)
2) das ganze kommt in ein eigenes Repositorie
3) darin kommt das SD_TOOL für Entwickler zusätzlich
4) die Datei wo die RAWMSG´s hineinkommen wird mit je 3 Zeilen bestimmt
- Kommentarzeile
- Zeile der Modulzuweisung, Zustände (klar vordefiniert mit Trennungszeichen)
- RAWMSG

BSP.:
## Sensor MaxMu Wert 345.6%
SD_MAX_Name;SD_MAX_Modul;345.6%
MU: .....

Somit können wir die Datei in ein hash einlesen weches ich in dem Tool verfügbar habe mit jeweiliger Zuordung Modul....
Da kann man alle RAWMSG hinten ergänzen und als PR jeder einreichen.

Alternativ:

Code Auswählen Erweitern

;name=GT-WT-02; id=0; dmsg=s5410AC5F9800; user=Ralf9; state=T: 17.2 H: 47;
MS;P1=-4129;P2=550;P3=-2100;P4=-9055;D=2423212321232123232323232123232323212321232121232323212321212121212123232121;CP=2;SP=4;R=241;O;s=4;m1;
wobei noch das Modul ergänzt wird und dann die Leerzeichen beim State ersetzt werden automatisch durch _

Code Auswählen Erweitern

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

MfG

[Ralf9]

1) bis  3) sind ok 

und als PR jeder einreichen.

Wer im Team ist, direkt per commit, wer nicht im Team ist per PR

Zu was wird der Eintrag Modul benötigt?

Gruß Ralf

[HomeAuto_User]

1) bis  3) sind ok 
Wer im Team ist, direkt per commit, wer nicht im Team ist per PR

Zu was wird der Eintrag Modul benötigt?

Gruß Ralf

Der Eintrag Modul ist notwendig, das man im Tool direkt nur die Nachrichten bzw. Devices eines speziellen Modules haben möchte. Wenn wir sonst 100te Nachrichten drin haben scrollt man sich zu tode und die Nachrichtenflut ist zu groß. So ist sofort ersichtlich zu welchen Modul das Device kommt und wenn es ums testen von einem Modul geht, weiß man auch sofort was man durchprobieren muss.

Das ganze ohne Modul ist bzw. wird die reinste Datenflut auf einmal.
Der Gedanke, bei neuen Protokollen wo noch kein Modul zugeordnet ist oder keines existiert, das dies in ein unknown geht.

[Harst]

Ich würde noch ein Datum und die Firmware-Version einfügen.
Es gibt bestimmt mal Änderungen in der Firmware, die da relevant sind. Ich erinnere nur an die Probleme mit MS/MU.

Horst

[Ralf9]

Der Eintrag Modul ist notwendig, das man im Tool direkt nur die Nachrichten bzw. Devices eines speziellen Modules haben möchte.

mir ist es egal ob der Eintrag Modul mit reinkommt. Für das Tool ist der Eintrag Modul nicht unbedingt notwendig, über die dmsg lässt sich aus der matchlist das Modul ermitteln, oder einfacher über die ID aus dem Protokoll hash

Das Datum lässt sich auch über die commits ermitteln.

[Sidey]

4) die Datei wo die RAWMSG´s hineinkommen wird mit je 3 Zeilen bestimmt
- Kommentarzeile
- Zeile der Modulzuweisung, Zustände (klar vordefiniert mit Trennungszeichen)
- RAWMSG

Besser wäre es, ein Standard Datenformat zu verwenden. So etwas habe ich noch nie gesehen in dem mehrere Zeilen zu einem Datensatz gehören, es aber keine "Verbindung" dazwischen gibt,
Standardformate wären z.B. CSV, JSON,YAML, XML oder auch ein Perl Modul in dem Variablen definiert sind.
Wieso nehmt ihr nicht so eins. Das ist wohl definiert und kann auch gut verarbeitet werden

In YAML wäre es dann in etwa so glaube ich:

Code Auswählen Erweitern


-
  - name: TFA 30.3208.0
  - id: 58
  - dmsg: W58#45C8142445DB0
  - user: Ralf9
  - repeat: 2
  - rmsg: MC;LL=-981;LH=964;SL=-480;SH=520;D=002BA37EBDBBA24F0015D1BF5EDDD127800AE8DFAF6EE893C;C=486;L=194;R=34;



[HomeAuto_User]

Hallo,
ich bin soeben dran eine Möglichkeit in unser TOOL zu bauen, wo wir die Dokumentation integrieren können.

- Wir werden ein JSON File erstellen können was uns erstmalig alle Notizen aus der geführten SD_ProtocolList.pm liest. Diese werden in einer Datei JSON gespeichert.
- Diese kann man ändern und dann rücklesen.

Ein Wille ist, dann im TOOL das Modul auszuwählen und alle verfügbaren RAWMSG + Zustände dann dort sofort zur Auswahl zu haben.

Code Auswählen Erweitern

{
   "0" : {
      "clientmodule" : "CUL_TCM97001",
      "comment" : "temperature / humidity or other sensors",
      "name" : "weather (v1)",
      "raw01" : "MS;P1=-7949;P2=492;P3=-1978;P4=-3970;D=21232423232424242423232323232324242423232323232424;CP=2;SP=1;R=245;O;",
      "raw01comment" : "-",
      "raw02" : "MS;P0=-9298;P1=495;P2=-1980;P3=-4239;D=1012121312131313121313121312121212121212131212131312131212;CP=1;SP=0;R=223;O;m2;",
      "raw02comment" : "-",
      "raw03" : "MS;P0=531;P1=-9027;P3=-4126;P4=-2078;D=0103040304040403030404040404040404040404030303040303040304030304030304040403;CP=0;SP=1;R=249;O;m2;",
      "raw03comment" : "-",
      "raw04" : "MS;P0=-4152;P1=643;P2=-2068;P3=-9066;D=1310121210121212101210101212121212121212121212121010121012121212121012101212;CP=1;SP=3;R=220;O;m2;",
      "raw04comment" : "-",
      "raw05" : "MS;P0=-4149;P2=-9098;P3=628;P4=-2076;D=3230343430343434303430303434343434343434343434343030343030343434343034303434;CP=3;SP=2;R=218;O;m2;",
      "raw05comment" : "-"
   },
   "0.1" : {
      "clientmodule" : "CUL_TCM97001",
      "comment" : "temperature / humidity or other sensors",
      "name" : "weather (v2)",
      "raw01" : "MS;P1=416;P2=-9618;P3=-4610;P4=-2036;D=1213141313131313141313141314141414141414141313141314131414;CP=1;SP=2;R=220;O;m0;",
      "raw01comment" : "-",
      "raw02" : "MS;P1=397;P2=-2033;P3=-4627;P4=-9630;D=1413121313131313121313121312121212121212121313121312131212;CP=1;SP=4;R=221;",
      "raw02comment" : "-",
      "raw03" : "MS;P0=-9690;P3=354;P4=-4662;P5=-2107;D=3034343434343535343534343435353535353535353434353535343535;CP=3;SP=0;R=209;O;m2;",
      "raw03comment" : "-",
      "raw04" : "MS;P1=367;P2=-2077;P4=-9415;P5=-4014;D=141515151515151515121512121212121212121212121212121212121212121212;CP=1;SP=4;O;",
      "raw04comment" : "-"
   },
...

Welche Punkte sehr Ihr als notwendig zum erfassen? Als Sinnvoll würde ich noch die dmsg eränzen.
Von einer Version, mit welcher es getestet wurde, würde ich fast absehen um den User zu "zwingen" sich zu Wort zu melden wenn etwas nicht funktioniert.

@Harst, wäre eine solche Umsetzung auch in deinem Sinne?

[Ralf9]

Ich sehe keine Notwendigkeit ein Standard Datenformat zu nehmen.
Die Werte werden von Hand in eine Textdatei eingegeben und wenn die Daten vom Tool zeilenweile eingelesen werden, ist das  Datenformat egal.
Beim Zeilenweise einlesen kann dann auch gleich eine Syntaxprüfung erfolgen.

Die folgenden Felder sollten eigentlich ausreichend sein.
my @rawmsg_fields  = qw(name id module dmsg user state repeat model comment);
Das Feld module muss nicht eingegeben werden, da es beim Einlesen über die ID vom Protokollhash geholt wird.

Code Auswählen Erweitern

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

;name=Ventus W044; id=0; dmsg=s8505301CC000; user=Harst; state=T: 20.2 H: 38;
MS;P0=-1957;P1=573;P2=-3961;P3=-8913;D=13121010101012101210101010101210121010121210101010101010121212101012121010;CP=1;SP=3;e;m1;

;name=Ventus W132; id=0.3; dmsg=sD66EE1603000; user=dirigent; comment=windGuest: 1.2 winddir:0;
MS;P1=492;P2=-4005;P3=-8937;P4=-2023;D=13121214121412121414121214121212141212121414141412141212141414141414141212;CP=1;SP=3;s6;e;m1;

Wenn pro Eintrag mehrere msg eingegeben werden sollen, kann dies über eine fortlaufende Nr am Anfang gemacht werden. z.B.

Code Auswählen Erweitern

;name=Manax_MX_RCS270; id=90; dmsg=P90#7B1D08650; state=...; user=..; comment=Taste_ALL_Aus;
MS;P0=-10253;P1=284;P2=-860;P3=811;P4=-343;D=10123434343412343412121234343412341212121234121212123434121234123412;CP=1;SP=0;R=41;O;m2;
;1; dmsg=P90#7B1D046D0; state=...; comment=Taste_ALL_Ein;
MS;P1=274;P2=-882;P3=810;P4=-334;P6=-10279;D=16123434343412343412121234343412341212121212341212123434123434123412;CP=1;SP=6;R=46;O;m2;
;2; dmsg=P90#...; state=...; comment=Taste_A_Aus;
MS;P1=-345;P2=801;...;
;3; dmsg=P90#...; state=...; comment=Taste_A_Ein;
MS;P1=...

Ich habe bei mir die 88_SIGNALduino_TOOL.pm so angepasst, daß damit die Textdatei eingelesen werden kann, nach dem Einlesen mit get werden diese in einer Übersicht angezeigt (siehe Anlage)

Ich habe in der Matchlist den folgenden Eintrag zugefügt:

Code Auswählen Erweitern

"90:SIGNALduino_TOOL" => '^pt([0-9]+(\.[0-9])?)(#.*)?',
Wenn dann beim dummysduino ein get raw gemacht wird, z.B.
get raw pt10
wird pt10 per dispatch an das SIGNALduino_TOOL übergeben, dort wird dann in der parse routine in dem rawmsg Hash die rawmsg der ID 10 geholt und per CallFn im dummysduino mit der rawmsg ein get raw gemacht.
Im  Tool gibt es per Attribut die Möglichkeit auszuwählen ob die aus der rawmsg demodulierte dmsg per dispatch dem Tool übergeben wird.
Im Tool kann dann in der Parseroutine die übergebene dmsg mit der im rawmsg hash verglichen werden.

Code Auswählen Erweitern

2019.03.09 22:53:53.966 4 : sduinoD/msg get dispatch: pt12
2019.03.09 22:53:53.993 3 : sd_tool SD_TOOL_Parse: id=12 nr=9
2019.03.09 22:53:53.993 3 : sd_tool SD_TOOL_Parse: name=Hama TS33C id=12 module=hideki dmsg=P12#7536BA8A82BFC151AB6401 user=Ralf9 state=T: 18.6 H: 43
2019.03.09 22:53:53.994 3 : sd_tool get raw: MC;LL=-1018;LH=914;SL=-539;SH=436;D=A8E4F45AEDF40AF97595766;C=484;L=91;R=7;
2019.03.09 22:53:53.994 4 : sduinoD/msg get raw: MC;LL=-1018;LH=914;SL=-539;SH=436;D=A8E4F45AEDF40AF97595766;C=484;L=91;R=7;
2019.03.09 22:53:53.994 4 : sduinoD: Found manchester Protocol id 12 clock 484 RSSI -70.5 -> Hideki
2019.03.09 22:53:53.994 4 : sduinoD: hideki protocol converted to hex: 7536BA8A82BFC151AB6401 with 91 bits, messagestart 1
2019.03.09 22:53:53.994 4 : sduinoD Dispatch: pt0#9#P12#7536BA8A82BFC151AB6401, -70.5 dB, dispatch
2019.03.09 22:53:53.994 3 : sd_tool SD_TOOL_Parse: nr=9 parseDmsg=P12#7536BA8A82BFC151AB6401
2019.03.09 22:53:53.994 3 : sd_tool SD_TOOL_Parse: nr=9 expecDmsg=P12#7536BA8A82BFC151AB6401 is equal

Damit ist es dann z.B. möglich für alle Einträge in der Liste oder nur für die IDs die in der  whitelist des dummysduino stehen automatisch mit den rawmsg ein get raw zu machen und die dmsg ans Tool zu übergeben und dort mit dem rawmsg hash zu vergleichen.

Gruß Ralf

[Sidey]

Ich sehe keine Notwendigkeit ein Standard Datenformat zu nehmen.
Die Werte werden von Hand in eine Textdatei eingegeben und wenn die Daten vom Tool zeilenweile eingelesen werden, ist das  Datenformat egal.

Das Datenformat muss doch zur Einleseroutine passen. Es kann also nicht egal sein.

Ich sehe drei Vorteile

1:
Gerade wenn von Hand etwas eingegeben wird, erhält man mit gängigen Formaten und einem Editor auch noch eine Syntaxprüfung.

2: Das Format muss demjenigen, der Daten hinterlegt bekannt sein.


3: Es gibt für etliche Programmiersprachen Bibliotheken, welche bekannte Formate verarbeiten können.

Was sind die Vorteile ein eigenes Format zu erfinden das niemandem bekannt ist?

Grüße Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

[Ralf9]

Gerade wenn von Hand etwas eingegeben wird, erhält man mit gängigen Formaten und einem Editor auch noch eine Syntaxprüfung.

ok, das json Format hat im Editor durch die Syntaxprüfung und unterschiedliche Farben vorteile.
Es dürfte auch egal sein ob alles in eine Zeile geschrieben wird oder auf mehrere Zeile verteilt wird.

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",
}

Ist da beim Einlesen auch eine Syntaxprüfung möglich, z.B. die Felder mit einer Liste oder hash

Code Auswählen Erweitern

my @rawmsg_fields  = qw(name id module dmsg user state repeat model comment);
vergleichen ob sie richtig geschrieben sind?

Beim Einlesen in einen hash soll dann ein key mit einer fortlaufender Nr zugefügt werden.
Der key mit der fortlaufenden Nr ist in json unpraktisch, da auch Einträge eingefügt werden sollen.
Der hash sieht dann so aus:

Code Auswählen Erweitern


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


Im Texteditor gibt es eine Syntaxprüfung mit unterschiedlichen Farben im Git gibt es aber keine farbliche Unterscheidung (siehe Anlagen)


Gruß Ralf

[HomeAuto_User]

Hallo,

ich schaue mir es mal parallel an Ralf.
Gern würde ich aber bei dem Schema bleiben, das Zusätzliche RAW´s immer dem Modul zugeordnen werden. Der Hintergrund ist einfach, das wir bei unserer Schematik ProtokollDatei bleiben und auch so die Auswertung im Tool sofort einfacher funktioniert.

Der jetzige Stand des Tools, ist soweit, das wir die Nachrichten oder Kommentare setzen können über das Tool.
Ich denke wir sind auf einem guten Weg und können unsere Ideen zusammenführen bzw. einen Mittelweg finden.

Dateistruktur, ein passendes vorhandenes Dateiformat sehe ich besser, denn auch eine Textdatei welche man nutzen würde, MUSS nach einem bestimmten Schema verlaufen um diese auch richtig zu prüfen / einzulesen.

Wäre es nicht besser, wenn wir die Überarbeitung des Codes in Github umsetzen?

Grüße Marco

[Sidey]

Ja, soll ich denn ein Repo anlegen?
Welchen Namen soll es erhalten?

Grüße Sidey

[HomeAuto_User]

Ja, soll ich denn ein Repo anlegen?
Welchen Namen soll es erhalten?

Grüße Sidey

Das wäre sehr gut!
Namensvorschlag: SIGNALduino_TOOL
Beschreibung: TOOL environment for SIGNALduino

Die Beschreibung können wir ja noch anpassen je nach Umfang und Optionen welche es kann und hinzukommen.

Können wir da mit einem Rutsch das SD_TOOL Verzeichnis verschieben oder muss ich das erst hinein bringen mit einem PR um das jetzige zu löschen in dem Repro?

[Ralf9]

Ich habe mir das mit dem JSON Format angeschaut, das Einlesen mit Syntaxprüfung funktioniert damit auch.
Was mir noch nicht so ganz gefällt, daß es im github bei JSON keine unterschiedliche Farben gibt, oder habe ich da was übersehen.

Wenn beim zeilenweise einlesen von "{" bis "}" jeweils in einen $json String kopiert wird, dann kann auch gleich eine Syntaxprüfung gemacht werden

Im Prinzip ungefähr so:

Code Auswählen Erweitern

$nr++;
my $decoded = decode_json($json);
foreach $field (keys %{$decoded}) {
if (!exists($rawmsg_fields_hash{$field})) {
Log3 $name,3,"$name rawlist: json=$json";
Log3 $name,3,"$name rawlist: field=$field not found";
}
else {
$rawmsg{$nr}{$field} = $decoded->{$field};
}
}

Ist es möglich für das Repo ein eigenes Team zu machen?
Jeder der häufiger Daten in die rawmsg Liste eintragen möchte oder helfen möchte, kann dann ins Team.
In die rawmsg Liste sollten direkte commits die Regel und PR nur die Ausnahme sein.

Nachtrag: die rawmsg Liste sollte als Endung json haben, dann kapiert der Editor sofort, daß es json ist.

Nachtrag2: die Einträge können über das Feld module dem Modul zugeordnet werden.

Gruß Ralf

[HomeAuto_User]

Ist es möglich für das Repo ein eigenes Team zu machen?

Nachtrag: die rawmsg Liste sollte als Endung json haben, dann kapiert der Editor sofort, daß es json ist.

Nachtrag2: die Einträge können über das Feld module dem Modul zugeordnet werden.

Gruß Ralf

Mit dem TEam sollte machbar sein.

rawmsg Liste, diese soll in die Datei SD_ProtocolList.json. Darin soll alles und nicht extra wieder eine Datei anfangen bitte. So habe ich es ja auch jetzt schon in der Dateiendeung.

[HomeAuto_User]

@Ralf9,

da deine Vorschläge und Ideen sehr hilfreich sind, wo können wir doch gern an einer gemeinsamen Version arbeiten.
So finden wir den Nenner um den anderen Usern eine Basis zu schaffen um letztendlich uns zu unterstützen.

Das separate Repro in Github wurde geschaffen.

MfG

[Ralf9]

Als ersten Schritt sollten wir uns darauf einigen wie die json Liste aussehen soll.

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

[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.

[HomeAuto_User]

Nachdem ich mal begonnen habe die Struktur zu überarbeiten kämen nun diese Daten heraus:

Code Auswählen Erweitern

{
   "1" : {
      "clientmodule" : "CUL_TCM97001",
      "dmsg" : "-",
      "id" : "0",
      "name" : "generic",
      "protocol_info" : "x",
      "raw" : "MS;P1=-7949;P2=492;P3=-1978;P4=-3970;D=21232423232424242423232323232324242423232323232424;CP=2;SP=1;R=245;O;",
      "state" : "no info",
      "user" : "unknown"
   },
   "10" : {
      "clientmodule" : "CUL_TCM97001",
      "dmsg" : "-",
      "id" : "0.2",
      "name" : "generic",
      "protocol_info" : "x",
      "raw" : "MS;P1=-2140;P2=309;P3=-4690;P4=-9695;D=2421232323232121232123232321212121212121212123212121232121;CP=2;SP=4;R=211;m1;",
      "state" : "no info",
      "user" : "unknown"
   },
   "100" : {
....

Die Zahlen / Schlüssel 1 und 10 sind fortlaufende Nummern vom einlesen.

Ist es machbar, das JSON geordnet zu schreiben von 0 .... 9 / 10 / 11 ... fortlaufend und nicht die Sortierreihenfolge 1 10 11  ...?
Es ist natürlich nur "Schönheit aber ich würde das letzte immern hinten dran haben wollen mit der fortlaufenden Nummer.

Code Auswählen Erweitern

"protocol_info" : "x",
ist nur eine Bemerkung, das diese Daten aus der SD_ProtocolData stammen. Ein passender Name fiel mir noch nicht ein.

Der Screenshot ist nur von den Informationen aus der SD_ProtocolData Datei. Dort sollen dann eure Infos dran.
Sortierung, da sollten wir überlegen was Sinnvoll ist. Da ich über alle Module blicke, so wäre eine Sortierung Modul -> Sensor vielleicht sinnvoll.

MfG

[Sidey]

Wenn Du die Nummern aus dem JSON raus lässt und eine einfache Liste verwendest, dann hast Du auch das Problem mit dem sortieren nicht.
Ich meine das, was Du mir 1..100 im Beispiel angegeben hast.

[HomeAuto_User]

Wenn Du die Nummern aus dem JSON raus lässt und eine einfache Liste verwendest, dann hast Du auch das Problem mit dem sortieren nicht.
Ich meine das, was Du mir 1..100 im Beispiel angegeben hast.

wie mache ich es denn als Liste? Ich habe mir zwar dies angesehen aber anscheind wurde ich da nicht schlau genug draus.
Der IstCode ist im Git ggf zum nachsehen.

Ich ging davon aus, so wie ich es jetzt eintrage kommt das selbige als Liste heraus NUR das es eben umgebrochen ist 

EDIT: Ich denke, wenn ich die Zahl weglasse, würde ich mir Einträge überschreiben sobald eine weiterer gleicher Eintrag kommt.

Bsp: Selbige id aber andere RAWMsG

[Sidey]

wie mache ich es denn als Liste? Ich habe mir zwar dies angesehen aber anscheind wurde ich da nicht schlau genug draus.
Der IstCode ist im Git ggf zum nachsehen.

Hier das Beispiel wie ich es meinte:

https://jsoneditoronline.org/?id=567c4641a8e6472f98be9d97ff6e6a5f

Ich ging davon aus, so wie ich es jetzt eintrage kommt das selbige als Liste heraus NUR das es eben umgebrochen ist 

Das sind Objekte, Du hast ein Objekt 1 und ein weitere Objekt 10 definiert.

EDIT: Ich denke, wenn ich die Zahl weglasse, würde ich mir Einträge überschreiben sobald eine weiterer gleicher Eintrag kommt.

Nein, das passiert nicht, da es eine Liste (Array) ist.

[HomeAuto_User]

@Ralf,
da ich sehe du nimmst Anpassungen für das Tool vor, möchten wir denn nich versuchen unsere Ideen zusammenzubringen?
Ich sehe sonst Differenzen wenn es 2 Wege einschlägt, da es für das SVN Update bzw. via Github downloaf update verteilt werden kann / soll.

Ein jetziger Stand ist soweit, das unsere Datei eingelesen wird und wir sehen was für Nachrichten zur Verfügung stehen.
Da würde ich ansetzen wollen. Zur besseren Veranschaulichung habe ich 2 Funktionen eingebunden und auch eine Option die JSON Datei vorerst zu löschen. (macht sich zum testen einfacher)

Die Übergabe an die Setliste realisiere ich soeben.

Überlegung:
- entweder wir lassen anstatt der "langen Texte" nur die Kommentare der Protokoll ID dort einlesen, weil einzelene Sensoren ja eh kürzere Namen haben
- auf klick der der Nachricht, diese dann an das Dummydevice weiterzugeben

@harst, kommen dir noch Ideen zur Umsetzung?

[Ralf9]

Hier ist eine Liste im json Format von RAWMSG und weiteren Daten von Sensoren und Fernbedienungen.

https://github.com/RFD-FHEM/SIGNALduino_TOOL/blob/master/FHEM/lib/SD_Device_ProtocolList.json

https://github.com/RFD-FHEM/SIGNALduino_TOOL/commit/7952c8abcb68e76b2e8647da8d7ef71d4f396a44


Gruß Ralf

[HomeAuto_User]

Hallo, weiß jemand mit wieviel MB wir Github belasten können?

Ich denke an die von Horst seine BilderDoku. Mir ging durch den Kopf, das man neue SensorenBilder hochlädt, Horst sie verarbeiten kann und wir diese dann wieder löschen ?


Gesendet von iPhone mit Tapatalk Pro

[Harst]

Ich würde sagen: GitHub löscht nicht

Horst