Problem m. Signalduino; FHEM Oberfläche "hängt"/wird blockiert->ziemlich Gelöst!

DerStephan · 02 Juni 2016, 11:16:01

Hallo zusammen!

Ich habe ein Problem mit einem (bzw ein zweiter) Signalduino angeschlossen ist. Es scheint, als würde der Signalduino empfangen,eine rote LED flackert in unregelmässigen Abständen. Wenn ich den Signalduino vom USB abziehe, reagiert die Oberfläche sofort wieder.

Im Log gibts folgende Meldung:

Code Auswählen


2016.06.02 10:28:00 1: define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL021NFH-if00-port0@57600
2016.06.02 10:28:00 1: init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL021NFH-if00-port0@57600
2016.06.02 10:28:09 1: Cannot init /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL021NFH-if00-port0, ignoring it (sduino2)
PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/00_SIGNALduino.pm line 856, <$fh> line 62.

Trotzdem werden Geräte gefunden,angelegt und auch ausgelesen:

Code Auswählen


2016.06.02 10:28:43 2: autocreate: define AURIOL_37 CUL_TCM97001 CUL_TCM97001_37
2016.06.02 10:28:43 2: autocreate: define FileLog_AURIOL_37 FileLog ./log/AURIOL_37-%Y.log AURIOL_37
2016.06.02 10:28:43 2: autocreate: define SVG_AURIOL_37 SVG FileLog_AURIOL_37:temp4hum4:CURRENT
2016.06.02 10:29:17 2: autocreate: define CUL_TX_96 CUL_TX 96
2016.06.02 10:29:17 2: autocreate: define FileLog_CUL_TX_96 FileLog ./log/CUL_TX_96-%Y.log CUL_TX_96
2016.06.02 10:29:17 2: autocreate: define SVG_CUL_TX_96 SVG FileLog_CUL_TX_96:temp4hum4:CURRENT

Flashen ging interessanterweise ohne Probleme. (FHEM 5.7) Ein zweiter von mir mit anderen Bauteilen zusammengebauter Signalduino reagiert genau so. Wenn ich die Signalleitung des Empfängers nicht anschliesse, läuft die Oberfläche und der Signalduino wird als Initialisiert angezeigt. Dann kann aber natürlich nichts eingelesen werden. Das Problem scheint irgendwie zu sein, dass der Datenstrom bei Empfang das aufrufen der Oberfläche verhindert (selbst wenn verbose auf 0 steht).

Einmal zwischendurch lief alles, da dachte ich schon, ich hätte das Problem gefunden, aber nach dem umstecken war wieder alles wie zuvor.

Hat jemand eine Idee, woran das liegen könnte bzw selbst das Problem?

Konfiguration: Raspberry Pi 2, Jessie, FHEM 5.7,Arduino Nano (Fake?-) FT 232, diverse Empfangsmodule für 433 MHz

Viele Grüße,

Stephan

habeIchVergessen · 02 Juni 2016, 14:34:11

ich behaupte, dass ohne angeschlossene DATA-Leitung vom Empfänger permanent Geister-Daten empfangen werden.
setze verbose vom sduino auf 4 und beobachte das Log-File.

DerStephan · 02 Juni 2016, 16:13:54

Hmm, ich habe etwas weiter geforscht:

wenn ich ohne angeschlossenen RX den Arduino anschliesse, wird er als Signalduino gefunden und initialisiert. Danach habe ich erst die Leitungen vom RX an den Arduino gesteckt und es funktioniert weiter, es werden auch Funksender geloggt.

Was ich aber etwas seltsam finde, ist die Häufigkeit der Initialisierung des Signalduinos:

Code Auswählen



