CUL geht nicht mehr wenn CUNO spannungslos geschaltet wird

[cocojambo]

Hallo liebe FHEM Fan-Gemeinde
ich habe einen CUL und einen CUNO mit FHEM laufen. der CUL steckt in der Fritzbox und CUNO im Garetenhaus in einem Netzwerk-Switch. Wenn das Gartenhaus nicht benutzt wird, wird dort der Strom abgeschalet und somit bekommt der CUNO keine Versorgungsspannung mehr. Kurz danach lassen sich keine Sendebefehle vom noch in Box steckenden CUL mehr empfanden. Nehme ich aber in der CFG Datei die Zeile Define... für den CUNO raus, geht es wieder. Das ist aber sehr umständlich. Kann man durch einen Befehl oder etwas ähnlichem, FHEM nicht sagen, das der Error durch das Ausfallen des CUNO nicht berücksichtigt werden soll und der CUL wie vorher auch weiter funktioniert.

gruß aus köln
norbert

[Zrrronggg!]

Ich vestehe nicht wieso das überhaupt passiert. Wenn bei mir eine der 4 Funkschnitstellen nicht erreichbar ist, hat das nicht den von dir beschreiben Einfluss auf die ANDEREN Schnittstellen.

[cocojambo]

@Zrrronggg!

Es ist so, wenn ich den Event monitor einschalte wird der Befehl verarbeitet und auch für den entsprechenden Aktor ausgegeben. Aber der CUL sendet keinen Befehl.
So sieht meine "define..." aus.

define CUL_0 CUL /dev/ttyACM0@9600 1034
define CUNO CUL 192.168.115.4:2323 0000

setze ich vor die CUNO Zeile ein "#" dauert es ein paar sekunden und der CUL sendet wieder.

Mal ne blöde Frage:
kann es vielleicht sein, das die Entfernung der beiden nicht groß genug ist? und der CUL gibt deshalb kein Befehl mehr raus und wenn ich dann den CUNO deaktiviere wird der CUL nicht wieder eingeschaltet?

Gruß aus Köln
Norbert

[Puschel74]

Hallo,

definier dir doch für die Geräte die mit dem CUL geschaltet werden sollen ein IODev.
Was passiert dann?

Grüße

[cocojambo]

so sieht das aus, alle haben die Zeile IODev CUL_0 drin stehen. Odere muß der CUNO ebenfalls drin stehen?

BTN 33
DEF f... 33
IODev CUL_0
NAME Gartenwegbeleuchtung
NR 69
STATE toggle
TYPE FS20
XMIT f...

Gruß
Norbert

[cocojambo]

@Zrrronggg!

so ich habe jetzt sicherheitshalber mal deinen Vorschlag IOdev untergebracht:

define Test_Schalter FS20 f... 07
attr Test_Schalter IODev CUL1
attr Test_Schalter eventMap on:Ein off:Aus
attr Test_Schalter model fs20st
attr Test_Schalter onOffDevice true
attr Test_Schalter room Allgemein
define FileLog_Test_Schalter FileLog ./log/FS20_f...07-%Y.log Test_Schalter
attr FileLog_Test_Schalter logtype text

dann habe ich den CUNO spannungslos gemacht und CUL funktioniert weiter. Aber wie definiere ich Aktoren mit IOdev die mit dem CUL und dem CUNO funktionieren sollen. Ich muß die Klingel zum Beispiel im Haus (CUL1) und im Gartehaus (CUNO1) hören. Dafür soll ja die Reichweitenvergrösserung sein. Wenn du oder auch jemand anders, der den Beitrag ließt, auch mehrere CULs und CUNOs am laufen hat, wäre es vielleicht für mich mal interessant, wie deine oder eine andere Config für den Parallelbetrieb CUL/CUNO und den Aktoren aussieht. Auszugsweise natürlich.

gruß aus köln
norbert

[Zrrronggg!]

Wenn du keine IOdevs definiert hattest ist eigentlich schon alles klar:

Wenn man KEIN IOdef definiert, wird das LETZTE Device, das passt (wie in fhem.cfg definiert)  als IOdev angenommen. Da das bei die der CUNO war und du den auschaltest, geht dann nichts mehr , dennFHEM sendet immer munter weiter über CUNO.
Nur: Dann wurde dein CUL sowieso für senden NIE benutzt! (Sondern eben erst, wenn du den CUNO aus der fhem.cg austrägst und damit das CUL die letzte passende Schnittstelle ist). Wenn trotzdem alles ging... brauchst du das CUL wegen Reichweite vielleicht gar nicht.

