Signalduino Version 3.3.1 / 3.3.2 / 3.3.3-dev

[RaspiLED]

Hi,
welche Hardware genau? Ich denke die Hex kommt auf 0x0000 und ist ausreichend
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

[killah78]

Da es dieser CUL_TCM97001  53 nicht ist, wird es schwierig.

Sieht Dein GT_WT_02 so aus?
https://shop.zeitlos-vertrieb.de/sensor-gt-wt-02-866146-578

Im log ist auch noch ein TFA 30.3208.0, SD_WS_58_TH_3, wird der ausreichend oft empfangen?

Hast Du auch noch eine WH3080?
Wenn Du das sduino Attribut WS09_CRCAUS auf 2 setzt, wird der Empfang besser

Gruß Ralf

Der GT_WT_02 ist leider nicht meiner und auch nicht in meiner Sichtweite.
Aber er kam bisher immer stabil und zuverlässig rein daher habe ich ihn immer als weiteres Thermometer verwendet.

Von den SD_WS_58 gibt es mehrere, und diese werden auch stabil empfangen. Diese sind jedoch auch nicht von mir und wohl auch irgendwo Indoor aufgebaut, daher für mich uninteressant.

Die WH3080 ist meine. Habe mal das WS09_CRCAUS auf 2 gesetzt. Hatte das bisher auf 0. Was besagt denn die zwei?

Aber nochmal zum GT_WT_02.
Was kann denn die Ursache sein, dass ein Signalduino örtlich an der gleichen Stelle, an einem aktiven Hub (= gleiche Spannungsverhältnisse) unterschiedliche Daten aufzeichnet? Die empfangenen Flanken kommen ja aus dem Arduino, nicht aus der verwendeten Hardware. Und die letztendliche Interpretation gibt ja dann auch keinen Spielraum.

Dazu noch eine andere Frage:
Wie lese ich das in der Hash Tabelle.
Zb. für id 0, one = [1,-7], zero = [1,-3], sync = [1,-16]
Wenn ich dann sowas habe wie:
MS;P0=539;P1=-9108;P2=-4140;P3=-2094;
Wie passt das übereinander?

Vielen Dank für die Hilfe.
Gruss

[Ralf9]

Die WH3080 ist meine. Habe mal das WS09_CRCAUS auf 2 gesetzt. Hatte das bisher auf 0. Was besagt denn die zwei?

Steht in der commandref

0: CRC-Check WH1080 CRC = 0 on, Standard
2: CRC = 49 (x031) WH1080, set OK

Dies ist ein Workaround, da bei manchen Protokollen wie auch hier bei der ID 9 das letzte Bit immer als 0 erkannt wird.
Wenn das letzte Bit 1 wäre ergibt diese eine falsche Prüfsumme von 49 (x031).
Wenn demnächst das "reconstructed last bit" auch in der offiziellen Version ist, wird dieser Workaround nicht mehr benötigt.

Hast Du mir mal z.B. von dem Internals des GT_WT_02 ein paar der seltenen empfangenen MS-Nachrichten?

Wie lese ich das in der Hash Tabelle.
Zb. für id 0, one = [1,-7], zero = [1,-3], sync = [1,-16]
Wenn ich dann sowas habe wie:
MS;P0=539;P1=-9108;P2=-4140;P3=-2094;
Wie passt das übereinander?

Code Auswählen Erweitern

one = [1,-7],  ist clock und clock mal -7 , also 539, -3773
zero = [1,-3], ist clock und clock mal -3 , also 539, -1617
sync = [1,-16], ist clock und clock mal -16 , also 539, -8624

Da gibt es auch noch Toleranzen:
my $tol=abs(abs($searchpattern)>3 ? abs($searchpattern)>16 ? $searchpattern*0.18 : $searchpattern*0.3 : 1);
also
bis 3 Tol=1
> 3 Tol=0.3
> 16 Tol=0.18

Gruß Ralf

[killah78]

Hallo Ralf9,
danke für die Erklärung, die Toleranz gilt für alle Protokolle so? Gilt das für positive und negative Abweichung?
Also ein zero = [1,-3] wäre dann 1,-2 bis 1,-4 ?

Ich habe das CRCAUS=2 mal so gesetzt. Hatte vorher aber eigentlich auch keine Probleme. Signale kommen so alle 5 Minuten.

Das letzte Signal vom GT_WT_02 wurde heute Morgen empfangen, seit gestern Abend 10 korrekt empfangene Daten.

Code Auswählen Erweitern

sduino_DMSG s9968FEA0A800
   sduino_MSGCNT 10
   sduino_RAWMSG MS;P0=-4138;P1=525;P2=-2105;P6=-9320;D=1610121210101212101210101210121212101010101010101210121012121212121012101210;CP=1;SP=6;R=240;
   sduino_RSSI -82
   sduino_TIME 2019-02-25 08:05:02


