Überwachung NanoCUL

[yersinia]

Hi,
Euer Verhalten ist der klassische Test Pin Fehler des originalen (und oft kopierten) Layouts der Arduino Nanos mit FTDI Chip. Wie andere schon vor mir geschrieben haben, fehlt dem Test Pin die Verbindung zu Ground. Fix mit dem A(nalogen)GND daneben verbinden und gut ist es:

http://systemwork.in/index.php/technical-articles/33-how-to-fix-moody-arduino-nano

Kurios, da ich mit den nanoCULs keine Probleme bisher hatte mit Flashen etc. (Allerdings sei noch gesagt, dass die nanoCULs mind. einmal die Woche -wenn nicht sogar öfter- neu initialisiert werden durch einen shutdown restart nach fhem update). Die Verbindung ist stabil, nur in -bisher sehr- seltenen Fällen 'hängt' sich der nanoCUL auf (und dies nur bei den 868er, bei dem 433er habe ich bisher keine Probleme gehabt). Wenn sich dies häuft, werde ich mal schauen ob ich TST und GND zusammengelötet bekomme.

für homematic devices solltest du besser auf die empfohlene ts_culfw https://forum.fhem.de/index.php/topic,24436.0.html wechseln.

vielleicht ist dort das verhalten dann auch anders.

Die ts_culfw ist mir neu - wo wird diese empfohlen? Oo Im Wiki wird sie nur unter CUL erwähnt, aber nicht bei Selbstbau-CUL.
Im Verhältnis zu einer Einbindung mittels a-culfw scheint das Einbinden der ts-culfw deutlich komplexer/aufwendiger zu sein (-> händische Änderungen in der fhem.cfg? ich dachte, da steht der Tod drauf...) - und mir erschließen sich die Vorteil (noch) nicht.
Trotzdem vielen Dank für den Hinweis.

[Beta-User]

Kurios, da ich mit den nanoCULs keine Probleme bisher hatte mit Flashen etc.

Vorrangig ging es ja um das vom TE beschriebene Verhalten (wildes Blinken). Das ist typisch für diese Art bug, aber bisher haben wir keine Rückmeldung, ob das tatsächlich die passende Hardware ist...?

Neu war mir allerdings, dass man das tatsächlich mit einem software-Hack lösen kann (ich habe einen Lötkolben... ).

Oo Im Wiki wird sie nur unter CUL erwähnt, aber nicht bei Selbstbau-CUL.

Man kann Dinge immer "überall" hinschreiben, aber systematisch richtig ist es beim IO-Modul (CUL).
Und es steht auch noch an einer weiteren wichtigen Stelle (systematisch korrekt: https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale)...

[MadMax-FHEM]

Die ts_culfw ist mir neu - wo wird diese empfohlen? Oo Im Wiki wird sie nur unter CUL erwähnt, aber nicht bei Selbstbau-CUL.
Im Verhältnis zu einer Einbindung mittels a-culfw scheint das Einbinden der ts-culfw deutlich komplexer/aufwendiger zu sein (-> händische Änderungen in der fhem.cfg? ich dachte, da steht der Tod drauf...)

Bei den Homematic-IO-Devices sollte es erwähnt sein bzw. drauf hingewiesen werden...

EDIT: danke Beta-User für den Link

Es ist halt schwer bei allen "Querverbindungen" einen Hinweis zu platzieren...
...aber jeder der Homematic nutzt sollte zumindest im Homematic Wiki vorbeigestolpert sein und wenn er dann einen CUL hat (oder nutzen will / vor hat das zu tun)  und zwar egal ob fertig gekauft/"Original" oder Selbstbau...
...sollte das mal "gelesen" haben...

Ja ist aufwändiger, weil eben auch fhem-Module ersetzt werden müssen (leider immer noch nötig)...
Es muss nicht zwingend in der fhem.cfg geändert werden.
Es kann auch auf DEF geklickt und angepasst werden und auf jeden Fall geht "raw Definition"...

- und mir erschließen sich die Vorteil (noch) nicht.

Das Timing ist bei Homematic wichtig!
Und es ist, im Gegensatz zu vielen anderen Protokollen, "bidirektional": Befehl senden und ACK bekommen bzw. "Info" erhalten und "ACK" zurücksenden.

Wenn das ACK zu spät kommt, dann ist der Aktor/Sensor "beleidigt" und schickt noch mal etc. oder es kommt Timeout Register Read oder oder oder...

