Rasperry aus FHEM neu starten

[Marlen]

Ja, sorry. Das Problem besteht ja nicht regelmäßig.
Hab auch schon versucht das Problem heraus zu provozieren, aber nix zu machen!

Dem nach werde ich eine Checkliste erstellen und die beim nächsten mal abarbeiten!

Bis dahin......

LG
  Marlen

[Beta-User]

Eine Checkliste ist nicht schlecht, hilft aber nur, wenn Du Dir klarmachst, in welcher Reihenfolge Du beim Finden des eigentlichen Problems vorgehen mußt.

Da das Problem nach dem Software-Reboot weiterzu bestehen scheint, ist es vermutlich tatsächlich der nanoCUL, der sich aufhängt, bis er stromlos ist (was uU. nicht der Fall ist, wenn Du den PI rebootest). Binde das Ding also "by-id" ein, dann kannst Du testen, ob das Aus- und An-Stöpseln hilft...

Ich habe vorhin gesehen, dass Du gesehen hast, dass jemand ein ähnliches Problem hat, der schnell mehrere Somfy-Befehle versenden will.
=> Du mußt ja wissen, ob Du auch Somfy versenden willst (und ggf. wann/wie ein Massenversand ausgelöst wird)
=> für 433 MHz kann der nanoCUL auch mit der Signalduino-FW geflasht werden. Sofern Deine Geräte unterstützt werden, kann es eine gute Idee sein, das zu tun, tendenziell mit der aktuellsten Version (3.3.1) für die CC1101-Unterstützung.

[Marlen]

Also einfach das einfach das "by-id" bei der Definition mit hinzufügen oder wie?

Ich habe vorhin gesehen, dass Du gesehen hast, dass jemand ein ähnliches Problem hat, der schnell mehrere Somfy-Befehle versenden will. 

Ja, hab ich gelesen, weil es scheinbar das gleiche Fehlerbild ist " blinkender CUL".
Ich brauch nur 868 Mhz und nutze nur Homematic!

[Beta-User]

... (oder gleich auf "by-id" in der DEF umstellen; und bevor Du fragst, wie es geht: SUCHEN!)

Tip für's suchen: u.a. Tipp der Woche im Wiki...

Für die reine HM-Verwendung (das lese ich eben zum ersten Mal, wäre evtl. auch im anderen Thread interessant gewesen ) ist es besser, die orginal culfw zu nutzen. Wenn Du also die a-culfw drauf haben solltest...

- Was ist es für ein Nano?

Manche FTDI-China-Nanos haben einen nicht auf Ground geführten PIN (=>Lösung ist irgendwo hier im Forum, soweit ich mich erinnere: PIN23 und PIN24 zusammenlöten..., aber OHNE Gewähr).
[/quote]
...das mit der fehlenden Verbindung auf Ground führt dazu, dass der Nano nicht sauber resetet werden kann. Das könnte u.U. die Ursache allen Übels sein, nur so am Rande... Das kann man aber nur beantworten, wenn man Infos zum Nano hat...

[Marlen]

Hab gerade die Def für meinen CUL gefunden!

define nanoCUL CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AK059AEV-if00-port0@38400 0000

...also passt das "by-id" schon, oder?

Und da ist meines Wissens nach die orginal culfw drauf!

Also, beim nächsten Vorfall, zieh ich ihn mal 20 Sek. raus!

LG
  Marlen

[Beta-User]

  Die Definition sieht gut aus, dann kannst Du das mit den 20 sec auch lassen (weil er eindeutig adressiert wird!).

Und: Es ist ein FTDI! China-Ware? => PINs suchen und löten

[Marlen]

Ich würde mal sagen das das der ist, da gibt es kein 23 & 24

http://www.ebay.de/itm/Nano-3-0-Atmel-ATMEGA328P-Mini-USB-Board-w-USB-Kabel-fur-Arduino-/282126982335?hash=item41b0141cbf:g:NP8AAOSw9NdXp-xE

[gloob]

Es geht um folgende Pins. Einfach mal beide gegen Masse (GND) messen, wenn du kannst.

[Beta-User]

Irgendwas paßt da nicht zusammen:

define nanoCUL CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AK059AEV-if00-port0@38400 0000

Ich würde mal sagen das das der ist, da gibt es kein 23 & 24
http://www.ebay.de/itm/Nano-3-0-Atmel-ATMEGA328P-Mini-USB-Board-w-USB-Kabel-fur-Arduino-/282126982335?hash=item41b0141cbf:g:NP8AAOSw9NdXp-xE

Du mußt auf die Rückseite sehen: Ist Dort ein länglicher Chip mit je 8 oder 9 PINs (Beschriftung typischerweise WCH340, dann kann aber eigenlich Deine Definition nicht passen, siehe Ausgabe von ls -l /dev/serial/by-id) oder eben einer mit mehr PINs (Beschriftung FTDI ...), wie auf gloobs Beitrag abgebildet?

