[FHZ] PECO-LAN-Funk-Gateway mit FHEM verheiraten?

[Guest]

Originally posted by: <email address deleted>

Hallo zusammen,
ich habe soeben im neuen ELV-Katalog (Seite 96) gesehen, dass es eine
Art "FHZ1300PC mit LAN-Interface" gibt. Es nennt sich "PECO-LAN-Funk-
Gateway" (Bestellnummer 10-882-65 für 99,95 Euronen, lieferbar ab
01.09.).

Wenn FHEM mehrere davon unterstützen würde, könnte ich das ewige
Problem mit der Reichweite (ich habe FS20-Komponenten und den
Energiemonitor im Untergeschoss unseres Reihenhauses, während der
Debian-Server im Dachgeschoss steht) endlich mal lösen.

Leider bin ich nicht (mehr) der grosse Programmierer, so dass ich
selbst nicht sehr viel dazu beisteuern kann (außer Versuchskaninchen
spielen).

Seht Ihr eine Chance, dieses Gateway (und vor allem mehrere davon)  zu
unterstützen?
Gruss
Helmut


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[Dr. Boris Neubert]

                                             

Hallo,

C64Emulator wrote:
> ich habe soeben im neuen ELV-Katalog (Seite 96) gesehen, dass es eine
> Art "FHZ1300PC mit LAN-Interface" gibt. Es nennt sich "PECO-LAN-Funk-
> Gateway" (Bestellnummer 10-882-65 für 99,95 Euronen, lieferbar ab
> 01.09.).

schau mal in die CUL-Liste          
   http://groups.google.de/group/cul-fans?hl=de
Tosti hat dort CUN vorgestellt,
   http://www.busware.de/tiki-view_blog_post.php?blogId=1&postId=17
dass eine FHZ mit Netzwerkanschluss darstellt. Da die Firmware auf der
CUL-Firmware von Rudi basiert, wird das Teil bereits unterstuetzt. Das
Teil ist noch nicht in Serie, aber es gibt bereits Interessenten. Preis
ist nicht bekannt.

Gruesse,
Boris

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

Dazu müsste man das unterstützte protokoll des interfaces kennen...

Aber ich vermute ELV wird sich dazu ausschweigen - die wollen ja auch
ihre eigene Software verbimmeln...


Aber das CUN von Tosti secheint sehr interessant zu sein - hoffenlich
geht das  in serie...


Gruß,
Thorsten.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[rudolfkoenig]

                                                   

> Aber ich vermute ELV wird sich dazu ausschweigen - die wollen ja auch
> ihre eigene Software verbimmeln...

Ich meine das ist kein direktes ELV Produkt (steht auch kein ELV Logo
drauf), sondern eins der Firma Power-ECOnomizer.

> Aber das CUN von Tosti secheint sehr interessant zu sein - hoffenlich
> geht das  in serie...

Das hoffe ich auch: fhem/culfw unterstuetzt inzwischen CUN, jedenfalls
in seiner Eigenschaft als "CUL ueber Ethernet".
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

Hi Rudi,

ist CUN-Support bereits im CVS ? Gibt es was zu beachten ?

Kann ich CUN entsprechend über iodev zuweisen ?
Bleibt das auch bei SAVE erhalten ?

Danke,
Gruß,
O.

Rudolf Koenig schrieb:
>> Aber ich vermute ELV wird sich dazu ausschweigen - die wollen ja auch
>> ihre eigene Software verbimmeln...
>
> Ich meine das ist kein direktes ELV Produkt (steht auch kein ELV Logo
> drauf), sondern eins der Firma Power-ECOnomizer.
>
>> Aber das CUN von Tosti secheint sehr interessant zu sein - hoffenlich
>> geht das  in serie...
>
> Das hoffe ich auch: fhem/culfw unterstuetzt inzwischen CUN, jedenfalls
> in seiner Eigenschaft als "CUL ueber Ethernet".

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

Hallo Gruppe,

On 7 Sep., 08:22, Rudolf Koenig wrote:
> Das hoffe ich auch: fhem/culfw unterstuetzt inzwischen CUN, jedenfalls
> in seiner Eigenschaft als "CUL ueber Ethernet".

Unterstützt das FHEM dann auch mehrere CUN's?
Ich habe das selbe Problem mit der Reichweite, aber mein Netzwerk ist
"überall".

