Habe das Problem das mit dem Befehl shutdown & restart bzw. FHEM stop & FHEM start sich die Schnittstellen nicht mehr ordnungsgemäß anmelden.
Nur ein reboot oder Hardware Reset aktiviert wieder die Schnittstellen.
Wenn die Schnittstellen einmal laufen bleiben diese auch funktionsfähig bis zum neuerlichen shutdown & restart!
Ohne logeinträge, defines für die devices und mehr Infos zur Hardware ist das schwierig zu beantworten?
Ich äussere aber mal eine Vermutung, vielleicht kommen die USB-Einträge durcheinander und sind nach einem Restart erst wieder korrekt. Vielleicht hilft Dir der Trick mit der serial-id weiter?
Siehe dazu hier im wikie: http://fhemwiki.de/wiki/Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden (http://fhemwiki.de/wiki/Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden)
Das mit den serial-id war mir schon bekannt.
Anbei das Log File nach einem Neustart wo noch alle Schnittstellen funktionieren.
Vielleicht sieht man hieraus einen Fehler betreffend der Schnittstellen.
Hallo Chris,
aus dem log file kann ich zumindest kein Problem erkennen, aber das ist wie erwartet, denn es funktioniert ja alles. Ohne Probleme auch keine Lösung ;)
Also solltest Du vermutlich hier mal die log-Einträge der Probleme oder zumindest die Fehlermeldung posten.
Was mir in diesem Log auffällt ist das die Zeilen Enden nicht immer mit LF abschließen, sondern manche mit CR LF was eigenlich nicht Unixtauglich ist.
Oder spielt das bei Linux keine Rolle?
Ich denke nicht.
Das trifft so zb. bei den nanoCUL's zu, wo ich aber keinen Enfluß darauf nehmen kann.
So habe jetzt wieder so einen Fall.
Folgende Einträge im LOG wo die Schnittstellen nicht inizialisiert wurden.
Zitat
Cannot init
Initialization Error
PERL WARNING
Zitat von: Burny4600 am 28 Oktober 2015, 11:28:32
So habe jetzt wieder so einen Fall.
Folgende Einträge im LOG wo die Schnittstellen nicht inizialisiert wurden.
Die Einträge machen weniger Sorgen, die eigentlichen Probleme tauchen meines Erachtens davor auf.
Auch die CR/LF-Zeilenendungen kommen wohl so aus dem Arduino / nanocul und sind jetzt erstmal kein Problem...
Der nanocul433 kann initialisiert werden, erst beim nanocul868 gibt es Probleme.
Beim nanocul868 ist aus meiner Sicht der interessante Teil:
2015.10.28 11:19:51 3: nanoCUL868 device opened
2015.10.28 11:19:51 5: SW: V
2015.10.28 11:19:54 5: SW: V
2015.10.28 11:19:57 5: SW: V
2015.10.28 11:19:57 5: CUL/RAW (ReadAnswer): ? (V is unknown) Us
Da antwortet der nanoCul (also ist es kein Schnittstellenproblem) kann aber mit dem Kommando nichts anfangen, da er wohl statt nur "V" noch ein präfix aus zweimal "\x01" erhält.
Jetzt müsste man genauer herausfinden, warum da noch diese Zeichen an den CUL gesendet werden (und zwar wohl nur an den CUL868 ?). Sind da irgendwelche Initialisierungen vorher aus dem Log ist das nicht erkennbar...
Wenn der CUL868 nicht korrekt initialisiert wurde kannst Du testweise mal versuchen:
set nanoCUL868 reopen im FHEMWeb, vielleicht hst Du damit zumindest einen Workaround?
Johannes
Danke Johannes.
Mit set nanoCUL868 reopen kann ich den nanoCul wiederbeleben.
Aber ich muß mindestens diesen Befehl zweimal ausführen.
OK, das ist für den NanoCul schon mal ein Workaround, ich weiss allerdings nicht ob etwas ähnliches für den rfxtrx auch geht.
Ich muss zugeben ich bin überfragt, wo die 0x01 Bytes herkommen, die beim arduino ankommen. Soweit ich mich erinnere werden diese Bytes wohl gelegentlich zur Flusskontrolle verwendet sollten also eigentlich nicht übertragen werden.
Vielleicht must Du die Frage dochmal im CUL-Forum posten / doer den Beitrag verschieben?
Johannes
Wie verschiebe ich diesen Betrag?
Soweit ich weiss kann das ein Moderator also kannst Du vielleicht über "Moderator informieren" den Wunsch äussern.
Johannes