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:
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:
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
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.
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:
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?
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?
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32/controls_signalduino.txtGruß Ralf
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. :D . 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! 8)
Stephan
Mir fällt noch ein: kritische Versorgungsspannung.
Evtl können nicht alle Komponenten mit stabiler Spannung versorgt werden und liefern dadurch Störsignale ab.
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
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:
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)
Es gibt anscheinend ziemlich viele von diesen MU Messages?!
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?
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:
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.
set sduino3 disableMessagetype unsyncedMUNachtrag:
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
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!!!! 8) 8) 8)
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! :D
Als nächstes werde ich jetzt nochmal eine aktuellere Version flaschen und dann mal sehen, ob die anderen Fehler dann weg sind.
Stephan
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
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
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
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
Hallo Ralf!
Wenn ich der einzige bin mit dem Problem, muss es ja an meinen Gerätschaften liegen! Da muss ich dann mal Teil für Teil durchgehen. 3A Netztteil für den Raspi ist schon bestellt, dann ist der Arduino dran. Die Atmels werden glaub ich nicht gefälscht, bleiben noch FT232 und der Quarz für den Atmel als potentielle Fehlerquellen. Gibts irgendwo eine Quelle für gute Nano's?
Dort hatte ich die Initialisierungsphase als log angehängt (noch mit einer älteren Signalduino-Version)
Zitat von: DerStephan am 03 Juni 2016, 20:52:21
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)
Ich bleibe dran und melde mich, wenn ich die Komponenten ausgetauscht habe.
Stephan
Zitat von: DerStephan am 06 Juni 2016, 09:44:11
Dort hatte ich die Initialisierungsphase als log angehängt (noch mit einer älteren Signalduino-Version)
In dem log fehlen die MU-Nachrichten. Ein log mit verbose 4 wäre aussagekräftiger.
Gruß Ralf
Hallöchen,
habe den Thread zufällig entdeckt. :)
Also das der Signalduino oft meldet, dass er initalized ist, das ist normal.
Das wird jedesmal gesetzt (um ein Event zu generieren), wenn eine Nachricht empfangen wurde. Liest sich im Log leider etwas missverständlich.
Zum Thema Initalisieren nach dem Starten.
Also, wenn der SIGNALduino dauerhaft was empfängt und das empfangene dauernd an FHEM übergibt, dann ist es denkbar, dass das Initialisieren nicht funktioniert.
Wir könnte dazu tatsächlich, das Auswerten von Signalen komplett deaktivieren und nach der Initialisierung wieder aktivieren.
Das würde dein Problem bestimmt lösen. Geht bei der Initialisierung etwas schief, läuft die Signalauswertung halt bis zum Nächsten Reset vom Arduino nicht.
Ich denke, das ist vertretbar.
Grüße Sidey
Hallo Sidney,
ja, ich glaube, genau das passiert hier. Zu viele Geräte auf 433 MHz ;)
Wenn Du sowas einbauen könntest, wäre das ne klasse Sache! Ich schätze mal, früher oder später könnten auch andere mit dem Problem konfrontiert werden?!
Viele Grüße,
Stephan
Hi,
Hatte ich direkt mit meinem Post auch eingebaut.
Einfach mal ein Update der devr32 Version machen und mir berichten.
Grüße Sidey
Super Sache! Thx
Ich habe leider beim Updaten noch ein Problem: ich bekomme nach dem Update: update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32/controls_signalduino.txt
immer die Version "V 3.2.0-b24 SIGNALduino - compiled at May 14 2016 00:06:40"
Irgendwas mache ich noch falsch. Hat jemand einen Tipp für mich?
Viele Grüße,
Stephan
Wenn Du die neue Firmware flashen willst, dann musst Du den set flash Befehl anwenden.
Um das beschriebene Problem zu lösen ist ein Flashen allerdings nicht erforderlich. Schadet aber auch nicht.
Grüße Sidey
Hallo Sidney,
ja, dass ein flash hinterher kommen muss, war mir schon klar(und habe ich auch gemacht), ich dachte halt, dass es eine neue Firmware gäbe. :-[
Ich habs jetzt mal grob getestet, leider immer noch das selbe Problem: es geht erst, wenn ich die MU's deaktiviere. Ich werde morgen weiter schauen, ob ich Unterschiede finde im Verhalten.
Viele Grüße,
Stephan
Seltsam... hmm
Hi Sidney!
Meine Vermutung ist, dass der Signalduino nach seiner Initialisierung sofort mit dem "abfeuern" seiner Nachrichten beginnt und zwar so schnell, dass FHEM es (zumindest auf dem Raspberry) nicht schafft, ihn in der Konfiguration zu integrieren, bevor der Nachrichtenstrom einsetzt.
Ich habe hier auch ein paar nanoCul's im Einsatz mit Arduinos aus der selben Serie wie dem Signalduino-Nano. Dort tritt das Problem nicht auf. Ich habe mal versucht, herauszufinden, wo der Unterschied liegen könnte. Dabei ist mir aufgefallen, dass der NanoCul nach dem Anschluss an den die USB Schnittstelle von sich aus anscheinend keine Daten an die serielle Schnittstelle schickt. Jedenfalls zeigt der Serielle Monitor nichts an.
<Spekulationsmodus an> Kann es sein, dass der NanoCUL erst auf einen Befehl vom Host (FHEM) wartet, um die Datenaussendung zu beginnen? Das könnte erklären, warum dort das Problem nicht auftaucht: Nach dem Einstecken initialiert sich die Schnittstelle auf dem Nanocul und wartet dann quasi auf FHEM, bis es mit der Einbindung fertig ist und schickt erst dann Datensignale, wenn FHEM es dazu aufgefordert hat. <Spekulationsmodus aus>
Mein Gedanke ist deshalb, die Firmware so zu modifizieren, dass der Signalduino erst einige Sekunde nach seiner "Erstinitialisierung" nach dem Einstecken mit der Ausgabe von Nachrichten über die serielle Schnittstelle beginnt (wenn FHEM komplett durch ist mit seiner Initialisierung des Signalduino). Wäre sowas machbar (und sinnvoll)?
Viele Grüße,
Stephan
By the way: Gerade ist mir im Log aufgefallen: Kann der Signalduino jetzt auch Revolt?
2016.06.11 16:23:31.028 4: sduino: Matched MS Protocol id 45 -> revolt
2016.06.11 16:23:31.028 4: sduino: Decoded MS Protocol id 45 dmsg i491C88 length 24
Dann kann ich den NanoCul ja in Rente schicken, wenn der Signalduino dieses Format auch beherrscht (plus die vielen anderen) 8) 8) 8)
Das mit dem Delay könnte man so machen. Da muss ich mal nachdenken, wie man das mit relativ wenig Rechenpower realisieren könnte, dass nicht jedesmal geprüft wird, ob der uC gerade gestartet wurde.
Kannst Du mal mit Verbose 5 einen Startvorgang mitloggen. Eigentlich hätte ich erwartet, dass das Abschalten des Interrupts die Lösung schlechthin ist.
Zu Revolt: Naja ich habe etwas implementiert, das vielleicht das Revolt Protokoll ist. Scheinbar liege ich da ja nicht so falsch.
Wenns klappt, dann wird ein IT Device angelegt. Unter Umständen brauchst Du aber die angpasste IT Version von Ralf9.
Grüße Sidey