Bei einem CUL wird "ALLES" von fhem-Modulen erledigt, der CUL inkl. FW ist (mehr oder weniger) "nur" ein "dummes" Funkmodul...
..."auswerten" der Telegramme, evtl. notwendige Antwort (z.B. ACK) "zusammenbauen" etc. wird von fhem gemacht und wenn da mal was (kurz) hängt etc. dann kommt z.B. das ACK zu spät (siehe weiter oben   )...

Bei der Timing-FW sind verschiedene (zwischen)Zeitstempel etc. eingebaut, die versuchen (und es auch irgendwie schaffen   ) evtl. "Verzögerungen" zu "korrigieren" etc.

Wenn du es ganz genau wissen willst: Ansgar fragen (oder den Timing-FW-Thread lesen   )

Noch besser ist nat. ein "Original-Homematic-IO", weil das "simple" Antworten (gerade ACKs zu empfangenen Paketen) selbständig von der FW erledigt werden, davon bekommt fhem (fhem Module) gar nichts mit.
D.h. da kümmern sich die fhem Module "nur" um die tatsächlich "relaventen" Dinge (der Telegramme), der "Telegrammverkehr" wird automatisch durch das IO "geregelt"...

Das nur kurz zur Erläuterung...
Man möge mir etwaige "Ungenauigkeiten" verzeihen   aber das Prinzip und warum die Reihenfolge: CUL (kann gehen / kann aber auch Probleme machen), CUL mit Timing-FW (geht eigentlich gut, ist aber "aufwändig" und bei nanoCUL wird auch schon mal der Speicher eng) und dann eben "Original-HM-IO" sollte klar(er) werden...

Gruß, Joachim

[FEHMPiDi]

Hallo,

Vielen Dank für Eure Tipps. Ich könnte leider nicht antworten, da ich unterwegs war. Ich werde mir das mit dem testpin mal genauer anschauen und ggf. mit dem Gnd pin zusammenlöten.
Die Anderen Punkte schaue ich mir auch noch an und werde dann berichten was geholfen hat. Momentan funktioniert meine Lösung aber anscheinend. Zumindest bis ich den nanocul mal wirklich abziehen und wieder anstecke.

Gruß und Danke

[FEHMPiDi]

Ich hänge mich hier mal an. Das gleiche Problem habe ich sporadisch auch mit meinen nanoCULs (laufen allerdings mit a-culfw; siehe sig). Ich hatte mich mit einem DOIF beholfen (in Anlehnung an diesen Thread), aber die CULs verlassen quasi nie den Initialized state, wenn der CUL sich selbst aufhängt. Ich bin gespannt auf neue Lösungen....

Nachtrag:Ja, via /dev/serial/by-id müsste das eigtl funktionieren.

ls -l /dev/serial/by-id liefert bei mir folgendes:

ttyUSB2 ist der interessante.
lrwxrwxrwx 1 root root 13 Jun 24 19:57 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jun 26 09:41 usb-FTDI_FT232R_USB_UART_AI03D5UD-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 Jun 25 21:34 usb-FTDI_FT232R_USB_UART_AI03D7GP-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Apr 19 19:15 usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 -> ../../ttyUSB3

Rufe ich dann das Script auf bekomme ich folgende Fehlermeldung:

sudo usbreset /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D5UD-if00-port0
Resetting USB device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D5UD-if00-port0
Error in ioctl: Inappropriate ioctl for device

Wie schaffe ich es jetzt also immer den richtigen USB Stick mit dem Script anzusprechen auch wenn ich den Stick mal abgezogen habe. Der USB BUS ändert sich ja dann. Die ID bleibt immer die Gleiche (AI03D5UD). Hat jemand eine Ahnung wie man das Script anpassen müsste.

Danke

[RaspiLED]

Hi,
Du nutzt das falsch. Richtig wäre:

Code Auswählen Erweitern


usbreset /dev/bus/usb/001/002

Wenn

Code Auswählen Erweitern

lsusb folgendes zeigt:

Code Auswählen Erweitern


pi@printer:~ $ lsusb
Bus 001 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

https://www.computerhilfen.de/info/usb-reset-am-raspberry-pi-usb-ports-zuruecksetzen.html

Alternativ kannst Du auch alle Ports resetten

Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...

[Nitaro]

Ich stolper gerade mal über das Thema. Das hektische Blinken hatte ich auch.
Irgendwann bin ich dann auf die Lösung gestoßen

https://forum.fhem.de/index.php?topic=73144.0