Hallo,
ich habe das Problem, dass mein nanoCUL alle paar Tage spontan mal von "initialized" auf "opened" wechselt und dann nicht mehr funktioniert.
Einzige Möglichkeit ist dann den nanoCUL auszusteken, wieder einzustecken und FHEM neu zu starten.
Ich habe schon folgenden Trick probiert um USB stromlos zu machen.
echo 0 > /sys/devices/platform/soc/3f980000.usb/buspower && sleep 5 && echo 1 > /sys/devices/platform/soc/3f980000.usb/buspower
/etc/init.d/fhem stop
/etc/init.d/fhem start
Aber das funktioniert leider nicht. Hat jemand eine andere Idee?
Gruß
Thomas
Hi,
Wie ist der Nano aufgebaut? Fake FTDI oder ohne Spannungsteiler?
Und ein Reopen reicht nicht, richtig?
Meine Glaskugel sagt: Test Pin am FTDI ist nicht mit GND verbunden.
Problem ist z.B. hier erläutert: http://aqua-grow.de/arduino-probleme-mit-china-clones/
Gruß Arnd
Gesendet von meinem SM-G800F mit Tapatalk
Hmm, das ich garnicht sagen. Ich habe das Teil in ebay gekauft und es ist ordntlich verschweißt.
Ein reopen klappt leider nicht. Hier das LIST dazu:
Internals:
CMDS BCFiAZEkGMKUYRTVWXefltx
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A505KVSN-if00-port0@38400 0000
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A505KVSN-if00-port0@38400
FD 5
FHTID 0000
NAME nanoCUL
NR 35
NR_CMD_LAST_H 3
PARTIAL
RAWMSG A0FAA80024E0A9FF1000001010A003B0A16
RSSI -63
STATE Initialized
TYPE CUL
VERSION V 1.66 nanoCUL868
initString X21
Ar
nanoCUL_MSGCNT 2636
nanoCUL_TIME 2017-07-07 17:20:32
owner_CCU VCCU
Matchlist:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
Readings:
2017-07-07 17:15:08 cmds B C F i A Z E k G M K U Y R T V W X e f l t x
2017-07-07 17:20:28 raw is0000000F0FF0
2017-07-07 17:20:32 state Initialized
XMIT_TIME:
1499440826.72361
1499440831.3323
1499440832.21194
Helper:
43c2f3:
QUEUE:
450acf:
QUEUE:
466da0:
QUEUE:
495bf1:
QUEUE:
4d035f:
QUEUE:
4e0a9f:
QUEUE:
4efc0d:
QUEUE:
4fab31:
QUEUE:
4fb569:
QUEUE:
505381:
QUEUE:
5222e6:
QUEUE:
52c606:
QUEUE:
Attributes:
group CUL
hmId F10000
icon cul_868
rfmode HomeMatic
Vlt. ist's ja so banal wie bei mir. Hatte ebenfalls über längere Zeit dieses Phänomen. Einfach mal andere USB-Leitung verwenden. Die günstigen aus China sind meist Schrott. Meine Erfahrung bisher. Der Leitungsquerschnitt ist so minimal da kann nur ein "Wackler" nach mehrmaligem bewegen entstehen😊
Hi,
Also aus List sehe ich FTDI unbekannte Quelle hört sich nach Test PIN Problem an. Mach mal ein Foto von Stick, vielleicht können wir Dir sagen wer den gebaut hat ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Also gebaut hat ihn ein Stefan F. und ich habe noch weitere CUL's bei ihm gekauft. Ich werd ihn mal anschreiben und fragen ob er das Problem kennt und ob es China Arduino's sind. Ich mach demnächst ein Foto und poste es hier.
Wo steht denn da "unbekannte Quelle" ?
Problem gelöst. Mein sduino hatte sich mit dem nanoCUL nicht vertragen.
Seitdem ich den nicht mehr verwende, bleibt der nanoCUL stabil.
Hi thgorjup,
Erstmal schön wenn es läuft, ABER:
Und warum? Sind beides FTDI oder CH340? Oder liegt es an der Spannungsversorgung an den USB Ports eines Pi ohne aktiven Hub oder hat der eine empfangen was der andere sendet, aber sich dabei aufgehangen???
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Hallo,
ich habe ein ähnliches (gleiches?) Problem. In unregelmäßigen Abständen geht mein CUL (433MHz) auf "opened" und nur ein Neustarten von FHEM bzw. Linux kann das beheben (manchmal auch erst nach mehrmaligem neustarten). Ganz selten passiert das auch bei dem CUL mit 868MHz.
Zu meiner Konstellation: FHEM läuft in einer Linux-VM auf einem NUC. Dort hängen an einem aktiven Hub jeweils ein CUL und ein Jeelink für je 433MHz und 868MHz. Alles nicht selber gebaut (busware und jeelabs). Diese sind in der VM eingebunden (Device 006 ist das Bluetooth-Gerät des NUC):
lsusb
=>
Bus 001 Device 006: ID 8087:0a2a Intel Corp.
Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 003: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Bus 001 Device 002: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Alle vier Sender/Empfänger haben unterschiedliche IDs:
ls /dev/serial/by-id
=>
usb-busware.de_CUL433-if00 usb-busware.de_CUL868-if00 usb-FTDI_FT232R_USB_UART_AL006PX5-if00-port0 usb-FTDI_FT232R_USB_UART_AL006UM1-if00-port0
An den USB-Ports des NUCs hängen sonst noch Funktastatur/-maus und eine USB-Festplatte, welche aber nicht in die VM eingebunden sind.
Die Abstände in denen es passiert sind unterschiedlich. Mal ist es nur ein Tag, mal sind es vier bis fünf bis es wieder passiert.
Ein list vom CUL gibt folgendes:
Internals:
CFGFN
CHANGED
CMDS BCFiANEkGMKUYRTVWXefmLltux
CUL_433_MSGCNT 1
CUL_433_TIME 2017-08-05 22:07:36
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF /dev/serial/by-id/usb-busware.de_CUL433-if00@9600 1134
DeviceName /dev/serial/by-id/usb-busware.de_CUL433-if00@9600
FD 71
FHTID 1134
NAME CUL_433
NEXT_OPEN 1501963650.77509
NR 221
PARTIAL
RAWMSG i0541540B
RSSI -68.5
STATE Initialized
TYPE CUL
VERSION V 1.20.01 a-culfw Build: 176 (2015-12-07_23-24-58) CUL433 (F-Band: 433MHz)
initString X21
MatchList:
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04....(1|5|9).a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
L:CUL_REDIRECT ^o+
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2017-08-05 22:07:36 cmds B C F i A N E k G M K U Y R T V W X e f m L l t u x
2017-08-05 22:07:47 raw is0000FFFFFFF0
2017-08-05 22:07:36 state Initialized
2017-04-07 05:10:23 version No answer
Attributes:
event-on-change-reading state
room Empfänger
Ich werde beim nächsten Auftreten mal mit Verbose 5 schauen, was passiert, wenn ich ein reopen versuche. Irgendwo muss er ja hängen bleiben.
Falls jemand eine andere Idee hat, gerne her damit.
Gruß
thaliondrambor
Hi,
Bei Nachbauten hätte man auf gefälschte FTDIs spekuliert, evtl. auf fehlende Verbindung zwischen dem TEST Pin und Ground.
Bei original USB Sticks sollte es daran ja nicht liegen.
Die Frage ist ja auch, warum geht der Stick auf "nur opened".
Was hast Du in so einer Situation schon alles zur Reinitialisierung versucht?
A) set <dev> reopen (Eventmonitor beobachten)
B) FHEM shutdown, restart (FHEM log beobachten)
C) USB Port reset, vgl. https://gist.github.com/3174438 (dmesg -w beobachten)
D) Gerät rausziehen, 3 Sekunden warten, reinstecken (dmesg -w beobachten)
E) Linux reboot (Linux Logdateien beobachten
F) VM neustart
(VM Logdateien beobachten)
G) NUC neustart
Was ist denn zur Spannungsversorgung zu sagen? Ein Hub mit welchem Netzteil? Hast Du das Problem auch mit zwei Hubs? Oder stärkerem Netzteil? Oder mit dicken Elkos am Hub als Kurzzeitpuffer?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Heute war es mal wieder soweit und ich habe mit verbose 5 mal ein reopen versucht. Folgendes steht dann im Log:
2017.08.06 16:22:15 3: Setting CUL_433 serial parameters to 9600,8,N,1
2017.08.06 16:22:15 5: SW: V
2017.08.06 16:22:18 5: SW: V
2017.08.06 16:22:22 5: SW: V
2017.08.06 16:22:55 1: Cannot init /dev/serial/by-id/usb-busware.de_CUL433-if00, ignoring it (CUL_433)
Und ausgestiegen ist er mit (verbose war noch auf 1):
2017.08.06 14:05:47 1: /dev/serial/by-id/usb-busware.de_CUL433-if00 disconnected, waiting to reappear (CUL_433)
2017.08.06 14:06:57 1: Cannot init /dev/serial/by-id/usb-busware.de_CUL433-if00, ignoring it (CUL_433)
Selbiges finde ich auch, wenn FHEM oder Linux neugestartet wird und der CUL immer noch nicht geht.
Ein "erfolgreicher" Neustart scheint folgendes zu ergeben:
2017.08.06 16:25:40 1: /dev/serial/by-id/usb-busware.de_CUL433-if00 disconnected, waiting to reappear (CUL_433)
2017.08.06 16:26:43 5: SW: is0FFFF00FFFF0
2017.08.06 16:26:44 5: SW: is00FFF000FF0F
2017.08.06 16:26:45 5: SW: is0FFFF000FF0F
2017.08.06 16:26:47 3: Setting CUL_433 serial parameters to 9600,8,N,1
2017.08.06 16:26:47 5: CUL/RAW (ReadAnswer): i0541510C
2017.08.06 16:26:47 4: CUL_Parse: CUL_433 i0541510C -68
2017.08.06 16:26:47 5: CUL_433: dispatch i054151
2017.08.06 16:26:47 4: CUL_433 IT: message "i054151" (7)
2017.08.06 16:26:47 4: CUL_433 IT: msgcode "00FFF00FFF0F" (12) bin = 000001010100000101010001
2017.08.06 16:26:47 5: CUL_433 IT: V1 housecode = 00FFF00FFF onoffcode = 0F
2017.08.06 16:26:47 4: CUL_Parse: CUL_433
2017.08.06 16:26:47 1: PERL WARNING: Exiting subroutine via next at ./FHEM/00_CUL.pm line 864.
2017.08.06 16:26:47 5: SW: V
2017.08.06 16:26:47 5: CUL/RAW (ReadAnswer): V 1.20.01 a-culfw Build: 176 (2015-12-07_23-24-58) CUL433 (F-Ban
2017.08.06 16:26:47 5: CUL/RAW (ReadAnswer): d: 433MHz)
2017.08.06 16:26:47 5: SW: ?
2017.08.06 16:26:47 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B C F i A N E k G M K U Y R T V W X
2017.08.06 16:26:47 5: CUL/RAW (ReadAnswer): e f m L l t u x
2017.08.06 16:26:47 3: CUL_433: Possible commands: BCFiANEkGMKUYRTVWXefmLltux
2017.08.06 16:26:47 5: SW: X21
2017.08.06 16:26:47 5: SW: T01
2017.08.06 16:26:47 5: CUL/RAW (ReadAnswer): 1134
2017.08.06 16:26:47 5: GOT CUL fhtid: 1134
2017.08.06 16:26:47 1: /dev/serial/by-id/usb-busware.de_CUL433-if00 reappeared (CUL_433)
Auffällig ist, dass beim erfolglosen Reopen dreimal "SW: V" dort steht und wenn es geht drei unterschiedliche Codes.
Ich bin momentan nicht zu Hause und kann deswegen die meisten Sachen nicht überprüfen.
Was ich bis jetzt beobachtet habe:
-FHEM reboot geht manchmal
-Linux reboot geht meistens, aber auch nicht immer
-NUC neustarten geht immer
-VM neustarten bin ich mir nicht ganz sicher, aber ich bin der Meinung, dass es auch immer geht
Wenn ich wieder zu Hause bin, werde ich mal schauen, ob es hilft, wenn ich den CUL aus der VM auswerfe und wieder einbinde. Wenn ich ihn hart ziehe (ohne ihn vorher auszuwerfen), kann er manchmal nicht wieder in die VM eingebunden werden. Das spricht eigentlich dafür, dass es kein Problem mit der Stromversorgung ist, sonst wäre er ja ganz weg und müsste zumindest manchmal nicht mal mehr im Linux zu finden sein. Ich werde ihn aber dann trotzdem mal einzeln mit eigener Versorgung anstecken. (Das Netzteil für den Hub liefert 30W, also eigentlich mehr als ausreichend.)
Gruß
thaliondrambor
Hi, probiere doch bitte mal die Resetlösung des USB Sticks per Software in meinem Thread oben. Im Moment habe ich das Gefühl, das eine IT Nachricht reinkommt und sich der Nano dabei aufhängt und dann erst einen Reset braucht.
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Werde ich das nächste mal versuchen, wenn er wieder auf opened geht.
Gesendet von meinem SM-G930F mit Tapatalk
Hi,
Ja aber richte den usbreset schon mal ein. Muss ja kompiliert werden ;-)
Und stelle bitte das Device auf Verbose 5, damit wir verstehen warum die Firmware oder wann die Hardware hängt.
Danke und Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
So, jetzt habe ich den CUL mal wieder dabei erwischt. Es ist passiert, als ich einen Ausschaltbefehl senden wollte an eine IT-Steckdose. Folgendes stand im Log: 2017.08.14 08:27:07 5: SW: is00FFF00FFFF0
2017.08.14 08:27:07 5: CUL/RAW (ReadAnswer): is00FFF00FFFF0
2017.08.14 08:27:08 5: SW: is00FFF00FFF0F
2017.08.14 08:27:11 1: /dev/serial/by-id/usb-busware.de_CUL433-if00 disconnected, waiting to reappear (CUL_433)
2017.08.14 08:27:42 3: Setting CUL_433 serial parameters to 9600,8,N,1
2017.08.14 08:27:42 5: SW: V
2017.08.14 08:27:45 5: SW: V
2017.08.14 08:27:48 5: SW: V
2017.08.14 08:28:21 1: Cannot init /dev/serial/by-id/usb-busware.de_CUL433-if00, ignoring it (CUL_433)
2017.08.14 08:28:21 5: SW: is00FFF00FFF0F
2017.08.14 08:28:21 5: SW: is00FFF00FFF0F
Habe dann den USB-Reset durchgeführt und dmesg sagte dazu: [284893.568078] usb 1-2: reset full-speed USB device number 3 using ohci-pci
[284893.803115] cdc_acm 1-2:1.0: ttyACM1: USB ACM device
Ein Reopen im FHEM hat den CUL dann wieder zum Laufen gebracht. Im Log dazu folgendes: 2017.08.14 09:18:40 3: Setting CUL_433 serial parameters to 9600,8,N,1
2017.08.14 09:18:40 5: SW: V
2017.08.14 09:18:40 5: CUL/RAW (ReadAnswer): V 1.25.01 a-culfw Build: 257 (2017-07-14_17-38-58) CUL433 (F-Ban
2017.08.14 09:18:40 5: CUL/RAW (ReadAnswer): d: 433MHz)
2017.08.14 09:18:40 5: SW: ?
2017.08.14 09:18:40 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of A B C E e F G h i K k L l M m R T t
2017.08.14 09:18:43 1: /dev/serial/by-id/usb-busware.de_CUL433-if00 disconnected, waiting to reappear (CUL_433)
2017.08.14 09:18:43 3: CUL_433: Possible commands: Noanswer
2017.08.14 09:18:43 5: SW: X21
2017.08.14 09:18:43 5: SW: T01
2017.08.14 09:18:43 3: Setting CUL_433 serial parameters to 9600,8,N,1
2017.08.14 09:18:44 5: SW: V
2017.08.14 09:18:44 5: CUL/RAW (ReadAnswer): V 1.25.01 a-culfw Build: 257 (2017-07-14_17-38-58) CUL433 (F-Ban
2017.08.14 09:18:44 5: CUL/RAW (ReadAnswer): d: 433MHz)
2017.08.14 09:18:44 5: SW: ?
2017.08.14 09:18:44 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of A B C E e F G h i K k L l M m R T t
2017.08.14 09:18:44 5: CUL/RAW (ReadAnswer): U u V W X x Y
2017.08.14 09:18:44 3: CUL_433: Possible commands: ABCEeFGhiKkLlMmRTtUuVWXxY
2017.08.14 09:18:44 5: SW: X21
2017.08.14 09:18:44 5: SW: T01
2017.08.14 09:18:44 5: CUL/RAW (ReadAnswer): 1134
2017.08.14 09:18:44 5: GOT CUL fhtid: 1134
2017.08.14 09:18:44 1: /dev/serial/by-id/usb-busware.de_CUL433-if00 reappeared (CUL_433)
Der CUL scheint wohl tatsächlich irgendwie festzustecken. Ich kann aber keinen Grund erkennen.
Die Frage ist auch, ob es immer nur beim Senden passiert oder auch wenn Nachrichten empfangen werden.
FHEM schien nach dem Ausschaltbefehl auch circa eine Minute festzuhängen. Da ich allerdings per VPN verbunden war, kann ich nicht ganz ausschließen, dass es nicht an der Internetverbindung lag.
Vielleicht wird jemand anderes schlauer daraus.
Gruß
thaliondrambor
Hi, ja Sorry Dein Post ist mir durchgerutscht!
Also ich sehe auch nur, dass sich der CUL zwischen zweitem und dritten IT Paket aufhängt.
Als workaround könnte man auf das disconnect triggern und dann den usbreset und das reopen ausführen.
Schau mal hier: https://forum.fhem.de/index.php/topic,54628.msg461969.html#msg461969
Vielleicht hat Bjoernh oder jemand Anderes noch Ideen!?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...