Gibt es eine Möglichkeit den CUL temporär zu deaktivieren und wieder zu aktivieren?
Definition:
defmod CUL_Badezimmer CUL raspi-bad:3000 0000
Hintergrund: Der Cul hängt nicht direkt am FHEM sonder via ser2net an einem Raspberry Pi im Badezimmer und dieser RPi wird des nächtens ausgeschalten.
Nun habe ich immer Fhem-Lags, sobald alle Residents schlafen, also hab ich mich mit apptime auf die Suche gemacht.
apptime zeigte mir nun, dass CUL_Badezimmer der (am meisten) Schuldige ist und tatsächlich, wenn ich den Raspi starte funktioniert alles ohne Lags.
Ist das Modul des CUL nicht nonblocking geschrieben? Wie kann ich erreichen, dass Fhem in der Nacht nicht ständig versucht auf den CUL zuzugreifen und dabei alles blockiert?
Danke
ZitatGibt es eine Möglichkeit den CUL temporär zu deaktivieren und wieder zu aktivieren?
Meines Wissens nicht, ausser die Instanz zu loeschen.
ZitatIst das Modul des CUL nicht nonblocking geschrieben?
Doch, weitgehend, das oeffnen des Geraetes gehoert aber nicht dazu, da ich das o.g. Szenario als nicht sinnvoll eingestuft habe.
Ich habe jetzt das Wiederoeffnen der Schnittstelle bei Netzwerkgeraeten nonblocking gemacht, die Aenderung ist per FHEM-Update morgen ab acht verfuegbar.
Danke für die Lösung des Problems,
habe die Änderung erstmal manuell in der 00_CUL.pm durchgeführt und jetzt blockiert der CUL nicht mehr.
Bleibt noch die Blockade hier:
https://forum.fhem.de/index.php/topic,117967.msg1123909.html#msg1123909 (https://forum.fhem.de/index.php/topic,117967.msg1123909.html#msg1123909)
Aber damit die Funktion PRESENCE_Ready auch nonblocking wird, muss der Maintainer von PRESENCE ran, das machst nicht du schätze ich, oder?
Ich hoffe Markus Bloch liest den Thread.
Danke nochmal!
Moin,
ich hänge mich mal hier an, weil das Thema passt.
Ich müsste auch meinen CUL_433 verzögert starten, weil er nämlich meinem CUL_0 in die Quere kommt
mit der Folge, dass die zwei sich stetig wechselseitig initialisieren und sogleich wieder disconnecten.
Manchmal meit der CUL_433 auch, er sei der CUL_1
Ziehe ich den CUL_433 raus, lasse den CUL_0 in Ruhe initialisieren und stecke dann den CUL_433 hinzu, dann tut es richtig.
Habe schon erwogen, den CUL_433 mittels eines Relais später zuzuschalten, aber vielleicht gibts ja eine intelligentere Lösung ?
Idee erbeten ?
@Ralph: ich bin nicht sicher, ob das passt...
Originalproblem ist doch (ganz) anders!?
Wie hast du eingebunden?
/dev/tty oder by-id oder wenigstens by-path?
Ich vermute eher, dass du mit /dev/tty... eingebunden hast und da kommt es eben beim Booten drauf an wie (Reihenfolge) die CUL "erkannt" werden...
https://wiki.fhem.de/wiki/Mehrere_USB-Ger%C3%A4te_einbinden
Mag mich aber täuschen, weil ja entspr. Infos fehlen... ;)
Gruß, Joachim
Zitat von: MadMax-FHEM am 04 Februar 2021, 22:10:39
Ich vermute eher, dass du mit /dev/tty... eingebunden hast ....
Du vermutetest exakt richtig. Danke Dir sehr, genau das wars.
Es war genau so:
defmod CUL_0 CUL /dev/ttyACM0@9600 1034
defmod CUL_433 SIGNALduino /dev/serial/by-id/usb-Unknown_radino_CC1101-if00@57600Nun ist wohl auch erklärt, warum es manchmal "richtig" ging und manchmal nicht.