Es kommen auch vereinzelt folgende Nachrichten als Unknown rein:

Code Auswählen Erweitern

sduino_DMSG s9968F800
   sduino_MSGCNT 24
   sduino_RAWMSG MS;P0=92;P1=527;P4=-4102;P5=-2037;P6=-9106;P7=-18880;D=16141515141415151415141415141515151414141414170515151515151415141514;CP=1;SP=6;R=235;m2;
   sduino_RSSI -84.5
   sduino_TIME 2019-02-25 08:25:53

Diese werden wohl vom besagten GT_WT_02 kommen, sind aber nicht vollständig.

Gruss

[Harst]

Wenn Du jetzt noch von den Dingen, die gehen (oder auch nicht) ein Bild und das Protokoll hast, dann kann ich das Wiki unter https://wiki.fhem.de/wiki/Geprüfte_Geräte erweitern.

Horst

[elektron-bbs]

Das letzte Signal vom GT_WT_02 wurde heute Morgen empfangen, seit gestern Abend 10 korrekt empfangene Daten.

Code Auswählen Erweitern

sduino_DMSG s9968FEA0A800
   sduino_RSSI -82


Es kommen auch vereinzelt folgende Nachrichten als Unknown rein:

Code Auswählen Erweitern

sduino_DMSG s9968F800
   sduino_RSSI -84.5


Für mich sieht das einfach so aus, als ob du schlechte Empfangsbedingungen hast. Die RSSI-Werte sind grenzwertig.

[Ralf9]

Gilt das für positive und negative Abweichung?

Ja

Hast Du schon mal versucht den sduino mit einem etwas längerem USB Kabel etwas weiter vom Rechner abzusetzen?

[Ralf9]

Da der GT_WT_02 die Besonderheit hat, daß die Wiederholungen durch 2 sync getrennt sind, lassen sich die MS-Nachrichten ganz leicht durch meine firmware V 3.3.2.1-rc8 erkennen;

MS;P1=-9013;P2=554;P3=-2088;P4=-4117;D=2123232323242324242423232323232323242324232424242323242324232424242423242423;CP=2;SP=1;R=244;O;s=4;m1;

Mit dem Attribut rawmsgEvent 1 lösen empfangene Rohnachrichten Ereignisse aus.

Wenn ich nun im Event monitor den folgenden Events Filter setze, passt es nicht, anscheinend liegt es an den Semikolons

Code Auswählen Erweitern

.*;s=4;.*

mit diesem Filter werden wie gewünscht alle Nachrichten angezeigt, die "s=4" enthalten

Code Auswählen Erweitern

.*s=4.*

Heißt das, daß im Filter keine Semikolons verwendet werden können?

[RaspiLED]

Hi,
Musst Du die Semikolons nicht escapen bzw. Doppelt angeben?
Gruß Arnd


Gesendet von iPhone mit Tapatalk

[Ralf9]

Musst Du die Semikolons nicht escapen bzw. Doppelt angeben?

Habe ich auch schon ohne Erfolg getestet.

[killah78]

Hast Du schon mal versucht den sduino mit einem etwas längerem USB Kabel etwas weiter vom Rechner abzusetzen?

Ja, das ist ja aktuell der Unterschied. Vorher über aktivem USB Hub direkt neben einem Raspberry, jetzt über einen aktiven USB Hub, über eine aktive USB Verlängerung (ca 7 Meter) an ein RockPro. Ich habe den Signalduino jetzt auch mal direkt an den Rockpro angeschlossen, aber auch dann gibt es keinen Empfang, aber da dann örtlich versetzt, kann das dann schon die Signalstärke sein.

Egal, werde den Sender nicht mehr nutzen. Es war eh nur ein "Ausweich-Sender".
Es bleibt mir trotzdem ein Mysterium, warum der selbe Signalduino, an gleicher Stromquelle (=aktiver Hub), am selben Ort einmal gut empfängt, einmal kaum.

Danke für die Hilfe und die Erklärungen.

[Sidey]

Hast Du denn mit der alten Konstellation noch Empfang?

Grüße Sidey

[killah78]

Hast Du denn mit der alten Konstellation noch Empfang?

Grüße Sidey

Ja, wenn ich den Signalduino wieder an den Raspberry stecke, ist der Empfang wieder regelmäßig da.
Hilft ein Log oder ein anderer Test?

Gruss

[Sidey]

Ja, ein Logfile würde mich da Mal sehr interessieren.
Stell am besten auf Verbose 5, dann entgeht uns nichts.

Gesendet von meinem Moto Z (2) mit Tapatalk

[Kawaci]

Hey was ist im Moment die aktuelle funktionierende firmware? Geht die für 868 und 433?