[Gelöst] Nanocul LED blinkt schnell

[Stippy19]

Hallo zusammen,

ich hab jetzt seit ein paar Monaten FHEM auf einem Raspy3 sowie ein Razberry2 (Z-Wave) samt Steckdosen und einen Nanocul für HomeMatic Thermostate und Türsensoren. Seit ein paar Wochen scheint sich der CUL immer wieder aufzuhängen und die CUL-LED fängt an extrem schnell zu blinken. Wenn ich den Raspy (samt CUL) vom Strom nehme und wieder anschließe funktioniert wieder alles für ein paar Stunden oder Tage. Es kam aber jetzt schon so häufig vor, dass es mich nervt.
Weiß jemand abhilfe?

Im Log sehe ich, dass FHEM versucht z.b. die Lampe einzuschalten, jedoch bekommt die Lampe nur "MISSING ACK"

Code Auswählen Erweitern

2017-06-13 14:52:02 CUL_HM Wohn_Esstischlampe set_on
2017-06-13 14:52:23 CUL_HM Wohn_Esstischlampe ResndFail
2017-06-13 14:52:23 CUL_HM Wohn_Esstischlampe MISSING ACK

[Beta-User]

Hallo Stippy,

die Forensuche nach dem von Dir gewählten Symptom im Titel liefert einiges an Treffern...

