Ablage der RAW Daten im Wiki

Begonnen von Harst, 04 Februar 2019, 23:28:21

Vorheriges Thema - Nächstes Thema

HomeAuto_User

Zitat von: Ralf9 am 27 Februar 2019, 19:38:50
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.
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

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

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

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Sidey

#18
Zitat von: HomeAuto_User am 27 Februar 2019, 18:18:44
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:

-
  - 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;




Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

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.

{
   "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?
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

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.

;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.
;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:
"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.

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




FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Sidey



Zitat von: Ralf9 am 10 März 2019, 01:47:31
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

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Ralf9

ZitatGerade 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.
{"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
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:


"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
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

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
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

Sidey

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

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

HomeAuto_User

Zitat von: Sidey am 10 März 2019, 16:56:08
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?
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

Ralf9

#26
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:
$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
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

HomeAuto_User

Zitat von: Ralf9 am 10 März 2019, 17:15:39
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.
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

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
"Developer" heißt nicht, das man alles wissen kann!
- FHEM v5.9 | Rasberry PI 3
- radino CC1101 433Mhz (SIGNALduino)| - radino CC1101 868Mhz (CUL) | nano 433Mhz (SIGNALduino) - Sensoren: purer Dschungel querbeet

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?
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7