Hauptmenü

Problem bei Stomausfall

Begonnen von chaser, 22 September 2016, 19:58:13

Vorheriges Thema - Nächstes Thema

chaser

Hallo Zusammen,

hoffe jemand hat einen Hinweis. Meine Fhem läuft seit einem Jahr super und die Wikis haben mir bei den meisten Problemen bis jetzt sehr geholfen.

Jedoch bekomm ich einen Punkt nicht gelöst. Die Fhem läuft auf einem Raspberry Pi 3 und bei jedem (simulierten) Stromausfall setzt sich der CUL auf disconnected. Ein separater Restart der Fhem bringt keine Abhilfe. Erst wenn ich den CUL aus dem Raspberry rausziehe, reinstecke und die Fhem anschließend restarte setzt er sich wieder auf Initialized. Das ist natürlich bei einem echten Stromausfall und Abwesenheit recht suboptimal da keine Geräte angesprochen werden.

Hat jemand eine Lösung?

PS: Insgesamt hängen drei CULs dran für Homematic, sdunio (für Steckdosen) und ein JeeLink. Das Problem bleibt auch bestehen, wenn ich nur einen verwende.

wthiess

#1
"Am Hauptchip bin 3+4 zusammengelötet. Habe ich hier im Forum gelesen."

Hallo!
Hab das Problem gelöst, das "sduino" nach einem neustart vom Rasperrry auf "disconnected" steht. Erst durch ab und anstecken vom USB ist er wieder auf "open" und in Funktion.

Ich hab die beiden Drähte Rot +5V und schwarz GND durch ein Relais (2 Öffner) für 15 Sekunden beim start ausgeschalten.

Per GPIO
Hier der Byten Code der beim start ausgeführt wird.
#!/usr/bin/python
import RPi.GPIO as GPIO
import time
GPIO.setmode(GPIO.BCM)
GPIO.setup(20, GPIO.OUT)
GPIO.output(20, 0)
time.sleep(15)
GPIO.output(20, 1)
GPIO.cleanup()

Link zum Relais
https://www.amazon.de/Neuftech-8-Kan%C3%A4le-Relais-Modul-Brett-Arduino/dp/B00PIMRI00/ref=sr_1_1?ie=UTF8&qid=1474570333&sr=8-1&keywords=8-CH+5V+8-Kan%C3%A4le


Wenn jemand ohne Hardewareeingriff das schafft wäre ich sehr froh!

lg
Wolfgang
Raspberry Pi 3; 8xRelais; Aptodec Nano V3.0 Pro; FS1000a; RF-5V; Hama TS33C; 3x Brennerstuhl FunkSteckdosen; 9x Dooya funk Rollo; KWL Systemair VR400; Thermokon Modbusthermostat; diverse China Modbus Thermostate; 1-wire Bus; Telegram; QuickFhem; FhemNative; Firmata; Alexa ......

mahowi

Wie simulierst Du denn den Stromausfall? Einfach Stecker raus? Das ist nicht so gut fürs Dateisystem.
Wie sind die CULs denn definiert, über /dev/ttyxxx oder /dev/serial/by-id/xxx? Im ersten Fall kann es sein, daß ein anderer Port vom System zugewiesen wird und die DEF nicht mehr passt.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

chaser

@wthiess ich verwende auch 2 Arduino Nano für die HM und IT Komponenten. Danke für den Hinweis wäre tatsächlich eine Option. Das Teil ist aber echt relativ groß im Vergleich zum Dunio selbst. Werde es ausprobieren. Eine Non-Hardware Lösung wäre tatsächlich ein Traum

@mahowi ja Du hast recht das ist nicht optimal mache auch vorher immer ein Backup und versuche alle Berechnungen zu deaktivieren um das schreiben zu vermindern. Ein Restrisiko bleibt dabei, aber irgendwie muss man es ja testen. Zumal der Fall bei mir tatsächlich eingetreten ist und da ich nicht Zuhause war nichts geschaltet (wie Rollländen, Lüftung) wurde. Meine CULs sind mit der serial/by-id festdefiniert und beim normal trennen treten auch keine Fehler auf.

KölnSolar

Du hast also gar keine originalen CULs, sondern Jeelink, Signalduino und NanoCUL 868 ?
Ich meine, dass ich das Verhalten bei Busware-CULs nämlich nicht habe. Hab aber keine Lust mir fürs Ausprobieren meine SD zu schrotten 8)
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

chaser

Naja die Busware-CULs würde ich jetzt auch nicht als Orginal bezeichen. Zumal die Dunios abgesehen vom Preis auch ihre Vorteile haben. Bis jetzt habe ich auch, bis auf des reconnect Thema beim shutdown des Pi, noch nie Probleme gehabt. Würde mich aber schon brennend interessieren ob das bei den Busware-CULs nicht auch passiert.  ;)

F.R.

Hallo,

ich hatte das Problem auch gelegentlich, sogar bei normalen Reboots. Ich habe einen nanoCUL433, einen nanoCUL868 und ein Mysensors-Gateway, alle selbstgebaut mir China Arduinos mit FTDI-Chip. Bei mir hat letztendlich geholfen, einen aktiven USB-Hub zu verwenden, ich vermute dass es da irgendwie zu kurzen Spannungseinbrüchen beim Booten des Raspberrys kam.

chaser

Zitat von: F.R. am 23 September 2016, 11:27:42
Hallo,

ich hatte das Problem auch gelegentlich, sogar bei normalen Reboots. Ich habe einen nanoCUL433, einen nanoCUL868 und ein Mysensors-Gateway, alle selbstgebaut mir China Arduinos mit FTDI-Chip. Bei mir hat letztendlich geholfen, einen aktiven USB-Hub zu verwenden, ich vermute dass es da irgendwie zu kurzen Spannungseinbrüchen beim Booten des Raspberrys kam.

Danke für den Tip, da bin ich noch nicht draufgekommen.

franky08

Und warum denkt man nicht über eine USV nach? Kostet auch nicht die Welt, versorgt bei mir den kompletten Serverschrank (2 Raspi's, Zotac nano Hauptinstanz, dieHMLAN's, den 16Port TP-Link Switch und den Router) und zur Not kann man ein sauberes runterfahren programmieren.

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1