Was hast Du davon schon ausprobiert? (siehe https://forum.fhem.de/index.php/topic,71806.msg633579.html#msg633579)

Als Minimalansatz würde ich folgendes machen/prüfen:
- eindeutige Einbindung aller USB-Devices beim Start ("by-id"-Methode => Wiki, Tipp der Woche)
- ausreichende Spannungsversorgung? (aktiven Hub verwenden).

Gruß, Beta-User

[Stippy19]

Hallo Beta-User,

dann scheine ich wohl falsch gesucht zu haben  Ich konnte hierzu nicht wirklich viel finden. Bei den meisten sind es Initialisierungs/Flash Probleme, aber meiner funktioniert ja erst super.

Er funktioniert ja auch einwandfrei eine Zeit lang, bis er eben plötzlich nicht mehr funktioniert. Ich konnte noch nicht ausmachen, wann genau das Problem auftritt, es scheint irgendwie sporadisch nach ein paar Stunden oder sogar Tagen zu sein.

Ich betreibe am Raspy über USB nur den NanoCUL und den Raspy selbst mit einem 2,5A 5V Netzteil. Da wäre ich eigentlich bisher nicht von Problemen der Stromversorgung ausgegangen.

Ein Abziehen des Sticks und wieder einstecken bringt, dass die LED wieder wie gewohnt 1/s blinkt, jedoch ist der CUL in FHEM dann "opened". Ein zusätzlicher FHEM Neustart bringt dann die Funktion wie gewohnt zurück.

Ein ccconf wirf im Fehlerfall nur sowas aus:

Code Auswählen Erweitern

Timeout reading answer for get C0D

Hier noch ein paar Daten:
- CH340 Basis
- Nur 1 CUL am USB, nichts anderes an USB angeschlossen
- Status in FHEM: Initialized
- CUL868HM ccconf => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
- CUL868HM version => V 1.67 nanoCUL433

Hier noch das "list NANOCUL" Ergebnis (im funktionierenden Zustand)

Code Auswählen Erweitern

Internals:
   CMDS       ABCEeFfGhiKklMmRTtUVWXxYZz
   CUL868HM_MSGCNT 3
   CUL868HM_TIME 2017-06-13 17:24:39
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:
   DEF        /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400 0000
   DeviceName /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5:1.0-port0@38400
   FD         12
   FHTID      0000
   NAME       CUL868HM
   NR         38
   NR_CMD_LAST_H 2
   PARTIAL
   RAWMSG     A0F4C861051303A0000000A78E90F000045
   RSSI       -39.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.67 nanoCUL433
   initString X21
Ar
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
   Readings:
     2017-06-13 17:23:36   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2017-06-13 17:23:23   cmds             A B C E e F f G h i K k l M m R T t U V W X x Y Z z
     2017-06-13 17:24:39   state           Initialized
     2017-06-13 17:23:59   version         V 1.67 nanoCUL433
   XMIT_TIME:
     1497367467.93259
     1497367468.73179
   Helper:
     5277a6:
       QUEUE:
Attributes:
   group      Dongles,HomeMatic
   hmId       F10000
   rfmode     HomeMatic
   room       99_System

Einbindung by-id würde ich gerne nicht tun, da ich planen einen weiteren CUL dranzumachen, der mit dem CH340 dann die selbe ID haben wird. Lösung laut Wiki war dann die Verwendung von by-path.

Hier mal ein Schaltvorgang im funktionierenden Fall:

2017-06-13 17:36:29 CUL_HM Zimmer_Lampe set_on
2017-06-13 17:36:29 CUL_HM Zimmer_Lampe deviceMsg: on (to CUL868HM)
2017-06-13 17:36:29 CUL_HM Zimmer_Lampe level: 100
2017-06-13 17:36:29 CUL_HM Zimmer_Lampe pct: 100
2017-06-13 17:36:29 CUL_HM Zimmer_Lampe on
2017-06-13 17:36:29 CUL_HM Zimmer_Lampe timedOn: off
2017-06-13 17:36:39 CUL_HM Zimmer_Lampe set_off
2017-06-13 17:36:39 CUL_HM Zimmer_Lampe deviceMsg: off (to CUL868HM)
2017-06-13 17:36:39 CUL_HM Zimmer_Lampe level: 0
2017-06-13 17:36:39 CUL_HM Zimmer_Lampe pct: 0
2017-06-13 17:36:39 CUL_HM Zimmer_Lampe off
2017-06-13 17:36:39 CUL_HM Zimmer_Lampe timedOn: off

Sobald ich den Fehlerfall wieder habe, nehme ich da auch mal das erweiterte Log auf.

[RaspiLED]

Hi,
dein Fehler liegt daran, dass sich die Firmware aufhängt bzw. einen Reset durchführt.
Mach doch mal
set CUL868HM raw e
Ist es so ein blinken?

Lösungsidee: Teste mal die aktuelle a-culfw oder eine andere Version der culfw!

Warum eigentlich:
CUL868HM version => V 1.67 nanoCUL433

Gruß Arnd

Gesendet von meinem SM-G800F mit Tapatalk

[Stippy19]

[...] dein Fehler liegt daran, dass sich die Firmware aufhängt bzw. einen Reset durchführt.
Mach doch mal
set CUL868HM raw e
Ist es so ein blinken?
[...]

Korrekt. raw e bringt ihn genau in den "Fehlerzustand". Ich hatte die FW von der Quelle aus dem Wiki genommen. Dort die eine Zeile auskommentiert, damit er auf 868 und nicht 433 MHz läuft. (Quelle: https://wiki.fhem.de/wiki/Selbstbau_CUL Unterpunkt Software)


Ist es eigentlich gewollt, dass im Wiki auf eine andere Version verwiesen wird, als im http://culfw.de/culfw.html?
Ich werde mal eine andere Version flashen versuchen und melde mich, ob es damit (dauerhaft) funktioniert.



/Edit: Jetzt hab ich seit 2 Tagen mal den CUL mit der culfw 1.66 geflasht dranhängen und bisher läuft er. Wenn das noch 2 Tage so weiter funktioniert, markier ichs mit [gelöst]. Vielen Dank schonmal euch!

/Edit2: Ja, funktioniert immer noch. Also dann war das tatsächlich die falsche/fehlerhafte Firmware bzw. Flashvorgang.

[thgorjup]

Hier wurde schon ewig nichts mehr geschrieben, aber die korrekte Lösung ist, dass man den Arduino Nano mit dem Optiboot Bootloader flashed.
Dieser bleibt nicht hängen und das Problem ist beseitigt.

[yersinia]

Auch wenn es ein alter Thread ist, möchte ich hier noch was ergänzen, wie man den Optiboot Bootloader realtiv simpel auf einen (bei mir) nano bekommt - daher hier eine Kopie aus einem anderen Thread, falls es jemand benötigt.

falls es mal jemand benötigt - meine nanos habe ich 2017 bestellt, wahrscheinlich laufen die mit dem alten, suboptimalen bootloader wie die meisten clones oder ältere Originale. Auf yt gibt es ein sehr gutes Video wie man den neuen bootloader relativ einfach mit einem weiteren nano und der Arduino IDE draufschreibt: Arduino Bootloader Update or Install - Upgrade a Clone From Old Bootloader to New Optiboot!
Wiring-diagram ist auf arduino.cc gut beschrieben (die Verbindungen sind identisch auch zwischen zwei nanos).

Optiboot unterstützt eine höhere Baudrate (alt: 57600; neu: 115200), um aculfw auf den nano zu flashen muss das entsprechend angepasst werden, zB:

Code Auswählen Erweitern

avrdude -p atmega328p -c arduino -P [COMPORT] -b 115200 -D -Uflash:w:./nanoCUL868.hex:i