Viele falsche RMSG

[sidey79]

@HomeAutoUser

Wenn wir die Prüfung der RMSGs wie in RFD-FHEM/RFFHEM#926 angedacht machen, dann sind ganz viele rmsgs im JSON ungültig.

Z.B. diese hier:

SIGNALduino_TOOL/FHEM/lib/SD_Device_ProtocolList.json

Line 18 in 67013e9

"rmsg":"MS;P1=-4129;P2=550;P3=-2100;P4=-9055;D=2423212321232123232323232123232323212321232121232323212321212121212123232121;CP=2;SP=4;R=241;O;s=4;m1;"

Das s4 wird in der Firmware nicht gesetzt. Ich kann mich da auch an nichts erinnern.

Bei MUs ist ein e drinnen, das ist mir auch unbekannt:

SIGNALduino_TOOL/FHEM/lib/SD_Device_ProtocolList.json

Line 271 in 67013e9

"rmsg":"MU;P0=-10108;P1=495;P2=-1050;P3=1496;P4=-27564;P5=372;CP=1;R=245;D=012121212121212321212123232121212121212323232123212321232123212323232323232123232123232121212123212323232323232121212121232323450;e;"

Insgesamt sind es 35 ungültige MS Nachrichten und und 15 MU (prerelase und master zusammen gerechnet).

[HomeAutoUser]

@sidey79 die Differenzen sind von den beiden Firmwareversionen. Ich werde versuchen mir es anzusehen.

Was oder wie lässt du den Test ablaufen das er die RAWMSG als nicht plausibel aussonderst ? Durch ein RegEx?

edit: RFD-FHEM/RFFHEM#926 ja, es prüft durch ein RegEx und da fällt die andere Version durch. Alle RAWMsg die gepostet werden von den Usern mit der inoffiziellen Version werden es sein.

[sidey79]

Vermutlich kommt es davon ja.
Die regex sind die, welche wir ja entwickelt hatten.
Ist halt die Frage, wie streng die Prüfung sein soll.
Wir könnten am Ende ja alle möglichen Zeichen erlauben, denn das im Blick halten was alles vorkommen kann finde ich nicht so prickelnd.
Die Prüfung deaktivierbar machen halte ich auch für keine alltags taugliche Lösung.

[elektron-bbs]

Die Tests sollten doch wohl nicht strenger sein wie ein funktionierendes FHEM. Solange zusätzliche Variablen in den Nachrichten die Weiterverarbeitung im laufenden FHEM nicht stören, sollten sich auch die Tests nicht daran stören.
Oder willst du zukünftig Nachrichten vom MapleSduino generell ausschließen?

[sidey79]

@elektron-bbs

Den Ursprung nahm die Sache ja, dass die Prüfung auf valide Daten zu schwach ist und es zu warnings kommt.
Dann hatte @HomeAutoUser die Idee, dass mittels einer Regex zu prüfen und was nicht passt wird erst gar nicht angerührt.
Jetzt haben wir Tests mit Fehlerhaften Daten und eine Regex die sich an dem Datenformat aus https://github.com/RFD-FHEM/SIGNALDuino orientiert. Andere Datenformate kenne ich erst mal nicht und wüsste auch nicht, wie die zu interpretieren wären. Aufgefallen ist es halt dadurch, dass im json wohl Daten stammen nicht nicht mit der Firmware aus https://github.com/RFD-FHEM/SIGNALDuino stammen.
In wie weit das nun Auswirkungen auf FHEM hat oder nicht, dazu kann ich überhaupt keine Aussage treffen.

Ich weiss auch selbst nicht was ich will.
Wenn wir die Regexprüfung weglassen, riskieren wir wieder "Müll" zu verarbeiten und es kommt zu warnings
Wenn wir unbekanntes in der regex erlauben wollen, wüsste ich gerade nicht wie, da ich noch nicht mal die Positionierung innerhalb des Datenstrings kenne.
Irgendwie eine Zwickmühle.

[elektron-bbs]

Ich würde nur prüfen, was wir benötigen und zusätzliche Variablen, sofern sie nicht den Ablauf stören, einfach ignorieren.

[sidey79]

@elektron-bbs

Verstehe ich Recht, dass Du auf eine Regex Prüfung verzichten würdest, welche die Bestandteile der rmsg auf valide Werte prüft?

[elektron-bbs]

Natürlich nicht komplett auf die Prüfung verzichten, sondern auf relevante Bestandteile beschränken.
Z.B. stören doch diese Bestandteile "O;s=4;m1;" die weitere Verarbeitung in FHEM nicht. Also muss auch der Test diese nicht bemängeln.

[sidey79]

m1 ist ja bekannt
O ist ebenfalls bekannt

s=4 ist ein unbekannter Wert.

Ich habe im Moment folgende Regex:
^MS;(?:P[0-7]=-?\d+;){3,8}D=[0-7]+;CP=[0-9];SP=[0-9];(?:R=\d+;)?(?:O;)?(?:m=?[0-9];)?$

Ich hab schon mal versucht mittels oder groups auch unbekanntes zu erlauben, das klappte bislang noch nicht:
^MS;(?:P[0-7]=-?\d+;){3,8}D=[0-7]+;CP=[0-9];SP=[0-9];((?:R=\d+;)?|(?:O;)?|(?:m=?[0-9];)?|(?:[A-Za-z0-9]+;)+)$

Das ist ja nun quasi das Problem, etwas erlauben das unbekannt ist, aber in den bekannten Feldern auch nur valides zulassen.

[sidey79]

So scheint es auf den 1. Blick zu klappen. Ganz wohl ist mir dabei nicht gerade ;)

^MS;(?:P[0-7]=-?\d+;){3,8}D=[0-7]+;CP=[0-9];SP=[0-9];((?:R=\d+;)?|(?:O;)?|(?:m=?[0-9];)?|(?:[A-Za-z0-9=]+;)*)$

[elektron-bbs]

Bei CP= und SP= müsste auch [0-7] reichen.

[sidey79]

@elektron-bbs
@HomeAutoUser

Ich habe die regex angepasst:

RFD-FHEM/RFFHEM@5023de8

passt noch nicht 100% aber es wird

[sidey79]

@HomeAutoUser
@elektron-bbs

Ich hab nun genau den Fall, den ich nicht gefixt bekomme:

https://regex101.com/r/oQBkKv/1

Mach ich es zu streng, sind beide nicht erlaubt, mache ich es zu lose, dann werden beide verarbeitet, obwohl das ja dann nicht korrekt ist.