Beide CUL Sticks sind plötzlich disconnected

[Aufsteigendes Talent]

Hallo,

ich habe ein echt eigenartiges Problem. Gestern Abend ist bei mir das Internet ausgefallen. Es gab wohl eine Störung beim Provider. Als ich währenddessen ein Licht im Haus anschalten wollte, hat es zwar funktioniert, aber mit etwas Verzögerung. Kurze Zeit später haben beide CUL Sticks bei mir nicht mehr funktioniert, bzw. werden in FHEM als disconnected angezeigt. Seit heut morgen geht das Internet wieder, die CUL Sticks aber nach wie vor nicht. (Ja ich weiß, dass es eigentlich unabhängig vom Internet ist, aber es hat genau dann angefangen, als das Internet nicht mehr ging komischerweise). Ich habe FHEM vor Jahren einmal komplett eingerichtet und seitdem nichts mehr gemacht. Auch kein Update oder Ähnliches in der letzten Zeit. Ich bin echt am Verzweifeln und verstehe überhaupt nicht woran das liegen kann Ich wäre für jede Hilfe sehr dankbar!

Die beiden CUL Sticks werden bei Linux aber anscheinend noch erkannt, wenn ich das richtig verstehe. Hier ein kleiner Auszug von der Stelle, wenn ich den Befehl "dmesg" in Linux eingebe:

[    2.091459] usb 1-1.3: new full-speed USB device number 4 using dwc_otg
[    2.248512] usb 1-1.3: New USB device found, idVendor=03eb, idProduct=204b
[    2.251547] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    2.254373] usb 1-1.3: Product: CUL433
[    2.257093] usb 1-1.3: Manufacturer: busware.de
[    2.361437] usb 1-1.4: new full-speed USB device number 5 using dwc_otg
[    2.508643] usb 1-1.4: New USB device found, idVendor=03eb, idProduct=204b
[    2.511453] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    2.514211] usb 1-1.4: Product: CUL868
[    2.516847] usb 1-1.4: Manufacturer: busware.de

[KölnSolar]

Die beiden CUL Sticks werden bei Linux aber anscheinend noch erkannt, wenn ich das richtig verstehe.Die beiden CUL Sticks werden bei Linux aber anscheinend noch erkannt, wenn ich das richtig verstehe.

Hast Du.
Stell butte mal ein list der CULs ein.

Grüße Markus

[Aufsteigendes Talent]

Hallo,

wie kann ich das den machen? Kenn mich mit Linux nicht wirklich sonderlich gut aus 

Grüße,
Tim

[rudolfkoenig]

Wenn die CULs von FHEM "einfach" (wie vom autocreate erkannt) ueber /dev/tty* angesprochen werden, dann kann es nach einem Neustart zu einer Vertauschung kommen, und dann versucht FHEM die 868MHz Geraete ueber das 433 CUL anzusprechen und andersherum, was wirkungslos ist. Der Neustart passierte womoeglich zeitgleich mit dem Internetausfall.

Siehe auch https://wiki.fhem.de/wiki/Mehrere_USB-Ger%C3%A4te_einbinden.

Mit list war ein FHEM list gemeint, das heisst "list CUL_1" ohne " in der FHEM Oberflaeche einzugeben.

[Aufsteigendes Talent]

Hallo,

danke für deine Antwort. Den Server habe ich aber schon oft neu gestartet, da gab es aber nie ein Problem damit.
Folgendes habe ich mit dem list Befehl bekommen:

CUL0:

Internals:
   CMDS       
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :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/ttyACM0@9600 1034
   DeviceName /dev/ttyACM0@9600
   FHTID      1034
   FUUID      5c6d3cea-f33f-9230-1ae1-cc6d23693c70d359
   NAME       CUL_0
   NR         26
   PARTIAL   
   STATE      disconnected
   TYPE       CUL
   initString X21
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     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......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:
     2020-07-24 09:03:57   raw             No answer
     2020-07-23 20:00:33   state           disconnected
Attributes:

CUL1:

Internals:
   CMDS       
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/ttyACM1@9600 1134
   DeviceName /dev/ttyACM1@9600
   FHTID      1134
   FUUID      5c6d3cea-f33f-9230-aa3a-15110ece56ef9404
   NAME       CUL_1
   NR         40
   PARTIAL   
   STATE      disconnected
   TYPE       CUL
   initString X21
Ar
   MatchList:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2020-07-22 09:58:39   cmds            A B b C e F G h i K k L l M m N R T t U u V W X x Y Z
     2020-07-23 20:00:33   state           disconnected
   helper:
Attributes:
   rfmode     HomeMatic

[Wernieman]

Nimm mal, den, welchen Du für  /dev/ttyACM1@9600 hälst, raus und starte neu. Schaue dann, ob wenigstens der eine Funktioniert.

Ich würde auch auf vertauschte CULS tippen.

Da die Reihenfolge von diversen internen Parametern der Hardware (Elkos, Widerstandswerte, Leistungskontakte etc) abhängen, welche sich durchs altern auch verändern, kann es zu solchen Änderungen kommen.

Aber bevor wir weitermachen, teste mal Deine Config mit nur einem CUL

Edit:
Rechtschreibung korrigiert

[Aufsteigendes Talent]

Hallo,

vielen Dank für deine Antwort! Ich habe nun den einen CUL gelöscht und neu gestartet aber der CUL_0 ist leider nach wie vor disconnected...

