Fehler bei MS-Erkennung #102

elektron-bbs · 2018-11-25T10:29:19Z

Ich betreibe 3 Sensoren vom Typ "Conrad S522". Bisher funktionierten diese problemlos. Heute habe ich bemerkt, das alle 3 Sensoren seit gestern Mittag nicht mehr empfangen werden. Auf einem 2. System funktioniert der Empfang allerdings noch.
Also auf dem gestörten System "verbose" auf 4 und die Logs angesehen. Die Nachrichten werden noch empfangen, aber nicht ausgewertet:

2018.11.25 10:52:45 4: sduino434/msg READredu: MS;P1=-8052;P2=505;P3=-2027;P4=-3972;D=21232324242424242323242323232423242424232424232324232423232323232323232323232323242424;C=??;SP=2;R=1;O;m2;
2018.11.25 10:52:45 4: sduino434/msg READredu: MS;P1=-8030;P2=504;P3=-2027;P4=-3984;D=21232324242424242323242323232423242424232424232324232423232323232323232323232323242424;C=??;SP=2;R=1;O;m1;
2018.11.25 10:52:45 4: sduino434/msg READredu: MS;P1=-8047;P2=504;P3=-2029;P4=-3981;D=21232324242424242323242323232423242424232424232324232423232323232323232323232323242424;C=??;SP=2;R=1;O;m0;

Ein "set reset" des SIGNALduino hat nichts gebracht. Erst ein Hard-Reset durch Abschaltung führte wieder zm Empfang der 3 Sensoren. Im Log eines Sensors erscheinen jetzt wieder die RAWMSG wie folgend:

2018-11-25_11:12:56 SD_WS_33_T_1 RAWMSG: MS;P1=-8043;P2=502;P3=-2039;P4=-3996;D=21232324232324232423242323232324232424242424242324232423232323232323232323232324232423;CP=2;SP=1;R=41;O;m2;

Ich vermute, das die Aussetzer an dieser Ausgabe liegen: C=??

Die Firmware-Version ist: V 3.3.1-RC9 SIGNALduino cc1101 - compiled at Nov 14 2018 23:01:23

Anbei noch das komplette Log:
fhem_2018-11-25.log

The text was updated successfully, but these errors were encountered:

sidey79 · 2018-11-25T12:17:03Z

Das ist ja sehr dubios.

sidey79 · 2018-11-25T20:03:29Z

Das ist die Stelle im Code. Da ist eigentlich nichts ungewöhnliches zu finden.

https://github.com/RFD-
FHEM/SIGNALDuino/blob/8f76d7130c9cf393067b8381ae63d2bcf479180b/src/_micro-api/libraries/signalDecoder/src/signalDecoder.cpp#L468

HomeAutoUser · 2019-01-07T17:22:10Z

Hallo @sidey79, keine Ahnung ob du die Entwicklung von den Atlantic und Focus Security China Devices https://forum.fhem.de/index.php/topic,95346.0.html mitbekommen hast. (oder beginnend ab hier: https://forum.fhem.de/index.php/topic,58397.msg876097.html#msg876097 und folgende.

Da haben wir wieder das Problem, das MU und MS Nachrichten von einem Device gemischt werden.
@elektron-bbs und ich sind der Meinung, das dies immer MU Nachrichten sein müssten.
Die Erkennung von MS ist Fehlerhaft noch. In diesem Falle wird immer der letzte Puls von der Nachricht der neuen als erstes zugeordnet und somit ist der erste eigendlich der letzte der vorherigen Nachricht.

Mit einer guten MU Nachricht siehst du wie dies sein müsste:

2019.01.06 10:53:21 MU;P0=-26924;P1=369;P2=-823;P3=-430;P4=762;P5=-3924;D=
01
212121212121343421213434343434213421212121212134343434212121343421342134
51
212121212121343421213434343434213421212121212134343434212121343421342134
51
212121212121343421213434343434213421212121212134343434212121343421342134
51
21212121212134342121343434343;CP=1;R=0;O;

angebliche MS Nachricht welche nur eine Wiederholung aus der langen Nachricht ist.
2019.01.06 10:53:59 MS;P1=-419;P2=380;P3=-810;P5=767;P6=-3912;D=26232323232323215153232151515151532153232323232321532151515323215151515323;CP=2;SP=6;R=0;m2;