Nun müsste FHEM von allen angemeldeten CUNs empfangen und auf allen
CUNs (das gleiche) senden.
Könnte das dann klappen? Das wäre super.
Dann wären auch die USB/Seriell - Teile weg, wieder ein Schritt zu
mehr Stabilität.

Vielen Dank,
Viele Grüße
Stefan


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[rudolfkoenig]

                                                   

> ist CUN-Support bereits im CVS ? Gibt es was zu beachten ?
Ja. Nein. Fuer FHEM ist CUN identisch mit einem CUL, nur dass der
Device statt /dev/ttyXXX dann host:port lautet.

> Kann ich CUN entsprechend über iodev zuweisen ?
Ja. "attr xxx IODev MyCUN" ist aber nur dann notwendig, falls mehrere
CUN/CUL/FHZ im Einsatz sind.

> Bleibt das auch bei SAVE erhalten ?
Ja, wenn fuer alle Geraete die attr's verwendet wurden. Hier muesste
noch eine Automatisierung stattfinden, weiss aber noch nicht genau
wie.

-----------

> Unterstützt das FHEM dann auch mehrere CUN's?
Ja, siehe "attr IODev" oben, obwohl ich das nicht testen konnte.

> Nun müsste FHEM von allen angemeldeten CUNs empfangen und auf allen
> CUNs (das gleiche) senden.

Das gibt es so nicht. Empfang ueber alle ist nicht ganz trivial, und
ich habe es (fuer FHZ) im Januar ersetzt mit dem  direkten Zuweisung
von IODev. Klaus arbeitet wieder daran, den gemeinsamen Emfpang fuer
CUL/FHZ aktivieren.
Senden ueber alle macht meiner Ansicht nach gar keinen Sinn, da keiner
der RF Protokolle Collision Detection beherrscht.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

Hallo,

Rudolf Koenig wrote:

>> ist CUN-Support bereits im CVS ? Gibt es was zu beachten ?
> Ja. Nein. Fuer FHEM ist CUN identisch mit einem CUL, nur dass der
> Device statt /dev/ttyXXX dann host:port lautet.

Gibt's auch jetzt eigentlich 'ne Möglichkeit, einen CUL, der an
einem entfernten Rechner hängt, so FHEM über's Netz zugänglich zu
machen?

Mein LAN erreicht die gesamte Wohnung (Server & Netzzugang im Keller,
Audio-Video-Kram (VDR/XBMC/Boxee (experimentell)) im EG, Arbeits-
zimmer im OG), 'n CUL, und auch die FHZ, im Wohnzimmer aber grade
mal sicher das im gleichen Raum

>> Nun müsste FHEM von allen angemeldeten CUNs empfangen und auf allen
>> CUNs (das gleiche) senden.
>
> Das gibt es so nicht. Empfang ueber alle ist nicht ganz trivial, und
> ich habe es (fuer FHZ) im Januar ersetzt mit dem  direkten Zuweisung
> von IODev. Klaus arbeitet wieder daran, den gemeinsamen Emfpang fuer
> CUL/FHZ aktivieren.

Hilfreich wäre es imho schon, wenn das ginge, in meinem Szenario kann
ich aber notfalls Sender dedizierten Empfangs-CULs/-CUNs zuweisen.

> Senden ueber alle macht meiner Ansicht nach gar keinen Sinn, da keiner
> der RF Protokolle Collision Detection beherrscht.

Ja. Nein; entschiedenes Vielleicht. Ich kenne mich mit dem Funkkram
nicht aus, da gab's auch 'ne Limitierung von Sendungen/Zeiteinheit oder
so? Und mit zunehmender Anzahl von Sensoren würden zuviele Kommandos
auch Sensordaten vernichten, wenn ich das richtig überreiße. Sofern man
multiple CULs per getrennten FHEM-Anweisungen das Gleiche senden lassen
kann (zwangsweise durch die sequentielle Abarbeitung in FHEM leicht zeit-
versetzt) müßte sich ein solche Effekt aber bei Bedarf realisieren lassen?


MfG,
-kai

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[Dr. Boris Neubert]

                                             

Hi,

Kai 'wusel' Siering wrote:
> Ja. Nein; entschiedenes Vielleicht. Ich kenne mich mit dem Funkkram
> nicht aus, da gab's auch 'ne Limitierung von Sendungen/Zeiteinheit oder
> so? Und mit zunehmender Anzahl von Sensoren würden zuviele Kommandos
> auch Sensordaten vernichten, wenn ich das richtig überreiße. Sofern man
> multiple CULs per getrennten FHEM-Anweisungen das Gleiche senden lassen
> kann (zwangsweise durch die sequentielle Abarbeitung in FHEM leicht zeit-
> versetzt) müßte sich ein solche Effekt aber bei Bedarf realisieren lassen?