[MadMax-FHEM]

Ich denke gemeint war nicht löschen, sondern den CUL abstecken...

Den Link bzgl. einbinden mehrerer CUL hast du mal gelesen!?

Am besten einen CUL einstecken, ls -la /dev/serial/by-id und notieren und dann den anderen und auch notieren und dann eben by-id definieren...

EDIT: außer beide IDs sind gleich, dann by-path und NICHT mehr UMSTECKEN. Sieht aber nach Original-Busware azs, sollte dann mit by-id gehen...

Der genannte Test mit "raus nehmen" war um zu sehen, ob es tatsächlich daran liegt...

Jetzt kannst du ja mal einen CUL ziehen und booten und wenn das nicht geht, dann den anderen stecken lassen (also immer nur einen)...

Wenn das dann auch nicht geht, ist es evtl./verm. was anderes...

EDIT: und lists etc. bitte in "code-Tags" (das '#' im "Menü")...

Gruß, Joachim

[Aufsteigendes Talent]

Achso das habe ich falsch verstanden

den Link hab ich mir schonmal angeschaut aber ich habe jetzt testweise den einen CUL Stick den ich sowieso in FHEM gelöscht habe auch ausgesteckt und nochmal neu gestartet. Der andere ist aber immer noch nicht connected. Dann kann es daran ja eigentlich nicht liegen oder?  Ich habe jetzt momentan nur den CUL_0 angeschlossen.

[MadMax-FHEM]

Hast du nach dem Löschen auch gespeichert!?
Also VOR dem Neustarten!?

Code Auswählen Erweitern


list TYPE=CUL


Und wenn du sicher bist, dass wirklich nur noch einer in fhem configuriert ist, dann mal den einen stecken und booten und schauen...
...und dann den anderen.

Hast du initialUsbCheck deaktiviert!?

Gruß, Joachim

[Wernieman]

@MadMax

Danke für Deine Beiträge .. Du hast Erfasst, was ich Meine

@Aufsteigendes Talent
Welchen CUL hast Du denn in FHEM gelöscht, den /dev/ttyACM0 oder den 1?

[MadMax-FHEM]

Welchen CUL hast Du denn in FHEM gelöscht, den /dev/ttyACM0 oder den 1?

Stimmt, das abwechselnde Stecken macht nat. nur Sinn, wenn der ACM0 noch da ist, also nicht gelöscht wurde

Gruß, Joachim

[Aufsteigendes Talent]

Vielen Dank für eure ganzen Antworten. Echt toll, dass hier einem so geholfen wird

@MadMax
Ja ich habe vor dem Neustart gespeichert.
Folgendes bekomme ich bei

Code Auswählen Erweitern

list TYPE=CUL

Code Auswählen Erweitern

Internals:
   CMDS       
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :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/ttyACM0@9600 1034
   DeviceName /dev/ttyACM0@9600
   FHTID      1034
   FUUID      5c6d3cea-f33f-9230-1ae1-cc6d23693c70d359
   NAME       CUL_0
   NR         26
   PARTIAL   
   STATE      disconnected
   TYPE       CUL
   initString X21
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     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......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:
     2020-07-24 21:28:08   raw             No answer
     2020-07-24 20:26:14   state           disconnected
Attributes:

Ich habe beide schon mehrmals ein und wieder ausgesteckt, aber leider ohne Erfolg.
Autocreate ist bei mir deaktiviert. Hat das damit was zu tun? Bin mir gerade nicht mehr sicher, warum ich das damals so eingestellt hatte.

@Wernieman
Ich habe den /dev/ttyACM1 gelöscht. Also den CUL_1.

Ich bin heute noch länger unterwegs und werde deshalb je nachdem vermutlich erst morgen wieder antworten können. Bis dahin Viele Grüße

[KölnSolar]

Ich fasse mal zusammen:
Die denkbare Problematik der "vertauschten" USB-Anschlüsse liegt hier nicht vor. Denn: Die CULs zeigen ein disconnected --> physisch nicht erreichbar.

Im Widerspruch dazu steht, dass Sie auf OS-Ebene aber gefunden u. auch mit den richtigen Treibern gestartet wurden.

[    2.091459] usb 1-1.3: new full-speed USB device number 4 using dwc_otg
[    2.361437] usb 1-1.4: new full-speed USB device number 5 using dwc_otg

Auch zeigt

2020-07-22 09:58:39   cmds            A B b C e F G h i K k L l M m N R T t U u V W X x Y Z

, dass der Stick zu diesem Zeitpunkt noch von FHEM erkannt wurde.

Ich würde nun folgende Dinge tun:

Den /dev/ttyACM0  CUL in FHEM auf verbose 5 setzen. Config speichern.
Reboot(nicht nur shutdown/restart von FHEM) des Systems.
Und dann nach ein paar min. Laufzeit folgende Infos posten:
- Logauszug von FHEM bzgl. des CUL
- Ausgabe von dmesg bzgl. des CULs(ich spekuliere, dass die Verbindung erfolgt, aber wieder verloren geht)
- Ausgabe von  ls -latR /dev/serial/by-id/

Alle Ausgaben so zeitgleich wie möglich.

Grüße Markus

[Wernieman]

Und was mir noch einfällt: Was ist es überhaupt für eine Hardwarebasis?

Wenn Raspi .. mal ein anderes Netzteil versucht?