Da wir bei diesen Devices eine XOR Checksumme bilden kommt es auf das letzte Bit drauf an.
@Ralf9 hatte die Idee ein paddingbit in die Definition einzubauen und das immer auf 1 zu setzen. https://forum.fhem.de/index.php/topic,95346.msg881896.html#msg881896
Letztendlich ist es ein Workaround welcher unser Problem mit der Erkennung nicht grundlegend behebt und die Richtigkeit nur bedingt gegeben ist.

Da die richtige Verarbeitung für die Auswerung des Modules ist, so möchte ich diese Problematik erneut ansprechen weil ich gern das Modul SD_UT updaten würde und zusätzlich ich der Meinung bin, solche Problematiken bzw. Bug haben eine hörere Priorität als unsere Schalter ;-) Schließlich tragen wir diese immer wiederkehrende Problematik mit uns schon lange mit. Ist eine Behebung möglich oder mit diesem Workaround panndingbit leben?

MfG

Ralf9 · 2019-01-07T18:51:24Z

@Ralf9 hatte die Idee ein paddingbit in die Definition einzubauen und das immer auf 1 zu setzen.
Letztendlich ist es ein Workaround welcher unser Problem mit der Erkennung nicht grundlegend behebt und die Richtigkeit nur bedingt gegeben ist.

Ich habe kein Fall gefunden bei dem das mit dem auffüllen per padding nicht richtig funktioniert.
Es sind bis jetzt nur sehr wenig Protokolle bekannt bei denen MU und MS Nachrichten von einem Device gemischt werden.

Es gibt 2 Fälle:
Hier wird als MS erkannt, wenn das letzte Bit 0 ist.
Das fehlende Bit 0 wird durch das padding ergänzt

	zero			=> [-x,1],
	one			=> [-x,2],
	start			=> [-sync,1],

Hier wird als MS erkannt, wenn das letzte Bit 1 ist.
Das fehlende Bit 1 wird durch das padding ergänzt.
Damit das ergänzen mit 1 hier funktioniert, ist eine neue Definition paddingbit => 1 notwendig

	one			=> [-x,1],
	zero			=> [-x,2],
	start			=> [-sync,1],

sidey79 · 2019-01-07T22:07:39Z

@HomeAutoUser
Auf Anhieb fällt mir nicht ein wie wie MS Erkennung hier verhindern könnten. Wir könnten stärker auf den CP prüfen, aber das würde auch einige Protokolle von der MS Erkennung ausschließen, die heute als MS erkannt werden.

HomeAutoUser · 2019-01-07T23:05:52Z

@sidey79 die Problematik ist ja auch nicht leicht zu lösen. Ich entnehme der Aussage wir betrachten das ganze als erledigt oder vertagen wir es? ;-)

Wie denkst du über die Lösung von Ralf mit dem paddingbit? Wäre es akzeptabel von deiner Seite so oder hast du dafür eine andere Lösung bzw. Umsetzungsvorstellung? Ich möchte einfach nur verhindern, etwas nun einzubauen und dann nehmen wir es wieder raus bzw. wird von vornherein abgelehnt.

HomeAutoUser · 2019-01-11T22:15:37Z

@sidey79 im Beitrag #102 (comment) hatte ich die Anfrage gestellt ob die von @Ralf9 ´s Lösung für dich in Ordnung geht oder ob du auf eine andere Variante zurück greifen würdest? Das steht noch auf meiner ToDo, da es ja zur Erkennung der Atlantic Security Sensoren wichtig ist.

sidey79 · 2019-01-11T22:40:13Z

@HomeAutoUser
Wir haben bereits

# paddingbits => ' '       # pad up to x bits before call module, default is 4.
# paddingbits => '1'       # will disable padding, use this setting when using dispatchBin
# paddingbits => '2'       # is padded to an even number, that is a maximum of 1 bit

Mit paddingbit =1 wird dann eine 1 angehangen und paddingbit =0 (default) hängt eine 0 in Abhängigkeit von paddingbits an ?

Anstelle von paddingbit sollte man es vielleicht paddingbits.symbol benennen und mögliche Werte wären 0 oder 1.

Im Forum gab es auch noch eine andere Idee
https://forum.fhem.de/index.php?topic=58397.new;topicseen#new

Ich bin aber selbst unsicher was ich davon halte.

Ralf9 · 2019-01-15T17:10:06Z

Ich würde paddingbits.value passender finden

HomeAutoUser · 2019-01-15T20:51:57Z

Egal wie es benannt wird, ich denke die Variante im Forum ist vermutlich „unsicher“ weil wir nicht Wissen wie es auf bestehende Protokolle wirkt. Wenn wir das einzeln in der Definition ergänzen ist es bestimmt besser den überblick zu behalten wo es zutrifft.