Empfang geht übrigens über alle Schnittstellen zugleich, jede die das Signal empfängt sendet es an FHEM ohne weiteres weiter und FHEM soritert dann doubletten aus.

Gesendet wird aber eben nur über die Schnittstelle, die in der Definition des Devices als IOdev eingetragen ist. Wenn die aus ist wird NICHT automatisch über andere Schnittstellen gesendet!
Wenn KEIN IOdev beim device definiert ist, wird automatisch das LETZTE passende wie in FHEM cfg genommen.

Ich muß die Klingel zum Beispiel im Haus (CUL1) und im Gartehaus (CUNO1) hören.

So richtig verstehe ich das nicht.
CUL und CUNO klingeln ja nicht selber, als hlft die Verteilung der beiden für KLINGELN nichts.
Gehe ich richtig in der Annahme das du also 2 Klingelaktoren hast?

Dann machst du den im Haus mit seiner Adresse an  IOdec CUL1, und den zweiten mit einer anderen Adresse an IOdev CUNO1.

Und wenn die klingeln sollen, dann sendest denen beiden ein ON Signal.

Ic habe aber wie gesagt inzwischen Zweifel, das du überhaupt 2 Funkschnittstellen wegen Reichweitenverlängerung brauchst.

[cocojambo]

Ich habe 6 Klingeln und jeweils ein on oder off Signal wird jeder Klingel zugeordnet. und zwar mit 3 FS20KSE die sowohl in 3 Stockwerken und auch im 50m entffenten Gartenhaus durch einen FS20SIG-2 ausgegeben werden.
Hier mal die Konfiguration für 2 Klingeln und einem FS20KSE:

define Klingel_Lask_SIG2 FS20 f... 45
attr Klingel_Lask_SIG2 eventMap on:Privat off:Geschaeft
attr Klingel_Lask_SIG2 onOffDevice true
attr Klingel_Lask_SIG2 room hidden
# attr Klingel_Lask_SIG2 model fs20sig2
# define FileLog_Klingel_Lask_SIG2 FileLog ./log/FS20_f...45-%Y.log Klingel_Lask_SIG2
# attr FileLog_Klingel_Lask logtype text

define KL_notify notify Klingel_Lask { if (Value("Klingel_Lask") eq "Privat" || Value("Klingel_Lask") eq "dimup" || Value("Klingel_Lask") eq "on") { fhem "sleep 1;;set Klingel_Lask_SIG2 Privat"} else { fhem "sleep 1;;set Klingel_Lask_SIG2 Geschaeft"}}

Und diese Konfiguration gibt es 3 mal für 6 verschiedene Klingelsignale. Diese Klingelsignale sollen logischer Weise natürlich im Haupthaus, wo wir nicht alleine wohnen, in der Garage bei der Arbeit und im Gartenhaus bei Bier und Grill, wenn der CUNO zusätzlich eingeschaltet wird, hörbar sein und deshalb sollen alle Signale über CUL und CUNO parallel übertragen werden. Ohne Reichweitenverlängerung nur mit dem CUL im Erdgeschoß des Hauses ist schon nach 20m im Garten und Garage Schluß.

gruß
norbert

[Zrrronggg!]

Das geht so nicht ganz...  ist machbar. Ich bin aber unterwegs und kann mich frühestens am Dienstag drum kümmern. Wenn inzwischen niemand anders hilft, komme ich dann wieder.

[Puschel74]

Hallo,

ich hab 4 CUNO und ein CSM im Einsatz - ich schalte aber keine davon hart ab.

Aber ich hab evtl. eine Idee.

Empfangen wird das Klingelsignal über jeden, in Reichweite befindlichen, CUL oder CUNO.

Im Haus reicht dir doch der CUL um das Klingelsignal an die Empfänger weiter zu leiten.
Wenn du im Garten oder in der Garage bist schaltest du den CUNO ja wieder ein.
Definier doch für die "externen" Empfänger den CUNO als IODev.
Der CUNO kann zwar nicht senden wenn er keine Spannung hat - dann müssen aber die externen Empfänger auch nichts signalisieren weil du ja nicht draussen bist.
Im Haus sollte die Signalisation aber über den CUL weiter funktionieren.
evtl. an den hausinternen Empfängern den CUL als IODev eintragen.

Grüße

Edith: Und evtl. am CUL und am CUNO noch sowas definieren

attr CUNO1 sendpool CSM,CUNO1,CUNO2,CUNO3,CUNO4

[cocojambo]

