[GELÖST] nanoCUL wechselt spontan von initialized auf opened

[thgorjup]

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.

Code Auswählen Erweitern


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

[RaspiLED]

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

[thgorjup]

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:

Code Auswählen Erweitern


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


[TomLee]

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😊

[RaspiLED]

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, ...

[thgorjup]

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.

[thgorjup]

Wo steht denn da "unbekannte Quelle" ?

[thgorjup]

Problem gelöst. Mein sduino hatte sich mit dem nanoCUL nicht vertragen.
Seitdem ich den nicht mehr verwende, bleibt der nanoCUL stabil.

[RaspiLED]

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, ...

[thaliondrambor]

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):

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[RaspiLED]

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, ...

[thaliondrambor]

Heute war es mal wieder soweit und ich habe mit verbose 5 mal ein reopen versucht. Folgendes steht dann im Log:

Code Auswählen Erweitern

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):

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[RaspiLED]

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, ...

[thaliondrambor]

Werde ich das nächste mal versuchen, wenn er wieder auf opened geht.

Gesendet von meinem SM-G930F mit Tapatalk

[RaspiLED]

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, ...