Entweder paddingbits oder paddingbits.value ist optimal.

sidey79 · 2019-01-15T21:23:19Z

Meinetwegen auch value, wobei wir damit die Wertigkeit des Bits festlegen und den Wert den die Bits repräsentieren. Richtig?

elektron-bbs · 2019-01-16T19:54:53Z

Ich finde die Idee aus dem Forum https://forum.fhem.de/index.php?topic=58397.msg885786#msg885786 eigentlich für universeller:
Zitat von Harst:
"Aus dem letzten (halben) Bit und den Definitionen für Zero und one sollte sich in fast allen Fällen der fehlende Wert ergeben. Es fehlt jeweils der zum letzten token passende aus der Liste Zero und one.
Wenn das nicht eindeutig ist haben wir sowieso keine Chance auf einen richtigen Wert."

Wie wird dann eigentlich bei Ralfs Variante das restliche Nibble aufgefüllt, wenn wir nicht zufällig eine durch 4 teilbare Anzahl an Bits haben? Bei paddingbit=1 nur eine 1 und der Rest Nullen, oder alles Einsen? Oder soll diese Variable jetzt nur speziell für dieses Protokoll sein?

Ralf9 · 2019-01-18T21:30:03Z

Aus dem letzten (halben) Bit und den Definitionen für Zero und one sollte sich in fast allen Fällen der fehlende Wert ergeben.

Es gibt einige IDs wo dies nicht funktioniert, daß bei one und zero das erste halbe Bit gleich ist, kommt recht häufig vor, z.B. bei der ID 0 oder 65.

Wie wird dann eigentlich bei Ralfs Variante das restliche Nibble aufgefüllt, wenn wir nicht zufällig eine durch 4 teilbare Anzahl an Bits haben?

Mit einer neuen Definition addbit => 0 oder addbit => 1 mit der vor dem padding ein Bit zugefügt wird, gibt es dieses Problem nicht

if (defined($ProtocolListSIGNALduino{$id}{addbit})) {
	push(@bit_msg, $ProtocolListSIGNALduino{$id}{addbit});
}

sidey79 · 2019-01-18T21:41:34Z

@elektron-bbs
Ich bin da auch hin und her gerissen. Wie Ralf es bereits geschrieben hat, gibt es Situationen, bei denen passt es nicht. Andere ließen sich so aber "dynamischer" realisieren

paddingbit würde die Anzahl vorgeben
paddingbits.value würde Festlegen ob 0 oder 1.

Eventuell könnte man beide Vorschläge auch kombinieren. Also immer wenn die 1. Pulselänge unterschiedlich ist, wird des Bit "automatisch" bestimmt. Ist es nicht eindeutig müsste paddingbits.value gesetzt sein, damit überhaupt Bits hinzugefügt werden.

Ralf9 · 2019-01-18T22:51:53Z

Bis jetzt konnte mir noch keiner einen Fall nennen wo meine Variante nicht funktioniert.

sidey79 · 2019-01-18T22:55:40Z

Du meinst, weil wenn der Letzte Pegel ein high ist, dann sorgt die nachfolgende lange Pause dafür dass es auch ausgewertet werden kann?

Ralf9 · 2019-01-18T23:17:53Z

hier habe ich es beschrieben
https://forum.fhem.de/index.php/topic,95346.msg882097.html#msg882097

elektron-bbs · 2019-01-19T13:30:23Z

Was du dort beschreibst, bezieht sich aber nur auf diesen einen speziellen Fall. Dieser Fall würde sich aber auch mit der Lösung von Harst korrigieren lassen. Diese hat den Vorteil, das sie universeller ist und nicht nur den einen Fall abdeckt.
Ich spreche übrigens nicht nur von MS, auch bei MU fehlt ja bei manchen Protokollen das letzte Bit.
Falls die Ergänzung eingebaut werden sollte, müsste sie default aber abgeschaltet sein. Es gibt ja auch Protokolle, die einfach nur einen EOT-Puls senden, wie z.B. FS20.

Ralf9 · 2019-01-19T17:19:50Z

Sie ist nur aktiv wenn addbit => 0 oder addbit => 1 in der Protokolldefinition steht.

Ich spreche übrigens nicht nur von MS, auch bei MU fehlt ja bei manchen Protokollen das letzte Bit.
Es gibt ja auch Protokolle, die einfach nur einen EOT-Puls senden, wie z.B. FS20.