Danke für den Lösungsansatz. Ich habe mal den CUNO1 als IODev definiert und auch die Zeile mit dem sendpool eingebaut. Funktioniert im Normalfall, wenn CUNO1 Betriebsspannung hat. Aber sobald ich dem CUNO1 die Spannung klaue, sendet der CUL1 wieder nicht. Also hat leider nichts gebracht.
Aber trotzdem Danke.
Vielleicht gibts ja noch irgend ein anderen Trick.
Gruß
norbert

[Zrrronggg!]

Okay. Jetzt hab ich ein bisschen Zeit.

1. Sendpool... kann ich nichts zu sagen, ich weiss insbesondere nicht wie sich das verhält, wenn eine der Schnittstellen offline ist.
Da es wie es bei dir scheint am eigentlichen Problem nichts ändert hlft das so also nicht.

2. Das eigentliche Problem ist, das ... (ich zitiere mich einfach selber)

Wenn man KEIN IOdef definiert, wird das LETZTE Device, das passt (wie in fhem.cfg definiert) als IOdev angenommen. Da das bei die der CUNO war und du den auschaltest, geht dann nichts mehr , denn FHEM sendet immer munter weiter über CUNO.

Ich erwarte (weiss es aber nicht), dass ein sendpool daran nix ändert (ich kann keinerlei Doku zu sendpool finden).

D.H. nochmal anders formuliert:
- wenn du keine IOdevices als attr zuweist wird bei deiner cfg immer über CUNO gesendet, wenn der aus ist geht NICHTS mehr. Die werden nicht automatisch über die andere Schnittstelle geroutet.
- wenn du hingegen IOdevices zuordnest, dann werden die Befehle nur gesendet, solange die passende sChnittstelle an ist. Wenn du also Aktoren mit Attrribute  IOdev CUNO versiesht, gehen zumindest die nicht mehr, wenn CUNO aus ist, die werden nicht automatisch über die andere Schnittstelle geroutet.
- was sendpool da genau mit macht oder nicht mach weiss ich nicht.


3. Man kann das aber trotzdem lösen. Ich habe bei mir einige FS20 Aktoren 2x angelegt. Beide mit der selben Adresse aber unterscheidlichen Namen und unterscheidlichen IOdevs. z.B. so

Code Auswählen Erweitern

define Klingel_A_CUL1 FS20 22224222 02
attr Klingel_A__CUL1 IODev CUL1

define Klingel_A_CUL2 FS20 22224222 02
attr Klingel_A_CUL2 IODev CUL2

Damit kann ich jetzt den Klingelbefhel für die SELBE Klingel mit der selben Adresse geziehlt über CUL1 oder CUL2 senden. Oder eben über beide zugleich, damit der Klingebefehl auch ankommt, wenn einer der beiden CULs ausser Reichweite oder aus ist. Wenn du das so machen würdest und dein Klingebefhel z.b. so heissen würde:

Code Auswählen Erweitern

set Klingel_A_CUL1 on ; sleep 1.0 ; set Klingel_A_CUL2 on

dann klingelt die Klingel, egal ob einer der beiden Funkschnittstellen aus ist.

[cocojambo]

@Zrrronggg!

diesen vorschlag findet ich sehr gut. ich kann ihn nur leider in meinem urlaub nicht ausprobieren, aber wenn wir in 3,5 wochen wieder da sind werde ich das zumindest mal mit einer klingel probieren.
auf jeden fall gebe ich dann rückmeldung ob es funktioniert damit nicht nur du sondern vielleicht andere die so was bauen wollen auch wissen ob es geht.
gruß
norbert

[cocojambo]

@Zrrronggg!

so bin am wochenende wieder in die heimat zurückgekehrt und habe mich dann heute mal wieder mit FHEM, CUNO und CUL beschäftigt.
Ich habe als erstes mal dafür gesorgt, das der CUNO an der garage über das lan-kabel dauerbetriebsspannung bekommt, weil das zuordnen der einzelnen Aktoren jeweils zu dem CUNO und dem CUL echt aufwendig wird.
Folgenes habe ich dann in der fhem.cfg eingetragen:

define CUL CUL /dev/ttyACM0@9600 0000
attr CUL sendpool CUL,CUNO
define CUNO CUL 192.168.115.4:2323 0000
attr CUNO sendpool CUNO,CUL

