Ich habe bei mir mehrere SIG2 in Betrieb, einige im Garten/Garagen bereich und andere im Haus. Für die Nachrichten im Hause ist ein CUL in Betrieb, für den Gartenbereich ein CUNO. Wenn ich jetzt ein Befehl zB. "set WM_Text on" absetze, bekommt immer das I/O Device was als letztes aktiviert war den Befehl. Wie kann ich es erreichen, das das beide I/O Device, also CUL und CUNO den Befehl erhalten und "weiterleiten" zum SIG2?.
Es geht entweder "attr WM_Text IODev CUNO" oder "attr WM_Text IODev CUL".
Ich weiß nicht wie ich eine CUL und ein CUNO zusammen als eine I/O Device als Attribut einem Befehl zuordnen kann.
So ähnlich stelle ich mir das vor: attr WM_Text IODev CUNO;CUL (nur zur Veranschaulichung, geht natürlich nicht)
Gibt es da eine Möglichkeit?
Gruß aus Köln
Norbert
Hallo,
einem set-Befehl kann kein IODev zugewiesen werden.
IODev kannst du mWn nur einem Device zuordnen.
Grüße
Da irrt der Puschel... Ein Blick in die commandref hilft enorm weiter.
Das Ganze findet aber nicht in den angesprochenen devices statt, sondern direkt im CUL selbst.
attr <culName> sendpool <culName>,<cunoName>Zitat von: commandrefIf using more than one CUL 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.
Ich habe sowas ähnliches bei mir in der fhem.cfg stehen und habe gedacht das bewirkt das:
define CUL CUL /dev/ttyACM0@9600 0000
attr CUL sendpool CUL,CUNO
define CUNO CUL 192.168.115.57:2323 0000
attr CUNO sendpool CUL,CUNO
reicht dass aus und ist das das was gemeint ist, oder muß das ganz anders aussehen, so wie in deinem Beispiel?
Gruß
Norbert
Hallo,
Zitat aus dem Wiki zu sendpool:
ZitatSendpool regelt nur die zeitliche Abfolge der Aussendung von Befehlen beim Einsatz mehrerer Funkschnittstellen. Es beeinflusst nicht, über welche Schnittstelle eine Befehl gesendet wird.
Das passt schon so wie du es hast cocojambo.
Nichts desto lässt sich einem set-Befehl kein IODev zuweisen :P (oder der Wikieintrag ist falsch - oder ich hab ihn nur falsch verstanden).
Grüße
Edith: Quelle nachgereicht: http://www.fhemwiki.de/wiki/Sendpool (http://www.fhemwiki.de/wiki/Sendpool)
Hallo,
warum den beiden sig2 nicht zwei verschiedene FS20-Adressen zuordnen und per set das ganze dann zweimal senden?
sig1 auf IODEV CUL_0
sig2 auf CUNO
Oder:
Die beiden sig's auf gleiche FS20 - Adressen, definieren, aber mit zwei verschiedenen IODevs und dann den set-Befehl an beide senden?
Ich habe ein Gerät, dass ist bzg. des Empfangs etwas grenzwertig gelegen. Ich habe esper define zweimal angelegt, auf die gleiche FS20 - Adresse, aber mit verschiednen IODevs.
An beide sende ich dann den Befehl, mit einem kleinen sleep von 0.25 dazwischen, in der Hoffnung, dass das Gerät mindestens eins der Signale korrekt empfängt.
Gruß
Elektrolurch
genau so hatte und habe ich es auch gemacht für meine Mülltonnenerinnerungen. Hier ist mein org. Ausschnitt auf der fhem.cfg.
define Tonnenabfuhr_blau_morgen at *02:00:15 { my $Value = fhem("get Tonnenabfuhr tomorrow");;\
if ($Value =~ m/Blau/) { fhem ("define a1 at 19:00:15 set Tonnen_CUL on;; set Tonnen_CUNO on")}}
define Tonnenabfuhr_blau_heute at *07:00:10 { my $Value = fhem("get Tonnenabfuhr today");;\
if ($Value =~ m/Blau/) { fhem ("set Tonnen_CUL on;; set Tonnen_CUNO on")}}
Was passiert, ist wenn um 02:00:15 die Abfrage (Die mache ich für eine Anzeige in einer readingsGroup) in der Tonnen.holiday Datei, wo die Daten stehen, gemacht wird geht der CUNO mit an. Der CUL bleibt ruhig. um 07:00:15 und um 19:00:15 werde beide wie gewollt angsprochen und es geht. Aber warum wird ein Signal an den CUNO um 02:00:15 gesendet, owohl dieser doch eindeutig nur den 07 und 19 Uhr Zeiten zugeordnet ist?
Das verstehe ich nicht und deshalb habe ich nach einer anderen Lösung gesucht.
Vielleicht ist diese Schreibweise falsch, oder es fehlen ein paar Zeichen? ("define a1 at 19:00:15 set Tonnen_CUL on;; set Tonnen_CUNO on")
Ich weiß mir keine Rat, vielleicht einer von Euch?
Gruß
Norbert
so ich habe wahrscheinlich eine Erkärung für die sendpool Geschichte gefunden. Wenn ich einen Befehl an eine CUL IO Device sende, wird dieser Befehl auch an die CUNO IO Device gesendet, ohne das ich den Befehl mit set.....CUNO definiere. Das gleiche passiert auch umgekehrt. Kann man im LOG nach sehen wenn man vorher verbose5 gesetzt hat. nehme ich jetzt die ganzen "sendpool Definitionen raus" macht FHEM das nicht mehr und sendet die den Befehl genau an das IO Device was angesprochen wird. Somit ist sendpool wahrscheinlich auch dafür verantwortlich, das alle Device nacheinander mit den Befehlen versorgt werden.
mit meinem anfänglichem Problem mit dem ("define a1 at 19:00:15 set Tonnen_CUL on;; set Tonnen_CUNO on") habe ich dann folgendes gemacht
("define a1 at 19:00:15 set Tonnen_CUL,Tonnen_CUNO on")
und schon waren die Fehler weg und die Durchsagen für die Tonnenbereitstellung kommen nur noch zu den festgegegten Zeiten und auch nicht mehr morgens mitten in der Nacht wenn die Daten aus der Tonnenabfuhr.holiday Datei gelesen werden.
Gruß
Norbert