Sind Dir außer bei FS20 auch noch andere Protokoll IDs bekannt wo es nur ein EOT-Puls gibt?
Sind Dir auch MS-Nachrichten bekannt wo wegen nur einem EOT-Puls das letzte Bit fehlt?

elektron-bbs · 2019-01-19T19:44:55Z

Ich meine natürlich die Variante, das das letzte (halbe) Bit automatisch ergänzt werden sollte.
Andere Protokolle sind mir nicht bekannt. Es mangelt ja auch an offiziellen Beschreibungen von Herstellern. Evtl. ist Protokoll 93 so ein Kandidat, 33 Bit sind eher ungewöhnlich.
Der EOT-Puls am Ende der Nachricht wird eigentlich nur gesendet, damit eben das letzte Bit noch ausgewertet werden kann.

Ralf9 · 2019-01-19T20:04:25Z

Bei MU-Nachrichten müsste es eigentlich funktionieren, wenn man hinter

				foreach my $sigStr (@pairs)
				{
					if (exists $patternLookupHash{$sigStr}) {
						push(@bit_msg,$patternLookupHash{$sigStr})  ## Add the bits to our bit array
					}
				}

die folgenden paar Zeilen einträgt:

if (exists($ProtocolListSIGNALduino{$id}{addbit}) && length($1) %2 == 1) {  # Laenge ungerade
	my $lastbit = substr($1,-1);
	if (substr($oneRegex,0,1) eq $lastbit) {
		push(@bit_msg,'1');
	} elsif (substr($zeroRegex,1,1) eq $lastbit) {
		push(@bit_msg,'0');
	}
}

Ralf9 · 2019-01-19T21:09:26Z

Andere Protokolle sind mir nicht bekannt.

Ich hab mal die MU-Nachrichten Protokolle durchgeschaut, die folgenden ID sind evtl auch betroffen:
8, 50, 66, 73, 78

elektron-bbs · 2019-01-19T21:32:34Z

Protokoll 73 ist wie 74 - ein EOT-Puls am Ende - braucht also kein "zusätzliches" Bit.
Mir sticht da gerade noch Protokoll 72 und 72.1 ins Auge - einmal MU und dann MS und Länge 39-40?

sidey79 · 2019-01-19T22:11:15Z

@Ralf9 @elektron-bbs

Gehört das noch in dieses Issue? Habt ihr den PR /RFD-FHEM/RFFHEM/pull/491 gesehen?

Ralf9 · 2019-01-19T22:55:45Z

Passt dort nicht dazu, hier geht es um ergänzung des letzten Bits bei MU-Nachrichten, dort sind es nur MS-Nachrichten

MoskitoHorst · 2019-01-20T14:31:56Z

Ich habe gerade einen Pull-Request für das generieren des korrekten Padbits erzeugt. Bei mir läuft das so. Es wird einfach bei der letzten Lücke im Decoder nachgesehen, ob die Situation eindeutig ist. Vielleicht passt es ja hier rein.

Horst

Ralf9 · 2019-01-20T16:58:29Z

@sidey79
Kannst Du da #102 (comment) mal drüberschauen, ob ich das mit dem $1 so machen kann

sidey79 · 2019-01-20T17:15:57Z

Ich kann aus dem Codeschnipsel nicht erkennen durch was $1 definiert wird.
B

Ralf9 · 2019-01-20T17:22:34Z

der ist von hier:
https://github.com/RFD-FHEM/RFFHEM/blob/cbee17cddbaa70adf6b88014da81780e20440321/FHEM/00_SIGNALduino.pm#L2384-L2389

sidey79 · 2019-01-20T20:20:02Z

In $1 steht das Ergebnis des kompletten matches. in $2 steht das Ergebnis der 1. capture group.

Wieso Du allerdings substr vom 1. und 2. Zeichen machst habe ich noch nicht verstanden. Ist nicht eher das letzte Interessant?

Ralf9 · 2019-01-20T21:19:38Z

Hier ist mal als Beispiel ein MU-Nachricht der ID 74 (FS20)
MU;P0=-10420;P1=-92;P2=398;P3=-417;P5=596;P6=-592;CP=2;D=1232323232323232323232323562323235656232323232356232356232323232323232323232323232323235623232323562356565623565623562023232323232323
Hier steht in $oneRegex 56 und in $zeroRegex |23
Die regex heisst dann (?:)((?:56|23){50,})
Das hier ist das Ende 2356202323 das ist "zero one" und die 2 vor der 0 ist die erste Hälfte von zero.

Ich brauche nun das Zeichen nach dem letzten 23 oder 56, hier also die 2
Wenn das richtig sehe bringt mich dies:

