Hallo,
ich habe das Problem das sich mein NanoCUL sporadisch aufhängt. Die LEDs blinken dann ganz hektisch und die Verbindung zu FHEM ist nicht mehr vorhanden. Ich habe ein script gefunden mit dem ich die USB-Ports meines Raspi neustarten kann. Das wirkt dann wie NanoCUL abziehen und wieder anstecken. Das habe ich schon probiert und es funktioniert super.
Jetzt möchte ich das aber gern irgendwie automatisieren. Ich hatte mir gedacht ich frage die UPTIME des NanoCUL jede Stunde ab. Sobald ich keine Antwort bekomme oder sich die Uptime nicht ändert, führe ich das script aus. Ich stehe aber gerade total auf dem Schlauch wie ich mit einem DOIF die Uptime des NanoCUL abfragen kann. Kann mir da bitte jemand helfen? Ich komme auch mit der Commandref nicht weiter.
Danke schon mal
Zyklische Abfragen sehen eher nach 'at' aus...
...Zeit der letzten Änderung eines Readings bekommst du per ReadingsAge
Was es noch gibt ist das Monitoring-Modul...
https://forum.fhem.de/index.php?topic=68765.0
Gruß, Joachim
Sehe ich auch so. Konkret dürfte der nano nicht mehr den state=Initialized habendefine check at +*00:00:05 {if (ReadingsVal('nanoCUL','state','opened') ne 'Initialized') {.....}}
Zitatich habe das Problem das sich mein NanoCUL sporadisch aufhängt.
Welche firmware hast Du drauf, cul oder signalduino (welche version)?
Gruß Ralf
Was genau macht das Reset-Skript? Kannst du das mal posten? (Neugier)
NanoCUL selbst gebaut oder von Ebay? (um gefälschten FTDI auszuschliessen, der das Ding instabil macht...)
Hallo,
erst mal Danke für die vielen Antworten zu so später Stunde :D
Ich
KölnSolar: Genau das ist das Problem. Der Status des NanoCUL bleibt auf Initialized. Ich muss also händisch mit dem Befehl "Get NanoCUL Uptime" abfragen und bekomme dann "Keine Antwort" als Rückmeldung. Nur So kann ich wirklich feststellen ob der NanoCUL noch arbeitet oder nicht. Und hier ist gerade mein Knoten im Kopf. Wie frage ich den Wert des Befehls "Get NanoCUL Uptime" in einem Notify oder Doif ab?
Ralf9: Ich habe die Firmeware 1.67 drauf.
connormcl: Der Nanocul ist selbstgebaut. Das Skript habe ich von dieser Seite hier.https://www.computerhilfen.de/info/usb-reset-am-raspberry-pi-usb-ports-zuruecksetzen.html (https://www.computerhilfen.de/info/usb-reset-am-raspberry-pi-usb-ports-zuruecksetzen.html)
Nachtrag:
Ich habe es jetzt folgendermaßen mit einem Notify in den Griff bekommen:
{
my $r1 = fhem "get nanoCUL_868MHz uptime";;
if ($r1 eq "nanoCUL_868MHz uptime => No answer") {
{system 'sudo usbreset /dev/bus/usb/001/024 &'};;
}
}
Ich vermute mal es würde noch eleganter gehen, aber ich glaube es funktioniert so erst mal. Einziges Problem was ich jetzt noch sehe ist, das sich der USB Port ändert wenn man den nanoCUL mal abziehen und wieder ansteckt. Hätte da jemand eine Idee wie man das noch abfangen kann? Man Müsste ja irgendwie nachgucken auf welchem port die ID vom NanoCUL zugewiesen ist und das dann einer Variable übergeben, oder?
Gruß und Danke
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 (https://forum.fhem.de/index.php/topic,91900.0.html)), aber die CULs verlassen quasi nie den Initialized state, wenn der CUL sich selbst aufhängt. Ich bin gespannt auf neue Lösungen....
Nachtrag:
Zitat von: FEHMPiDi am 26 Juni 2019, 08:09:40Einziges Problem was ich jetzt noch sehe ist, das sich der USB Port ändert wenn man den nanoCUL mal abziehen und wieder ansteckt. Hätte da jemand eine Idee wie man das noch abfangen kann? Man Müsste ja irgendwie nachgucken auf welchem port die ID vom NanoCUL zugewiesen ist und das dann einer Variable übergeben, oder?
Ja, via /dev/serial/by-id (https://wiki.fhem.de/wiki/Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden) müsste das eigtl funktionieren.
Zitat von: yersinia am 26 Juni 2019, 09:53:35
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 (https://forum.fhem.de/index.php/topic,91900.0.html)), 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 (https://wiki.fhem.de/wiki/Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden) müsste das eigtl funktionieren.
Wenn by-id nicht geht, dann geht (normalerweise immer) by-path (man darf halt nicht "echt" umstecken)...
Bzgl. "kommt nie aus dem Status raus": beim Hochfahren von fhem ein Notify (global:INITIALIZED) mit entweder einem sleep (1-2-3-4-5min) und dann Prüfung, ob der CUL "gut" ist (ALLERDINGS: fhem-sleep!!! wegen blockieren), ansonsten -> Script ODER im Notify ein at (für 1-2-3-4-5min später) was dasselbe tut...
Gruß, Joachim
Zitat von: connormcl am 26 Juni 2019, 00:20:33
NanoCUL selbst gebaut oder von Ebay? (um gefälschten FTDI auszuschliessen, der das Ding instabil macht...)
Nicht immer ist ein Fake-FTDI das Problem, sondern (scheinbar gar nicht so selten) ein falsch verlöteter echter...
Kannst du mal die by-id-Ausgabe liefern bzw. mitteilen, ob es ein FTDI ist? Ggf. mal im FHEM-Wiki unter Arduino schauen, wie man das mit dem Test-PIN fixt (da muß man zwei PINs zusammenlöten, ist nicht schwer).
Zitat von: MadMax-FHEM am 26 Juni 2019, 10:12:23Bzgl. "kommt nie aus dem Status raus": beim Hochfahren von fhem ein Notify (global:INITIALIZED) mit entweder einem sleep (1-2-3-4-5min) und dann Prüfung, ob der CUL "gut" ist (ALLERDINGS: fhem-sleep!!! wegen blockieren), ansonsten -> Script ODER im Notify ein at (für 1-2-3-4-5min später) was dasselbe tut...
Ich muss mal schauen, möglicherweise vertu' ich mich auch (hab FHEM gerade nicht zur Hand...).
Initialized wird möglicherweise verlassen und auf
Connected umgestellt. Allerdings bekommt FHEM im laufenden Betrieb nicht (oder nur selten) mit, wenn der CUL sich aufhängt - der state wechselt nicht auf
Disconnected o.ä..
Ich kann es auch schwer testen - wenn ich den CUL manuell abziehe, bekommt FHEM das allerdings mit.
ZitatKölnSolar: Genau das ist das Problem. Der Status des NanoCUL bleibt auf Initialized.
OK, bei mir verabschiedet sich schon einmal der aktive USB-Hub und nicht immer wird der Stick dann neu erkannt. Dafür funktioniert es.
ZitatIch muss also händisch mit dem Befehl "Get NanoCUL Uptime" abfragen und bekomme dann "Keine Antwort" als Rückmeldung. Nur So kann ich wirklich feststellen ob der NanoCUL noch arbeitet oder nicht. Und hier ist gerade mein Knoten im Kopf. Wie frage ich den Wert des Befehls "Get NanoCUL Uptime" in einem Notify oder Doif ab?
Dann würd ich es mit ReadingsAge versuchen(Bsp.: alle 5s prüfen, ob länger als 1 min. nichts empfangen/wurde.
define check at +*00:00:05 {if (ReadingsAge('nanoCUL','state',61) > 60) {.....}}
Zitat von: yersinia am 26 Juni 2019, 11:52:10
Ich muss mal schauen, möglicherweise vertu' ich mich auch (hab FHEM gerade nicht zur Hand...). Initialized wird möglicherweise verlassen und auf Connected umgestellt. Allerdings bekommt FHEM im laufenden Betrieb nicht (oder nur selten) mit, wenn der CUL sich aufhängt - der state wechselt nicht auf Disconnected o.ä..
Ich kann es auch schwer testen - wenn ich den CUL manuell abziehe, bekommt FHEM das allerdings mit.
Hab nachgeschaut und nope,
initialized wird nicht verlassen. Hier ein List von einem nanoCUL:
Internals:
CMDS ABCEeFfGiKlMNRTtUVWXxZ
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A94H5T9K-if00-port0@38400 0000
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A94H5T9K-if00-port0@38400
FD 10
FHTID 0000
FUUID 5c443cea-f33f-3151-cc84-d7ba10e1ebdcec87
NAME nanoCUL_868_1
NR 22
NR_CMD_LAST_H 3
PARTIAL
RAWMSG A0FAE8610567A380000000A991AC8000024
RSSI -56
STATE 2019-06-26 17:38:55 Initialized
TYPE CUL
VERSION V 1.26.03 a-culfw Build: 300 (2018-04-15_20-15-39) nanoCUL868 (F-Band: 868MHz)
initString X21
Ar
nanoCUL_868_1_MSGCNT 19
nanoCUL_868_1_TIME 2019-06-26 17:38:55
owner_CCU VCCU
.attraggr:
.attreocr:
.*
.attrminint:
.clientArray:
CUL_HM
MatchList:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2019-06-26 17:33:47 Initialized
2019-06-26 17:34:02 cmds A B C E e F f G i K l M N R T t U V W X x Z
2018-12-13 18:00:49 disconnected
2018-12-13 18:00:49 fhtbuf No answer
2019-06-26 17:38:55 state Initialized
2019-06-26 17:38:02 uptime 0 00:04:01
2019-01-29 22:02:52 version V 1.26.03 a-culfw Build: 300 (2018-04-15_20-15-39) nanoCUL868 (F-Band: 868MHz)
2018-03-11 21:18:39 | Initialized
XMIT_TIME:
1561563321.86187
1561563322.09597
1561563413.48665
helper:
538A78:
QUEUE:
5C1CA0:
QUEUE:
Attributes:
DbLogExclude .*
event-on-change-reading .*
icon cul_868
rfmode HomeMaticUnd mein DOIF zur Überwachung:
(["^nanoCUL_:DISCONNECTED"] or
["^nanoCUL_:OPENED"] or
["^nanoCUL_:disconnected"] or
["^nanoCUL_:opened"])
({Log 2, "CUL $DEVICE ist ausgefallen; versuche reopen"})
(set $DEVICE reopen)
DOELSE ()Möglicherweise könnte man das mit readingsage machen und müsste die nanoCULs regelmässig pingen....aber wie?
für homematic devices solltest du besser auf die empfohlene ts_culfw https://forum.fhem.de/index.php/topic,24436.0.html (https://forum.fhem.de/index.php/topic,24436.0.html) wechseln.
vielleicht ist dort das verhalten dann auch anders.
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
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Zitatmüsste die nanoCULs regelmässig pingen....aber wie?
für none-homematic bzw. rfslow: Thermometer, zählerablesung...... ;D
Zitat von: RaspiLED am 26 Juni 2019, 20:09:00Hi,
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.
Zitat von: frank am 26 Juni 2019, 17:53:24für homematic devices solltest du besser auf die empfohlene ts_culfw https://forum.fhem.de/index.php/topic,24436.0.html (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 (https://wiki.fhem.de/wiki/CUL#Firmware) erwähnt, aber nicht bei Selbstbau-CUL (https://wiki.fhem.de/wiki/Selbstbau_CUL#Software).
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... (https://forum.fhem.de/index.php/topic,24436.msg945418.html#msg945418)) - und mir erschließen sich die Vorteil (noch) nicht.
Trotzdem vielen Dank für den Hinweis.
Zitat von: yersinia am 27 Juni 2019, 10:51:45
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... ;D ).
Zitat
Oo Im Wiki wird sie nur unter CUL (https://wiki.fhem.de/wiki/CUL#Firmware) erwähnt, aber nicht bei Selbstbau-CUL (https://wiki.fhem.de/wiki/Selbstbau_CUL#Software).
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)...
Zitat von: yersinia am 27 Juni 2019, 10:51:45
Die ts_culfw ist mir neu - wo wird diese empfohlen? Oo Im Wiki wird sie nur unter CUL (https://wiki.fhem.de/wiki/CUL#Firmware) erwähnt, aber nicht bei Selbstbau-CUL (https://wiki.fhem.de/wiki/Selbstbau_CUL#Software).
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... (https://forum.fhem.de/index.php/topic,24436.msg945418.html#msg945418))
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"...
Zitat von: yersinia am 27 Juni 2019, 10:51:45
- 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
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
Zitat von: yersinia am 26 Juni 2019, 09:53:35
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 (https://forum.fhem.de/index.php/topic,91900.0.html)), 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 (https://wiki.fhem.de/wiki/Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden) 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
Hi,
Du nutzt das falsch. Richtig wäre:
usbreset /dev/bus/usb/001/002
Wenn lsusb folgendes zeigt:
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, ...
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 (https://forum.fhem.de/index.php?topic=73144.0)