SIGNALDuino
SIGNALDuino copied to clipboard
RFD-FHEM
Fehler bei MS-Erkennung
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
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
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 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],
@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.
@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.
@sidey79 im Beitrag https://github.com/RFD-FHEM/SIGNALDuino/issues/102#issuecomment-452011691 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.
@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.
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.
Meinetwegen auch value, wobei wir damit die Wertigkeit des Bits festlegen und den Wert den die Bits repräsentieren. Richtig?
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?
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});
}
@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.
Bis jetzt konnte mir noch keiner einen Fall nennen wo meine Variante nicht funktioniert.
Du meinst, weil wenn der Letzte Pegel ein high ist, dann sorgt die nachfolgende lange Pause dafür dass es auch ausgewertet werden kann?
hier habe ich es beschrieben https://forum.fhem.de/index.php/topic,95346.msg882097.html#msg882097
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.
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?
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.
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');
}
}
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
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?
@Ralf9 @elektron-bbs
Gehört das noch in dieses Issue? Habt ihr den PR /RFD-FHEM/RFFHEM/pull/491 gesehen?
Passt dort nicht dazu, hier geht es um ergänzung des letzten Bits bei MU-Nachrichten, dort sind es nur MS-Nachrichten
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
@sidey79 Kannst Du da https://github.com/RFD-FHEM/SIGNALDuino/issues/102#issuecomment-455810942 mal drüberschauen, ob ich das mit dem $1 so machen kann
Ich kann aus dem Codeschnipsel nicht erkennen durch was $1 definiert wird. B
der ist von hier: https://github.com/RFD-FHEM/RFFHEM/blob/cbee17cddbaa70adf6b88014da81780e20440321/FHEM/00_SIGNALduino.pm#L2384-L2389
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?