nein, das geht zumindest bei FS20 nicht. Wenn CUL1 und CUL2 beide
denselben Befehl senden, wird dieser Befehl, Empfang beider CULs
vorausgesetzt, vom Empfaenger zweimal ausgewertet. Damit die
Doppelsendung erkannt wird muesste fhem im zweiten FS20-Datagramm der
Repeat Count hochsetzen - FS20-Repeater funktionieren z.B. genau so,
damit der Empfaenger erkennen kann, dass in einem kurzen Zeitfenster
gesendete Befehle nur verschiedene Ausgaben desselben Kommandos sind.

Warum ist mehrfaches Auswerten desselben Befehls im Empfaenger schlimm?
Der FS20RSU (Rolladenschalter) ist im Gegensatz zu allen anderen mir
bekannten FS20-Geraetetypen so programmiert, dass der "An"-Befehl den
Rolladenmotor fuer 1 Minute hochfahren laesst und ein zweiter
"An"-Befehl den Rolladenmotor stoppt. Dummerweise kann damit noch kein
GUI umgehen. In dem von Dir geschilderten Setup wuerde der Motor dann
zwei "An"-Befehle nacheinander erhalten.

Gruesse,
Boris

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[rudolfkoenig]

Originally posted by: <email address deleted>

Hi,

Dr. Boris Neubert wrote:

>> Ja. Nein; entschiedenes Vielleicht. Ich kenne mich mit dem Funkkram
>> nicht aus, da gab's auch 'ne Limitierung von Sendungen/Zeiteinheit oder
>> so? Und mit zunehmender Anzahl von Sensoren würden zuviele Kommandos
>> auch Sensordaten vernichten, wenn ich das richtig überreiße. Sofern man
>> multiple CULs per getrennten FHEM-Anweisungen das Gleiche senden lassen
>> kann (zwangsweise durch die sequentielle Abarbeitung in FHEM leicht zeit-
>> versetzt) müßte sich ein solche Effekt aber bei Bedarf realisieren lassen?
>
> nein, das geht zumindest bei FS20 nicht. Wenn CUL1 und CUL2 beide
> denselben Befehl senden, wird dieser Befehl, Empfang beider CULs
> vorausgesetzt, vom Empfaenger zweimal ausgewertet. Damit die

Das wäre in meinem Szenario durchaus wünschenswert. Ich habe das
Problem, daß gelegentlich Schaltsignale nicht durchkommen; ich
setzte FHEM unter anderem zur Steuerung der Beleuchtung des Tera-
riums ein, 2 FS20-Schalter schalten je dieser Quecksilberdampf-
lampen (in der gemeinsamen Zuleitung steckt dann noch ein EMEM
zur Messung) in grober Abhängigkeit von Sonnenauf-/-untergang.
Wenn nun eine oder auch beide Lampen statt gegen 19 Uhr auszuge-
hen die Nacht über an sein, ist das ein ziemlicher Energiever-
brauch (2x 50 Watt) und zudem Streß für's Tier. Mangels Rückka-
nal möchte ich daher liebend gerne das Signal, zeitlich kurz ver-
setzt, gerne nochmals senden. (Ja, klar, ich könnte auch die
Werte des EMEM zu Rate ziehen ... Hay varias posibilidades )

> Warum ist mehrfaches Auswerten desselben Befehls im Empfaenger schlimm?
> Der FS20RSU (Rolladenschalter) ist im Gegensatz zu allen anderen mir
> bekannten FS20-Geraetetypen so programmiert, dass der "An"-Befehl den
> Rolladenmotor fuer 1 Minute hochfahren laesst und ein zweiter
> "An"-Befehl den Rolladenmotor stoppt. Dummerweise kann damit noch kein
> GUI umgehen. In dem von Dir geschilderten Setup wuerde der Motor dann
> zwei "An"-Befehle nacheinander erhalten.

Offensichtlich ein bedauerlicher Einzelfall, dieser FS20RSU
Wobei ich schon denke, daß derlei in FHEM abgefangen werden könnte,
der Typ wird, IIRC, ja übergeben (wenn auch, AFAIR, nicht ausgewer-
tet).