wenn ich das so mache und ein befehl senden will, sendet immer nur der CUNO.
nehme ich die 2 zeilen für den CUNO raus (#....), sendet wieder der CUL.

woran liegt das jetzt wieder? langsam verzweifele ich. ich habe gedacht wenn beide gleichzeitig arbeiten und die befehle ausgegeben werden, das dann auch beide die befehle unabhängig von einander senden. so stehts zumindest in den hier gefundenen beiträgen.

weiß jemand woran das jetzt wieder liegt?

gruß aus köln
norbert

[Zrrronggg!]

Wie ich glaube ich schon erwähnte kenne ich mich "sendpool" nicht aus und habe keine genau Vorstellung, was dieser Befehl konkret macht.  Das Zuordnen einzelner Devices zu einer Funkschnittstelle (also dass, das du "echt aufwendig " nennst) ist an sich das normale Vorgehen und bietet ein gute Kontrolle wer was sendet.

Viele scheinen hier zu vermuten, dass sendpool dazu führt, das der Sendebefehl von beiden Schnittstellen zugleich gesendet wird. Das halte ich für eher unwahrscheinlich, weil es da 1-2 Probleme geben kann, inclusive sich gegenseitig störenden Funkverkehrs.
(aber wie gesagt ich VERMUTE nur)

Und dann wenn meine Vermutung richtig ist (sendpool also nicht dafür sorgt, das alle Funkschnitstellen den Befehl aussenden) ergäbe das genau das von dir beschrieben Verhalten:
FHEM nutzt, wenn man *kein* IOdev als attribut setzt, die LETZTE DEFINIERTE für das Protokoll nutzbare Funkschnittstelle. Und das ist in deinem Fall der CUNO. Und zwar immer.

woran liegt das jetzt wieder? langsam verzweifele ich.

Wenn ich mal so keck sein darf: Selba in Schuld!
- du verwendest Befehle, deren genaue Bedeutung dir möglicherweise unklar ist
- Leute machen hier Vorschläge (setzen von IOdev) die du nicht annimmst, weil zu mühevoll.
- anstelle dessen machst du irgendwas anderes, Vorzugsweise etwas wo wir hier schon gesagt haben, das es nichts bringen wird
         (denn wie sich FHEM ohne IOdev verhält und das Sendpool daran vermutlich nichts ändert habe ich schon vor 2 oder 3 Posts erklärt, oder)
- Obwohl bereits mehrfach erläutert ignorierst du normales Verhalten von FHEM (letzte Funkschnittstelle wird genutzt)



Nimms mir bitte nicht übel, aber ich sag dir jetzt zum letzen Mal: IOdev setzen bitte.

Bitte frag zumindest mich erst wieder um Hilfe, wenn du das ausprobiert hast. Bitte.

_____________________

Okay.... inzwischen hab ich die Doku zu sendpool gefunden und *wenn* ich dir richtig verstehe, macht sendpool was GANZ anderes.

Sendpool sorgt nämlich "nur" dafür, dass diverse Funkschnittstellen einer RFmode-Klasse auf keinen Fall zugleich senden.

Wenn man z.b. zwei Lampen hat und

 lamp1
hat

Code Auswählen Erweitern

attr IODev CUL

und

lamp2
hat

Code Auswählen Erweitern

attr IODev CUNO


und man sagt dann

Code Auswählen Erweitern

set lamp1,lamp2 on
Dann würde je nach Details der Anbindung der Schnittstellen diese zeitgleich den jeweiligen "on" Befehl absetzen und sich damit gegenseitig stören.

sendpool bewirkt nun *nur*, dass eine Reihenfolge festgelegt wird, wann welche Funkschnittstelle seinen Befehl absetzen darf und das dies garantiert nur nacheinander passiert.
D.H. sendpool ist nur sinnvoll, wenn die Gefahr besteht, das die Anbindung zweier Schnittstellen ähnlich schnell ist. (Bei einen RFR-Cul braucht man dann z.b. keinen Sendpool)

Ohne die Definition von IODevs ist der Befehl sendpool also nutzlos, weil sowieso immer alles über die letzte Schnittstelle gesendet wird, wie es bei dir der Fall ist.

Und natürlich müsste die sendpool-Definition bei beiden Funkschnittstellen auf gleich sein, so ist in Commandref auch dargestellt:

sendpool
If using more than one CUL/CUN for covering a large area, sending different events by the different CUL's might disturb each other. This phenomenon is also known as the Palm-Beach-Resort effect. Putting them in a common sendpool will serialize sending the events. E.g. if you have three CUN's, you have to specify following attributes:
attr CUN1 sendpool CUN1,CUN2,CUN3
attr CUN2 sendpool CUN1,CUN2,CUN3
attr CUN3 sendpool CUN1,CUN2,CUN3

Mit anderen Worten: Die aufwändige Arbeit, sich um die IOdefs zu kümmern wird dir nicht erspart bleiben.