2016-06-02 16:08:05 SIGNALduino sduino3 Initialized
2016-06-02 16:08:05 SIGNALduino sduino3 Initialized
2016-06-02 16:08:06 SIGNALduino sduino3 Initialized
2016-06-02 16:08:07 SIGNALduino sduino3 Initialized
2016-06-02 16:08:08 SIGNALduino sduino3 Initialized
2016-06-02 16:08:09 SIGNALduino sduino3 Initialized
2016-06-02 16:08:09 SIGNALduino sduino3 Initialized
2016-06-02 16:08:09 CUL_TCM97001 TCM97..._37 trend: rising
2016-06-02 16:08:09 CUL_TCM97001 TCM97..._37 temperature: 24.0
2016-06-02 16:08:09 CUL_TCM97001 TCM97..._37 T: 24.0
2016-06-02 16:08:10 SIGNALduino sduino3 Initialized
2016-06-02 16:08:11 SIGNALduino sduino3 Initialized
2016-06-02 16:08:11 SIGNALduino sduino3 Initialized
2016-06-02 16:08:12 SIGNALduino sduino3 Initialized
2016-06-02 16:08:12 SIGNALduino sduino3 Initialized
2016-06-02 16:08:13 SIGNALduino sduino3 Initialized
2016-06-02 16:08:14 SIGNALduino sduino3 Initialized
2016-06-02 16:08:14 SIGNALduino sduino3 Initialized
2016-06-02 16:08:15 SIGNALduino sduino3 Initialized
2016-06-02 16:08:16 SIGNALduino sduino3 Initialized
2016-06-02 16:08:17 SIGNALduino sduino3 Initialized
2016-06-02 16:08:18 SIGNALduino sduino3 Initialized
2016-06-02 16:08:18 SIGNALduino sduino3 Initialized
2016-06-02 16:08:18 SIGNALduino sduino3 Initialized
2016-06-02 16:08:19 SIGNALduino sduino3 Initialized
2016-06-02 16:08:19 SIGNALduino sduino3 Initialized
2016-06-02 16:08:20 SIGNALduino sduino3 Initialized
2016-06-02 16:08:20 SIGNALduino sduino3 Initialized
2016-06-02 16:08:22 SIGNALduino sduino3 Initialized
2016-06-02 16:08:23 SIGNALduino sduino3 Initialized

Ist das normal, wenn der Stick mehrmals pro Sekunde Initialisiert wird?

Habe auch verschiedene Hardwaremodifikationen ausprobiert: Pufferkondensator zur Stabilisierung der 5 Volt Leitung, Pullup & Pulldown der Datenleitung. Hat alles nichts geholfen.

Die einzige Variante, den Signalduino zuverlässig zum laufen zu bringen , ist bei mir die Variante, ohne Datenleitung zu starten und diese im laufenden Betrieb zu stecken.

Ich hab zu wenig Ahnung von dem Programmcode, würde es was bringen, zB die Datenabfrage im Signalduino erst einige Sekunden nach dem Start zu beginnen? Und wie könnte man das in den Code reinbekommen?

Ralf9 · 02 Juni 2016, 19:45:22

Zitat von: DerStephan am 02 Juni 2016, 16:13:54
wenn ich ohne angeschlossenen RX den Arduino anschliesse, wird er als Signalduino gefunden und initialisiert. Danach habe ich erst die Leitungen vom RX an den Arduino gesteckt und es funktioniert weiter, es werden auch Funksender geloggt.

Was ich aber etwas seltsam finde, ist die Häufigkeit der Initialisierung des Signalduinos:

Das ist nicht normal. Was erhältst Du bei "get uptime"?
Hast Du evtl ein Nano mit Fake-FTDI? Die können auch Probleme machen
https://forum.fhem.de/index.php/topic,38831.msg447254.html#msg447254

Verwendest Du einen brauchbaren Empfänger?
https://forum.fhem.de/index.php/topic,17196.msg454454.html#msg454454
https://forum.fhem.de/index.php/topic,17196.msg454572.html#msg454572

Hast Du es schon mal mit der dev Version versucht?

Code Auswählen

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32/controls_signalduino.txt

Gruß Ralf

DerStephan · 03 Juni 2016, 00:14:35

Hallo "habichvergessen" und Ralf!

Zitatsetze verbose vom sduino auf 4 und beobachte das Log-File.

Es gibt tatsächlich eine vielzahl Geräten, die ich hier "höre". Aber im "Normalfall" komme ich gar nicht in das Log, wenn der Signalduino angeschlossen ist.