while ( $rawData =~ m/$regex/g) {
	my @pairs = unpack "(a$signal_width)*", $1;

nicht weiter, in $1 steht nun alles bis ...2356, die 2 ist nicht mehr dabei.
Brauche ich für die 2 eine eigene regex?
Komme ich an den Rest 202323... irgendwie ran?

sidey79 · 2019-01-20T21:29:02Z

Ich würde die Regex erweitert:

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

PS: Die von dir angegebene Regex hat einen Fehler.

Ralf9 · 2019-01-20T21:35:46Z

Ja, mit der regex müsste es funktionieren, ich werde es mal damit testen

sidey79 added the bug label Nov 25, 2018

HomeAutoUser added the incorrect detection MU MS MC label Jan 7, 2019

HomeAutoUser mentioned this issue Jan 9, 2019

added new model Atlantic Security RFD-FHEM/RFFHEM#482

Merged

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fehler bei MS-Erkennung #102

Fehler bei MS-Erkennung #102

elektron-bbs commented Nov 25, 2018 •

edited by HomeAutoUser

sidey79 commented Nov 25, 2018

sidey79 commented Nov 25, 2018

HomeAutoUser commented Jan 7, 2019 •

edited

Ralf9 commented Jan 7, 2019

sidey79 commented Jan 7, 2019

HomeAutoUser commented Jan 7, 2019

HomeAutoUser commented Jan 11, 2019

sidey79 commented Jan 11, 2019

Ralf9 commented Jan 15, 2019

HomeAutoUser commented Jan 15, 2019

sidey79 commented Jan 15, 2019

elektron-bbs commented Jan 16, 2019

Ralf9 commented Jan 18, 2019

sidey79 commented Jan 18, 2019

Ralf9 commented Jan 18, 2019

sidey79 commented Jan 18, 2019

Ralf9 commented Jan 18, 2019

elektron-bbs commented Jan 19, 2019

Ralf9 commented Jan 19, 2019

elektron-bbs commented Jan 19, 2019

Ralf9 commented Jan 19, 2019

Ralf9 commented Jan 19, 2019

elektron-bbs commented Jan 19, 2019

sidey79 commented Jan 19, 2019

Ralf9 commented Jan 19, 2019

MoskitoHorst commented Jan 20, 2019

Ralf9 commented Jan 20, 2019

sidey79 commented Jan 20, 2019

Ralf9 commented Jan 20, 2019

sidey79 commented Jan 20, 2019

Ralf9 commented Jan 20, 2019 •

edited

sidey79 commented Jan 20, 2019

Ralf9 commented Jan 20, 2019

Fehler bei MS-Erkennung #102

Fehler bei MS-Erkennung #102

Comments

elektron-bbs commented Nov 25, 2018 • edited by HomeAutoUser

sidey79 commented Nov 25, 2018

sidey79 commented Nov 25, 2018

HomeAutoUser commented Jan 7, 2019 • edited

Ralf9 commented Jan 7, 2019

sidey79 commented Jan 7, 2019

HomeAutoUser commented Jan 7, 2019

HomeAutoUser commented Jan 11, 2019

sidey79 commented Jan 11, 2019

Ralf9 commented Jan 15, 2019

HomeAutoUser commented Jan 15, 2019

sidey79 commented Jan 15, 2019

elektron-bbs commented Jan 16, 2019

Ralf9 commented Jan 18, 2019

sidey79 commented Jan 18, 2019

Ralf9 commented Jan 18, 2019

sidey79 commented Jan 18, 2019

Ralf9 commented Jan 18, 2019

elektron-bbs commented Jan 19, 2019

Ralf9 commented Jan 19, 2019

elektron-bbs commented Jan 19, 2019

Ralf9 commented Jan 19, 2019

Ralf9 commented Jan 19, 2019

elektron-bbs commented Jan 19, 2019

sidey79 commented Jan 19, 2019

Ralf9 commented Jan 19, 2019

MoskitoHorst commented Jan 20, 2019

Ralf9 commented Jan 20, 2019

sidey79 commented Jan 20, 2019

Ralf9 commented Jan 20, 2019

sidey79 commented Jan 20, 2019

Ralf9 commented Jan 20, 2019 • edited

sidey79 commented Jan 20, 2019

Ralf9 commented Jan 20, 2019

elektron-bbs commented Nov 25, 2018 •

edited by HomeAutoUser

HomeAutoUser commented Jan 7, 2019 •

edited

Ralf9 commented Jan 20, 2019 •

edited