Überwachung NanoCUL

[FEHMPiDi]

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

[MadMax-FHEM]

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

[KölnSolar]

Sehe ich auch so. Konkret dürfte der nano nicht mehr den state=Initialized haben

Code Auswählen Erweitern

define check at +*00:00:05 {if (ReadingsVal('nanoCUL','state','opened') ne 'Initialized') {.....}}

[Ralf9]

ich habe das Problem das sich mein NanoCUL sporadisch aufhängt.

Welche firmware hast Du drauf, cul oder signalduino (welche version)?

Gruß Ralf

[connormcl]

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

[FEHMPiDi]

Hallo,

erst mal Danke für die vielen Antworten zu so später Stunde 
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

Nachtrag:

Ich habe es jetzt folgendermaßen mit einem Notify in den Griff bekommen:

Code Auswählen Erweitern

{
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

[yersinia]

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:

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?

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

[MadMax-FHEM]

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.

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

[Beta-User]

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

[yersinia]

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

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.

[KölnSolar]

Kö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.

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?

Dann würd ich es mit ReadingsAge versuchen(Bsp.: alle 5s prüfen, ob länger als 1 min. nichts empfangen/wurde.

Code Auswählen Erweitern

define check at +*00:00:05 {if (ReadingsAge('nanoCUL','state',61) > 60) {.....}}

[yersinia]

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:

Code Auswählen Erweitern

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     HomeMatic

Und mein DOIF zur Überwachung:

Code Auswählen Erweitern

(["^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?

[frank]

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.

[RaspiLED]

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

[KölnSolar]

müsste die nanoCULs regelmässig pingen....aber wie?

für none-homematic bzw. rfslow: Thermometer, zählerablesung......