ZitatWas erhältst Du bei "get uptime"?

Uptime scheint er ganz normal hochzuzählen, wenn ich beim Anschluss die "Prozedur" mit dem "erst ohne Empfänger anschliessen und dann erst Empfänger zustecken" einhalte.

ZitatVerwendest Du einen brauchbaren Empfänger?

Ich hab mittlerweile so gut wie alle Varianten durch: den billigen, einen etwas besseren und den mit der Abschirmung und 3 pins rechts + 3 pins links.

. Machen aber alle keinen grossen Unterschied.

ZitatHast Du evtl ein Nano mit Fake-FTDI? Die können auch Probleme machen

Da könnte der Fehler liegen! Auch wenn die jetzt verwendeten Arduinos nicht mehr durch den Windows Treiber auf 0 zurück gesetzt wurden, gehe ich davon aus, dass es Fake Modelle sind.
Soweit ich weiss, sind die Fakes zu 100% Pinkompatibel mit den echten?! Da müsste es möglich sein, die Fake 232 durch echte zB von Reichelt zu ersetzen, oder? Heissluftlöter und etwas Erfahrung sind vorhanden, ich werde mal versuchen, die Chips zu tauschen, dann kann man jedenfalls einigermaßen sicher sein, dass man einen echten FT232-Arduino hat.

Vielen Dank für eure Hinweise!

Stephan

RappaSan · 03 Juni 2016, 07:29:43

Mir fällt noch ein: kritische Versorgungsspannung.
Evtl können nicht alle Komponenten mit stabiler Spannung versorgt werden und liefern dadurch Störsignale ab.

Ralf9 · 03 Juni 2016, 17:47:09

Zitat von: DerStephan am 03 Juni 2016, 00:14:35
Es gibt tatsächlich eine vielzahl Geräten, die ich hier "höre". Aber im "Normalfall" komme ich gar nicht in das Log, wenn der Signalduino angeschlossen ist.

Kannst Du mal im log schauen wie viele MU-Nachrichten ungefähr in einer Minute empfangen werden?

MU-Nachrichten sehen ungefähr so aus:
sduino/msg READ: MU;P0=-200;P1=..

Gruß Ralf

DerStephan · 03 Juni 2016, 20:52:21

Das mit den MU Nachrichten schaue ich mir gleich mal an.Auch die Stromversorgung nehme ich noch unter die Lupe.