[Mitch]

Hab dann eine alte fhem cfg geladen und dann wieder die aktuelle, dann ging es wieder!

Mal davon abgesehen, dass hier wohl einiges "quer" läuft, macht mich diese Aussage noch stutzig.
Was genau heißt, die alte geladen und dann wieder nie neue?

cfg File alt kopiert, fhem neu gestartet?
cfg File neu kopiert, fhem neu gestartet?

Oder cfg alt kopiert, fhem neu gestartet und dann cfg neu kopiert? Dann wird die neue cfg gar nicht benutzt.

Vorauf ich hinaus will:
Ich vermute fast, du hast weder ein HW Problem, noch ein Strom oder CUL Problem, ich glaube du hast ganz einfach "Murks" in deiner cfg.

[frank]

Ja, hab ich gelesen, weil es scheinbar das gleiche Fehlerbild ist " blinkender CUL".
Ich brauch nur 868 Mhz und nutze nur Homematic!

in fhem.log gibt es keine hinweise? auch nicht mit global verbose 5?
wirklich nur die blinkende led?

[Marlen]

Guten Morgen,

ja, der eBay-Link ist der falsche Chip! Ich hab schon den wie auf den Bild von gloob! Und auch die Pin's sind bei mir gebrückt!

Also passt hardwaremäßig alles mit meinen nanoCul und def....mit "by-id" hab ich auch!

@Mitch bzw. @all:
Das eine Problem ist, das der nanoCUL "hängt/blinkt" ...bis jetzt noch nicht nachvollziehbar warum in unregelmäßigen Abständen aber eben neu 1-2 mal im Monat!
-Meine Lösung bisher: Ich bin über die Konsole rein und hab mit  "sudo shutdown -r 0" eine Neustart gemacht und alles ging wunderbar! <-- das geht aber nur wenn ich zu Hause bin + gerade Zeit habe und halt manuell!

Meine Wunschlösung: ...natürlich das der Fehler garnicht erst auftritt aber wenn dann möchte ich per Telegram benachrichtigt werden um dann per Telegram eine Neustart des Raspberry auszulösen.
Wenn ich das aber mit System({"sudo shutdown -r")} mache, hab ich das Problem das mein System hängt und ich kaum noch irgendwie ran komme, da ständig die Verbindung zusammen bricht und wenn dann alles ewig langsam geht. Auch ein "sudo shutdown -r über die Konsole hat keine Veränderung gebracht.
Wenn ich aber dann eine ältere fhem.cfg aufs Rasp spiele und reboote, läuft alles wieder, allerdings mit dem alten stand. Dann hab ich wieder die aktuelle fhem.cfg aufs Rasp und nach einen erneuten Neustart läuft alles wieder!

Ich glaube nicht das das eine "blinkender nanoCUL" etwas damit zu tun hat das es nach dem System({"sudo shutdown -r")} zu tun hat!
Ich könnte ja einfach mal wenn der nanoCUL normal läuft ein  System({"sudo shutdown -r")} auslösen......aber ich hab halt angst das dann wieder nichts mehr geht.
Ich hab mal im Forum gelesen das FHEM doppelt ausgeführt ist....vielleicht ist das ja auch bei mir der Fall!

LG Marlen

[Mitch]

Hm, so ganz schlau werde ich immer noch nicht.

Für dein "Bootproblem" würde ich mir einfach einen Script anlegen, der mir "sudo shutdown -r now" ausführt und diesen dann aus fhem aufrufen, z.B. "/opt/fhem/reboot_script.sh"
Damit das root Passwort nicht eingegeben werden muss, entsprechenden Eintrag in suedor machen.

[Fixel2012]

Hallo,

wäre es nicht angebracht den Title deiner Frage zu ändern, "Rasperry aus FHEM neu starten" passt hier wohl nicht mehr so gut?

Grüße Fixel

[Fixel2012]

Wenn ich das aber mit System({"sudo shutdown -r")} mache, hab ich das Problem das mein System hängt und ich kaum noch irgendwie ran komme, da ständig die Verbindung zusammen bricht und wenn dann alles ewig langsam geht. Auch ein "sudo shutdown -r über die Konsole hat keine Veränderung gebracht.

Habe gestern mal versucht mir einen Raspberry reboot dummy zu machen, hab das selbe Problem. Der Raspberry Fährt runter aber nicht mehr hoch. Auch per SSH ist er dann nicht mehr erreichbar. Also hilft nur Stecker raus und wieder rein.

Werde das dann wohl so lösen:

Für dein "Bootproblem" würde ich mir einfach einen Script anlegen, der mir "sudo shutdown -r now" ausführt und diesen dann aus fhem aufrufen, z.B. "/opt/fhem/reboot_script.sh"
Damit das root Passwort nicht eingegeben werden muss, entsprechenden Eintrag in suedor machen.

Allerdings verstehe ich nicht, warum das über Fhem mit {system (.... nicht funktioniert.

Grüße Fixel