Aber, wie gesagt: für meinen Fall wäre es hilfreich/wichtig, wenn
alle Empfänger alles Empfangene nach FHEM melden könnten (und nicht
nur 1 Empfänger; identische Signale sollte man in FHEM ausfiltern
können und zu nur einem Event werden lassen, man würde aber die Stör-
anfälligkeit senken können); in meiner 4.5er-CVS-Version scheint der
parallele Empfang noch drin zu sein (sieht jedenfalls im Log so aus)?
Insofern weiß ich auch nicht, wie ich paralleles Senden unterbinden
könnte?

Ciao,
         kai


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

Wenn nun eine oder auch beide Lampen statt gegen 19 Uhr auszuge-
> hen die Nacht über an sein, ist das ein ziemlicher Energiever-
> brauch (2x 50 Watt) und zudem Streß für's Tier.


Hi
sinnvoller wäre hier den Befehl on-for-timer und eine Zeit auszuwählen.
Damit ist sichergestellt, dass die Lampe nach Ablauf des Timers auf
jedenfall ausgeht.
Der Timer ist von einer Sekunde bis über 4 Stunden einstellbar, somit dürfte
das ausreichend sein.

Gruß,
Maz

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Dr. Boris Neubert]

Originally posted by: <email address deleted>

Hi,

[...]

> Das wäre in meinem Szenario durchaus wünschenswert. Ich habe das
> Problem, daß gelegentlich Schaltsignale nicht durchkommen; ich
> setzte FHEM unter anderem zur Steuerung der Beleuchtung des Tera-
> riums ein, 2 FS20-Schalter schalten je dieser Quecksilberdampf-
> lampen (in der gemeinsamen Zuleitung steckt dann noch ein EMEM
> zur Messung) in grober Abhängigkeit von Sonnenauf-/-untergang.
> Wenn nun eine oder auch beide Lampen statt gegen 19 Uhr auszuge-
> hen die Nacht über an sein, ist das ein ziemlicher Energiever-
> brauch (2x 50 Watt) und zudem Streß für's Tier. Mangels Rückka-
> nal möchte ich daher liebend gerne das Signal, zeitlich kurz ver-
> setzt, gerne nochmals senden. (Ja, klar, ich könnte auch die
> Werte des EMEM zu Rate ziehen ... Hay varias posibilidades )

Dieser Meinung schließe ich mich auch an. Ich würde auch mehrere FHZ oder CUN Devices benötigen die alle die selben Daten senden bzw. empfangen können. Ich komme teilweise aus dem Keller nicht ins Erdgeschoß und schon gar nicht zur Garage und Tor. Außerdem gehen leider des Öfteren Kommandos verloren.

Cheers,
Mike

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

HI all,

also wenn jeweils ein CUL/CUN pro Etage genau die Daten sendet, die die
Geräte der Etage benötigen, wozu sollten dann mehrere Sender, die
wahrscheinlich weiter weg, sind das ganze dann nochmal senden.

Beim Empfang stellt sich die gleiche Frage.

Es ist doch einfach nur sicherzustellen, dass genügen Sender da sind, um
das ganze Feld abzudecken, aber dann ist doch jedes Gerät ohne Probleme
eindeutig einem Sender/Empfänger zuzuordnen, und es gibt weder
Nachrichten- noch Funk-Salat

Man muß halt nur genügend dedizierte Sender haben, was bei Serienreife
des CUN ja kein Problem mehr darstellt.

Gruß,
Olaf

Michael Holzer schrieb:
> Hi,
>
> [...]
>
>> Das wäre in meinem Szenario durchaus wünschenswert. Ich habe das
>> Problem, daß gelegentlich Schaltsignale nicht durchkommen; ich
>> setzte FHEM unter anderem zur Steuerung der Beleuchtung des Tera-
>> riums ein, 2 FS20-Schalter schalten je dieser Quecksilberdampf-
>> lampen (in der gemeinsamen Zuleitung steckt dann noch ein EMEM
>> zur Messung) in grober Abhängigkeit von Sonnenauf-/-untergang.
>> Wenn nun eine oder auch beide Lampen statt gegen 19 Uhr auszuge-
>> hen die Nacht über an sein, ist das ein ziemlicher Energiever-
>> brauch (2x 50 Watt) und zudem Streß für's Tier. Mangels Rückka-
>> nal möchte ich daher liebend gerne das Signal, zeitlich kurz ver-
>> setzt, gerne nochmals senden. (Ja, klar, ich könnte auch die
>> Werte des EMEM zu Rate ziehen ... Hay varias posibilidades )
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[Guest]