Interessant ist es auch, wenn ich den Raspi neu starte mit dem angeschlossenen Signalduino (inkl Empfänger:

Code Auswählen



2016.06.03 21:02:40 1: Including fhem.cfg
2016.06.03 21:02:40 3: telnetPort: port 7072 opened
2016.06.03 21:02:41 3: WEB: port 8083 opened
2016.06.03 21:02:41 3: WEBphone: port 8084 opened
2016.06.03 21:02:41 3: WEBtablet: port 8085 opened
2016.06.03 21:02:41 2: eventTypes: loaded 100 events from ./log/eventTypes.txt
2016.06.03 21:02:41 3: sduino3: IDlist MS 0 1 13 14 15 17 2 22 23 25 3 32 33 35 38 4 6 7
2016.06.03 21:02:41 3: sduino3: IDlist MU 16 20 21 24 26 27 28 29 30 31 34 36 37 39 5 8 9
2016.06.03 21:02:41 3: sduino3: IDlist MC 10 11 12 18
2016.06.03 21:02:41 3: Opening sduino3 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9YDP7FJ-if00-port0
2016.06.03 21:02:41 3: Setting sduino3 serial parameters to 57600,8,N,1
2016.06.03 21:02:41 3: sduino3 device opened
2016.06.03 21:02:41 1: define: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9YDP7FJ-if00-port0@57600
2016.06.03 21:02:41 1: init: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9YDP7FJ-if00-port0@57600
2016.06.03 21:02:45 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/00_SIGNALduino.pm line 1720, <$fh> line 68.
2016.06.03 21:03:09 2: CUL_TCM97001 Unknown device CUL_TCM97001_37, please define it
2016.06.03 21:03:38 2: CUL_TCM97001 Unknown device CUL_TCM97001_37, please define it
2016.06.03 21:03:38 2: autocreate: define AURIOL_37 CUL_TCM97001 CUL_TCM97001_37
2016.06.03 21:03:38 2: autocreate: define FileLog_AURIOL_37 FileLog ./log/AURIOL_37-%Y.log AURIOL_37
2016.06.03 21:03:38 2: autocreate: define SVG_AURIOL_37 SVG FileLog_AURIOL_37:temp4hum4:CURRENT
2016.06.03 21:03:45 3: sduino3: Possible commands: ViRtXFSPCG
2016.06.03 21:03:45 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/00_SIGNALduino.pm line 856.
2016.06.03 21:03:45 3: sduino3: Firmwareversion: V 3.2.0-b12 SIGNALduino - compiled at Feb 13 2016 21:34:09

2016.06.03 21:03:45 1: Including ./log/fhem.save
2016.06.03 21:03:45 1: configfile: AURIOL_37 already defined, delete it first
FileLog_AURIOL_37 already defined, delete it first
SVG_AURIOL_37 already defined, delete it first

2016.06.03 21:03:45 2: Messages collected while initializing FHEM: configfile: AURIOL_37 already defined, delete it first FileLog_AURIOL_37 already defined, delete it first SVG_AURIOL_37 already defined, delete it first 
2016.06.03 21:03:45 0: Featurelevel: 5.7
2016.06.03 21:03:45 0: Server started with 13 defined entities (fhem.pl:11545/2016-05-29 perl:5.020002 os:linux user:fhem pid:514)

Um ca 21:03:45 (habe den Versuch gerade nochmal wiederholt, vorher meine anderen SDuino-Versuche deaktiviert, damit es nicht unübersichtlich wird) habe ich dann kurz die Stromversorgung des Empfängers unterbrochen und kurz darauf wieder eingesteckt, damit die Oberfläche wieder erreichbar ist. Es scheint, dass die Initialisierung von FHEM durch den SDuino pausiert wird (oder habe ich das falsch interpretiert?).
Erst wenn der Empfänger des SDuinos kurz entfernt wird und keine Daten mehr liefern kann, wird die Initialisierung (vom SDuino?) beendet und der Rest von FHEM. Danach ist alles völlig normal benutzbar (bis zum nächsten Neustart oder ab- und anklemmen des SDuino)

DerStephan · 03 Juni 2016, 21:16:01

Es gibt anscheinend ziemlich viele von diesen MU Messages?!

Code Auswählen



2016.06.03 21:13:09 4: sduino3/msg READ: MU;P0=-237;P1=163;D=01010101010101010101010101010101010101010101010101;CP=1;
2016.06.03 21:13:09 4: sduino3/msg READ: MU;P0=-216;P1=9988;P2=152;D=0010202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202;CP=2;
2016.06.03 21:13:09 4: sduino3: Fingerprint for MU Protocol id 20 -> livolo matches, trying to demodulate
2016.06.03 21:13:09 4: sduino3: decoded matched MU Protocol id 20 dmsg u20#AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8 length 208
2016.06.03 21:13:09 4: SIGNALduino_unknown incomming msg: u20#AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8
2016.06.03 21:13:09 4: SIGNALduino_unknown rawData: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8
2016.06.03 21:13:09 4: SIGNALduino_unknown Protocol: 20
2016.06.03 21:13:09 4: SIGNALduino_unknown converted to bits: 1010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101000
2016.06.03 21:13:10 4: sduino3/msg READ: MU;P0=171;P1=10024;P2=-260;P3=-2508;P4=-5484;D=01202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202030402020202020202;CP=0;
2016.06.03 21:13:10 4: sduino3: Fingerprint for MU Protocol id 20 -> livolo matches, trying to demodulate
2016.06.03 21:13:10 4: sduino3: decoded matched MU Protocol id 20 dmsg u20#AAAAAAAAAAAAAAAAAAAAAAAAAAAA length 112
2016.06.03 21:13:10 4: SIGNALduino_unknown incomming msg: u20#AAAAAAAAAAAAAAAAAAAAAAAAAAAA
2016.06.03 21:13:10 4: SIGNALduino_unknown rawData: AAAAAAAAAAAAAAAAAAAAAAAAAAAA
2016.06.03 21:13:10 4: SIGNALduino_unknown Protocol: 20
2016.06.03 21:13:10 4: SIGNALduino_unknown converted to bits: 1010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010
2016.06.03 21:13:10 4: sduino3: Fingerprint for MU Protocol id 39 -> X10 Protocol matches, trying to demodulate
2016.06.03 21:13:10 4: sduino3/msg READ: MS;P0=-233;P1=235;P2=-7404;P3=9960;D=1230101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101;CP=1;SP=2;
2016.06.03 21:13:11 4: sduino3/msg READ: MU;P0=-237;P1=236;D=001010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101;CP=1;
2016.06.03 21:13:12 4: sduino3/msg READ: MS;P0=-268;P3=221;P4=-8608;P5=-620;D=3435303030303030303030303030303030303030303030303030303030303;CP=3;SP=4;
2016.06.03 21:13:12 4: sduino3/msg READ: MU;P0=-217;P1=153;D=010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101;CP=1;
2016.06.03 21:13:13 4: sduino3/msg READ: MU;P0=2504;P1=15796;P2=-226;P3=163;D=012323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323232323;CP=3;
2016.06.03 21:13:13 4: sduino3: Fingerprint for MU Protocol id 20 -> livolo matches, trying to demodulate
2016.06.03 21:13:13 4: sduino3: decoded matched MU Protocol id 20 dmsg u20#AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA length 208
2016.06.03 21:13:13 4: SIGNALduino_unknown incomming msg: u20#AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
2016.06.03 21:13:13 4: SIGNALduino_unknown rawData: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
2016.06.03 21:13:13 4: SIGNALduino_unknown Protocol: 20
2016.06.03 21:13:13 4: SIGNALduino_unknown converted to bits: 1010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010
2016.06.03 21:13:13 4: sduino3/msg READ: MU;P0=-250;P1=141;P2=10016;D=001020101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101;CP=1;
2016.06.03 21:13:13 4: sduino3: Fingerprint for MU Protocol id 20 -> livolo matches, trying to demodulate
2016.06.03 21:13:13 4: sduino3: decoded matched MU Protocol id 20 dmsg u20#AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA length 140
2016.06.03 21:13:13 4: SIGNALduino_unknown incomming msg: u20#AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
2016.06.03 21:13:13 4: SIGNALduino_unknown rawData: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
2016.06.03 21:13:13 4: SIGNALduino_unknown Protocol: 20
2016.06.03 21:13:13 4: SIGNALduino_unknown converted to bits: 10101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010
2016.06.03 21:13:15 4: sduino3/msg READ: MU;P0=-726;P1=124;P2=-267;D=001212121212121212121212121212121212121212121212;CP=1;
2016.06.03 21:13:15 4: sduino3: Fingerprint for MU Protocol id 20 -> livolo matches, trying to demodulate
2016.06.03 21:13:15 4: sduino3: decoded matched MU Protocol id 20 dmsg u20#555555555554 length 48
2016.06.03 21:13:15 4: SIGNALduino_unknown incomming msg: u20#555555555554
2016.06.03 21:13:15 4: SIGNALduino_unknown rawData: 555555555554
2016.06.03 21:13:15 4: SIGNALduino_unknown Protocol: 20
2016.06.03 21:13:15 4: SIGNALduino_unknown converted to bits: 010101010101010101010101010101010101010101010100
2016.06.03 21:13:15 4: sduino3: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2016.06.03 21:13:15 4: sduino3/msg READ: MU;P0=-220;P1=192;P2=-21776;P3=9976;D=0101010101010101010101010101010101010101010101010101010101010101010101010101010101010123010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010;CP=1;O;
2016.06.03 21:13:15 4: sduino3/msg READ: MU;P0=242;P1=-219;D=0101010101010101010101010101010101010101010;CP=0;
2016.06.03 21:13:16 4: sduino3/msg READ: MU;P0=-278;P1=10004;P3=115;D=010303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030;CP=3;
2016.06.03 21:13:16 4: sduino3: Fingerprint for MU Protocol id 20 -> livolo matches, trying to demodulate
2016.06.03 21:13:16 4: sduino3: decoded matched MU Protocol id 20 dmsg u20#AAAAAAAAAAAAAAAAAAAAAAAAAA length 104
2016.06.03 21:13:16 4: SIGNALduino_unknown incomming msg: u20#AAAAAAAAAAAAAAAAAAAAAAAAAA
2016.06.03 21:13:16 4: SIGNALduino_unknown rawData: AAAAAAAAAAAAAAAAAAAAAAAAAA
2016.06.03 21:13:16 4: SIGNALduino_unknown Protocol: 20
2016.06.03 21:13:16 4: SIGNALduino_unknown converted to bits: 10101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010
2016.06.03 21:13:16 4: sduino3/msg READ: MU;P0=-7556;P1=-245;P2=125;D=012121212121212121212121212121212121212121212121212121212121212;CP=2;
2016.06.03 21:13:16 4: sduino3: Fingerprint for MU Protocol id 20 -> livolo matches, trying to demodulate
2016.06.03 21:13:16 4: sduino3: decoded matched MU Protocol id 20 dmsg u20#5555555555555550 length 64
2016.06.03 21:13:16 4: SIGNALduino_unknown incomming msg: u20#5555555555555550
2016.06.03 21:13:16 4: SIGNALduino_unknown rawData: 5555555555555550
2016.06.03 21:13:16 4: SIGNALduino_unknown Protocol: 20
2016.06.03 21:13:16 4: SIGNALduino_unknown converted to bits: 0101010101010101010101010101010101010101010101010101010101010000
2016.06.03 21:13:16 4: sduino3/msg READ: MU;P0=10032;P1=-254;P2=190;D=0121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121212121;CP=2;
2016.06.03 21:13:16 4: sduino3: Fingerprint for MU Protocol id 20 -> livolo matches, trying to demodulate
2016.06.03 21:13:16 4: sduino3: decoded matched MU Protocol id 20 dmsg u20#55555555555555555555555555555 length 116
2016.06.03 21:13:16 4: SIGNALduino_unknown incomming msg: u20#55555555555555555555555555555
2016.06.03 21:13:16 4: SIGNALduino_unknown rawData: 55555555555555555555555555555
2016.06.03 21:13:16 4: SIGNALduino_unknown Protocol: 20
2016.06.03 21:13:16 4: SIGNALduino_unknown converted to bits: 01010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101
2016.06.03 21:13:16 4: sduino3/msg READ: MU;P0=155;P1=-234;P2=-620;D=010101010101010101010101010101010201010101010101010101010101010101010101010;CP=0;
2016.06.03 21:13:16 4: sduino3: Fingerprint for MU Protocol id 20 -> livolo matches, trying to demodulate
2016.06.03 21:13:16 4: sduino3: decoded matched MU Protocol id 20 dmsg u20#55555555550 length 44
2016.06.03 21:13:16 4: SIGNALduino_unknown incomming msg: u20#55555555550
2016.06.03 21:13:16 4: SIGNALduino_unknown rawData: 55555555550
2016.06.03 21:13:16 4: SIGNALduino_unknown Protocol: 20
2016.06.03 21:13:16 4: SIGNALduino_unknown converted to bits: 01010101010101010101010101010101010101010000
2016.06.03 21:13:16 4: sduino3: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2016.06.03 21:13:17 4: sduino3/msg READ: MU;P0=-273;P1=10024;P3=136;D=010303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303;CP=3;
2016.06.03 21:13:17 4: sduino3: Fingerprint for MU Protocol id 20 -> livolo matches, trying to demodulate
2016.06.03 21:13:17 4: sduino3: decoded matched MU Protocol id 20 dmsg u20#AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA length 136
2016.06.03 21:13:17 4: SIGNALduino_unknown incomming msg: u20#AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
2016.06.03 21:13:17 4: SIGNALduino_unknown rawData: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
2016.06.03 21:13:17 4: SIGNALduino_unknown Protocol: 20
2016.06.03 21:13:17 4: SIGNALduino_unknown converted to bits: 1010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010
2016.06.03 21:13:18 4: sduino3/msg READ: MU;P0=-242;P1=216;D=0101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101;CP=1;
2016.06.03 21:13:18 4: sduino3/msg READ: MU;P0=-264;P1=10032;P3=162;P4=-7888;P5=-620;D=0103030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030303030343530303030303030303030303030303030303030303030303030303030303;CP=3;
2016.06.03 21:13:18 4: sduino3: Fingerprint for MU Protocol id 20 -> livolo matches, trying to demodulate
2016.06.03 21:13:18 4: sduino3: decoded matched MU Protocol id 20 dmsg u20#555555555555554 length 60
2016.06.03 21:13:18 4: SIGNALduino_unknown incomming msg: u20#555555555555554
2016.06.03 21:13:18 4: SIGNALduino_unknown rawData: 555555555555554
2016.06.03 21:13:18 4: SIGNALduino_unknown Protocol: 20
2016.06.03 21:13:18 4: SIGNALduino_unknown converted to bits: 010101010101010101010101010101010101010101010101010101010100
2016.06.03 21:13:18 4: sduino3: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2016.06.03 21:13:18 4: sduino3/msg READ: MU;P0=32001;P1=145;P2=-216;D=012121212121212121212121212121212121212121;CP=1;
2016.06.03 21:13:18 4: sduino3: Fingerprint for MU Protocol id 20 -> livolo matches, trying to demodulate
2016.06.03 21:13:18 4: sduino3: decoded matched MU Protocol id 20 dmsg u20#AAAAAAAAAA length 40
2016.06.03 21:13:18 4: SIGNALduino_unknown incomming msg: u20#AAAAAAAAAA
2016.06.03 21:13:18 4: SIGNALduino_unknown rawData: AAAAAAAAAA
2016.06.03 21:13:18 4: SIGNALduino_unknown Protocol: 20
2016.06.03 21:13:18 4: SIGNALduino_unknown converted to bits: 1010101010101010101010101010101010101010

Was kann das bedeuten?

Ralf9 · 03 Juni 2016, 21:46:36

Zitat von: DerStephan am 03 Juni 2016, 21:16:01
Es gibt anscheinend ziemlich viele von diesen MU Messages?!
Was kann das bedeuten?

So wies aussieht werden auch Störsignale empfangen.
Aus dem wiki:

Code Auswählen

MU - Message unsynced: Diese Art von Nachrichten, sind nicht nach Manchester codiert und haben auch keinen erkennbaren Sync / Clock Signalpegel 
am Start der Nachricht. Bei diesen Nachrichtentypen ist es, im Vergleich zu den anderen, am wahrscheinlichsten, dass das übermittelte Signal unvollständig 
oder überhaupt kein Signal ist.

Wenn Du keine Sensoren hast, die MU-Nachrichten senden, dann kannst Du die MU-Nachrichten disablen.

Code Auswählen

set sduino3 disableMessagetype unsyncedMU

Nachtrag:

Zitat2016.06.03 21:03:45 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/00_SIGNALduino.pm line 856.

Du verwendest noch eine etwas ältere 00_SIGNALduino.pm die noch Fehler enthält.
Hast Du es schon mit der dev-Version versucht?

Gruß Ralf

DerStephan · 04 Juni 2016, 10:30:32

Hallo Ralf!

Zitat
Wenn Du keine Sensoren hast, die MU-Nachrichten senden, dann kannst Du die MU-Nachrichten disablen.
set sduino3 disableMessagetype unsyncedMU

Wow, das wars!!!!

Nachdem ich diese Funktion deaktiviert hatte, lief es sofort ohne Probleme! Neustarts des Raspi, shutdown-restart's, alles kein Problem mehr!

Jetzt stellt sich mir nur noch die Frage, habe ich hier irgendwelche Geräte in der Umgebung, die ständig derartige Meldungen absetzen oder gibts irgendwelche Störquellen, die als MU Signale gedeutet werden?

Auf jeden Fall schonmal vielen vielen Dank für die klasse Hilfe!

Als nächstes werde ich jetzt nochmal eine aktuellere Version flaschen und dann mal sehen, ob die anderen Fehler dann weg sind.

Stephan

DerStephan · 04 Juni 2016, 23:11:29

Hallo nochmal!

Mit dem Firmware- und Modulupdate sind die Perl-Fehler aus dem Log verschwunden, gute Sache!

Ich bin immer noch am schauen,welcher Funkverkehr die Blockade auslösen könnte. Ich habe mal einen DVB-TStick mit der HDSDR auf die Frequenz gesetzt und "zugeschaut", was da auf 433 MHz so los ist.
Da ist schon einiges los um den Frequenzbereich. Insgesamt ist der Bereich hier aber - glaub ich - HF mässig relativ sauber, die wahrscheinlichsten Übeltäter müssten die 4 Revolt Messstecker sein, die hier im Einsatz sind. Die Funken alle paar Sekunden ihre Werte raus, eine ziemliche Kakophonie . Ich glaube, die werden vom Signalduino nicht umgesetzt, oder?

Stephan

Ralf9 · 04 Juni 2016, 23:44:24

Zitat von: DerStephan am 04 Juni 2016, 23:11:29
Da ist schon einiges los um den Frequenzbereich. Insgesamt ist der Bereich hier aber - glaub ich - HF mässig relativ sauber, die wahrscheinlichsten Übeltäter müssten die 4 Revolt Messstecker sein, die hier im Einsatz sind. Die Funken alle paar Sekunden ihre Werte raus, eine ziemliche Kakophonie . Ich glaube, die werden vom Signalduino nicht umgesetzt, oder?

Welchen Empfänger verwendest Du? Hat er eine Abschirmung?
Das Senden alle paar Sekunden der Revolt dürfte nichts ausmachen.
Ich konnte nichts finden, daß die Revolt vom Signalduino erkannt werden.

Gruß Ralf

DerStephan · 05 Juni 2016, 10:10:05

Hallo Ralf!

Der Empfänger ist der "RXB6" mit Abschirmung. Wenn ich diese MU Erkennung wieder anschalte, passen die Signale aus HDSR zu den flackernden LEDs am Signalduino. Die - so glaube ich - "verstopfen" dann den Eingang in FHEM und blockieren die Oberfläche, wenn FHEM noch in der Initialisierungsphase war/ist.

Ich frage mic, ob es vielleicht möglich ist, den RX im Signalduino mit einem Befehl in der Firmware bei der Initialisierung in Richtung FHEM für ein paar Sekunden "stumm" zu schalten, sodass FHEM mit der Initialisierung durch ist, bevor der Datenstrom einsetzt? Dann müsste doch das Problem auch bei viel unbekanntem Betrieb auf 433 MHz gelöst sein,oder?

Stephan

Ralf9 · 05 Juni 2016, 10:25:50

Zitat von: DerStephan am 05 Juni 2016, 10:10:05
Der Empfänger ist der "RXB6" mit Abschirmung. Wenn ich diese MU Erkennung wieder anschalte, passen die Signale aus HDSR zu den flackernden LEDs am Signalduino. Die - so glaube ich - "verstopfen" dann den Eingang in FHEM und blockieren die Oberfläche, wenn FHEM noch in der Initialisierungsphase war/ist.

Kann Du mal einen log der Initialisierungsphase anfügen?

Zitat von: DerStephan am 05 Juni 2016, 10:10:05
Ich frage mic, ob es vielleicht möglich ist, den RX im Signalduino mit einem Befehl in der Firmware bei der Initialisierung in Richtung FHEM für ein paar Sekunden "stumm" zu schalten, sodass FHEM mit der Initialisierung durch ist, bevor der Datenstrom einsetzt? Dann müsste doch das Problem auch bei viel unbekanntem Betrieb auf 433 MHz gelöst sein,oder?

Du bist bis jetzt der erste der dieses Problem hat.

Gruß Ralf