Originally posted by: <email address deleted>

Hi,

> HI all,
>
> also wenn jeweils ein CUL/CUN pro Etage genau die Daten sendet, die
> die
> Geräte der Etage benötigen, wozu sollten dann mehrere Sender, die
> wahrscheinlich weiter weg, sind das ganze dann nochmal senden.
>
> Beim Empfang stellt sich die gleiche Frage.
>
> Es ist doch einfach nur sicherzustellen, dass genügen Sender da
> sind, um
> das ganze Feld abzudecken, aber dann ist doch jedes Gerät ohne
> Probleme
> eindeutig einem Sender/Empfänger zuzuordnen, und es gibt weder
> Nachrichten- noch Funk-Salat
>
> Man muß halt nur genügend dedizierte Sender haben, was bei
> Serienreife
> des CUN ja kein Problem mehr darstellt.

Stimmt, dieser Ansatz geht auch. Ich muss mir das ehrlich gesagt einmal genau ansehen. Ich hab im Moment nur eine FHZ1300PC hier im Keller am Serverrack liegen. Wie sieht dann die Zuordnung der einzelnen Devices zu den jeweiligen FHZ/CUL/CUN Devices aus? Geht das mittels dem IODev Attribut?

Cheers,
Mike



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-

[rudolfkoenig]

Originally posted by: <email address deleted>

Michael Holzer schrieb:
> Hi,
>
> [...]
>
>> Das wäre in meinem Szenario durchaus wünschenswert. Ich habe das
>> Problem, daß gelegentlich Schaltsignale nicht durchkommen; ich
>> setzte FHEM unter anderem zur Steuerung der Beleuchtung des Tera-
>> riums ein, 2 FS20-Schalter schalten je dieser Quecksilberdampf-
>> lampen (in der gemeinsamen Zuleitung steckt dann noch ein EMEM
>> zur Messung) in grober Abhängigkeit von Sonnenauf-/-untergang.
>> Wenn nun eine oder auch beide Lampen statt gegen 19 Uhr auszuge-
>> hen die Nacht über an sein, ist das ein ziemlicher Energiever-
>> brauch (2x 50 Watt) und zudem Streß für's Tier. Mangels Rückka-
>> nal möchte ich daher liebend gerne das Signal, zeitlich kurz ver-
>> setzt, gerne nochmals senden. (Ja, klar, ich könnte auch die
>> Werte des EMEM zu Rate ziehen ... Hay varias posibilidades )
>
> Dieser Meinung schließe ich mich auch an. Ich würde auch mehrere FHZ oder
> CUN Devices benötigen die alle die selben Daten senden bzw. empfangen
> können. Ich komme teilweise aus dem Keller nicht ins Erdgeschoß und schon
> gar nicht zur Garage und Tor. Außerdem gehen leider des Öfteren Kommandos
> verloren.

Ganz so einfach ist das nicht. Das Problem mit dem FS20RSU wurde ja
schon geschildert, aber auch die Dimmer sind ein Problem
(DIM-UP/DIM-DOWN), von den einfachen Toggle-Befehlen mal ganz zu schweigen.

Da ist es schon deutlich einfacher von der ganzen Organisation her, wenn
man jedes Gerät eindeutig einem CUL/CUN/FHZ zuordnet und nur die dort
eingehenden Signale verarbeitet werden (wobei ja gerade dran gearbeitet
wird, das auf dem Weg auch mehrere Empfänger korrekt funktionieren) und
vor allem nur von dort aus zu den Geräten gesendet wird.

Aber selbst bei optimal platzierten CUL/CUN/FHZ gehen manchmal Befehle
verloren, das kann ich bestätigen. Vielleicht wäre es da möglich, kurz
nach dem eigentlichen Befehl nochmals den gleichen Befehl mit erhöhtem
Repeat-Zähler zu senden (zumindest bei CUL/CUN)? Das könnte hier doch
das Problem verkleinern, oder? Eventuell über ein Flag bei den
kritischen Devices, damit man bei den Devices, wo man sicheren Empfang
hat nicht unnötig die Frequenz belegt?

Ciao,
Sven

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "FHEM users" group.
To post to this group, send email to fhem-users@googlegroups.com
To unsubscribe from this group, send email to fhem-users+unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/fhem-users?hl=en
-~----------~----~----~----~------~----~------~--~-