FHZ 1300 PC Distanz vom PC vergrößern

[rudolfkoenig]

                                                   

> daher wäre ggf. doch mal eine gründlichere Erklärung, warum FHT-Empfang zu
> Lasten der culfw-Sendezeit geht, hilfreich.

Eine FHT<->FHZ Kommunikation ist bidirektional, und kann auch mit fhem
mitprotokolliert werden ("set CUL raw X61" vorher nicht vergesen). Hier ein
Mitschnitt:

  2008-09-28 13:04:18 FHT wz actuator: 0%
  2008-09-28 13:04:18 FHT wz actuator: 0%
  2008-09-28 13:04:18 FHT wz start-xmit: 17
  2008-09-28 13:04:18 FHT wz FHZ:start-xmit: 17
  2008-09-28 13:04:19 FHT wz measured-low: 21.9 (Celsius)
  2008-09-28 13:04:19 FHT wz FHZ:measured-low: 21.9 (Celsius)
  2008-09-28 13:04:19 FHT wz measured-high: 0
  2008-09-28 13:04:19 FHT wz FHZ:measured-high: 0
  2008-09-28 13:04:19 FHT wz ack: 0
  2008-09-28 13:04:20 FHT wz FHZ:ack: 0
  2008-09-28 13:04:20 FHT wz warnings: none
  2008-09-28 13:04:20 FHT wz FHZ:warnings: none
  2008-09-28 13:04:20 FHT wz ack: 0
  2008-09-28 13:04:20 FHT wz FHZ:ack: 0
  2008-09-28 13:04:20 FHT wz end-xmit: 0
  2008-09-28 13:04:20 FHT wz FHZ:end-xmit: 0

Jede Zeile steht fuer ein Telegramm (und nicht fuer 3, wie beim FS20).

FHZ:xxx Telegramme wurden von dem FHZ (oder CUL) gesendet, die anderen vom FHT.

fhem fasst measured-low und measured-high zu measured-temp zusammen, es werden
also im normalen log (telnet: inform timer) 2 Zeilen weniger gemeldet.

17 ist der Housecode des protokollierten FHZ. Wenn das FHZ nicht mit dem
richtigen Housecode antwortet, dann geht die Kommunikation nicht weiter.

-> Ausflug:
   Wenn das FHT nicht an dem FHZ angemeldet ist (d.h. das FHT hat nicht den
   Housecode des FHZ gespeichert), werden keine Temperaturdaten uebermittelt.
   Set Prog:Cent:N/A setzt den FHT Housecode auf 100, dann sollte jeder FHZ auf
   "start-xmit" antworten, und das FHT merkt den ersten.  Noch besser dem FHT
   via fhem was zu senden, dann muss man nicht auf die naechste
   Temperaturmeldung (bis zu 15 Minuten) warten.

Falls die Gegenseite nicht wie erwartet antwortet, dann wird es nach einem
Timeout das Telegramm einmal wiederholt. Falls immer noch keine korrekte
Antwort vorliegt, dann wird es nach 115+x Sekunden das ganze Vorgang einmal
wiederholt.

Jedes Telegramm ist bei 1000Baud ca 75ms lang. Temperatur wird pro FHT 4-mal
die Stunde gemeldet: 4*7*75ms = 2.1s FHZ-Sendezeit pro FHT und Stunde, und da
man wg. 1% 36 Sekunden hat, entspricht das 5.833% pro FHT. Wenn das 1%
erschoepft ist, dann versucht das CUL zu antworten, aber es wird bei jedem
Versuch LOVF ausgegeben.

Falls die Kommunikation nie abbricht, und sonst auch nichts gesendet wird, kann
man mit einem FHZ 17 FHT's versorgen.  Last auf mehrere FHZ/CUL's zu verteilen
hilft um das 1% Problem zu loesen, aber die Wahrscheinlichkeit, dass FS20
Nachrichten wegen Funkmuell nicht mehr klappen, wird zunehmend realistisch.

Sendefehler entstehen aber je nach Konfiguration auch zwangsweise: Da wegen dem
115+x (x = 0.5sec * Low-Nibble des FHT-HouseCodes) die FHT-Sendeintervalle
unterschiedlich sind, "kreuzen" sich zwei FHT's mit dem Housecode 10 (115s
Intervall) und Housecode 12 (116s Intervall) alle 115*115sec = 13225sec = 3.67h
zwangsweise.  Bei mehreren FHT's gibt es wohl mehrere Kreuzungsmoeglichkeiten.
Ist aber vermutlich immer noch besser, als mehrere FHT's, die immer zur
gleichen Zeit senden.

Die andere Richtung (FHZ->FHT) ist aehnlich (bescheuert , das FHZ muss nach
dem actuator Meldung sofort mit FHT:can-xmit anfangen, damit der FHT nicht
"einschlaeft".



Stellt das jemand bitte ins Wiki ein?

Gruss,
  Rudi

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

> Last auf mehrere FHZ/CUL's zu verteilen
> hilft um das 1% Problem zu loesen

Was wäre, wenn man diese IMHO eher willkürliche 1%-Regel für CUN/CUL
modifizierbar macht ? Da alle FHZs in meinem Fall vom CUN erreichbar
sind, halte ich die Installation eines weiteren CUN an dieser Stelle
für widersinnig.

Nur ein  Vorschlag ...

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[rudolfkoenig]

                                                   

> Was wäre, wenn man diese IMHO eher willkürliche 1%-Regel für CUN/CUL
> modifizierbar macht ?

Willkuerlich mag zwar sein, ist aber meines Wissens nach von der
Bundesnetzagentur festgelegt, und damit gibt es in Deutschland legale
Moeglichkeiten, das Betrieb von Geraeten zu unterbinden, die diesen Regel nicht
einhalten -> Ich werde das brechen dieser Regel nicht unterstuetzen.

Btw, kann jemand die genaue Anordnung aussuchen? Das beste was ich bisher
gefunden habe ist
http://www.bundesnetzagentur.de/cae/servlet/contentblob/134184/publicationFile/2570/FundstelleId5772pdf.pdf
Und in diesem Zusammenhang (damit wir dann so richtig off-topic werden
interessiert mich auch, was fuer 433MHz gilt.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

Moin,

MSB wrote:

>> Last auf mehrere FHZ/CUL's zu verteilen
>> hilft um das 1% Problem zu loesen
>
> Was wäre, wenn man diese IMHO eher willkürliche 1%-Regel für CUN/CUL
> modifizierbar macht ?

Das wäre latent keine gute Idee, da diese "willkürliche 1%-Regel"
Voraussetzung für die Nutzung des 868-MHz-Funks ist:

http://www.rn-wissen.de/index.php/Funkmodule#Das_neue_868_MHz_Band

Nachdem dank Rudis Erklärung nun klar ist, daß FHT und "FHZ" (hier also:
FHEM mit CUx) ausgiebig miteinander kommunizieren (und nicht nur eine sim-
ple Aussendung a la FS20 erfolgt), ist ein rechtskonformer Aufbau mit
der Anzahl an FHTs wie bei Dir nur durch Aufteilung auf mehrere CUx mög-
lich. Wobei ich mich da schon frage, ob bei mehreren CUx an einem steu-
ernden FHEM wirklich der Duty-Cycle pro Sender zählt; mal von der Vermüll-
ung des Frequenzbandes abgesehen -- wogegen ja die 1%-Regel helfen soll,
imho allerdings widersinnig, da parallel der Bereich für Audioanwendungen
ohne diese Einschränkungen freigegeben wurde --, die *Steuerung* der CUx
nimmt ja FHEM vor, die mehreren CUx dienen ja grade der Umgehung der 1%-
Grenze ...

Was sagt eigentlich ELV, wieviele FHTen man mit einer FHZ steuern kann?
         kai

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[rudolfkoenig]

                                                   

> Btw, kann jemand die genaue Anordnung aussuchen?

Habs:

http://www.bundesnetzagentur.de/cae/servlet/contentblob/38206/publicationFile/2580/ShortRangeDevicesSRD_ID17299pdf.pdf

Da steht es: 868.000 bis 868.600 ist mit 25mW und <= 1% erlaubt.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

Hi,

Rudolf Koenig wrote:

> Btw, kann jemand die genaue Anordnung aussuchen? Das beste was ich bisher
> gefunden habe ist
> http://www.bundesnetzagentur.de/cae/servlet/contentblob/134184/publicationFile/2570/FundstelleId5772pdf.pdf

Yepp, die fand' ich auch, hat aber leider genau 868,35 MHz nicht drin

http://www.mikrocontroller.net/topic/122787 verweist auf http://www.bundesnetzagentur.de/media/archive/6709.pdf,
aber leider waren bei der BNetzA ausgewiesene Experten am Werk:

   "Die Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post
    und Eisenbahnen hat ihr Internetangebot auf den Government Site Builder
    – die Content Management Lösung der Bundesverwaltung – umgestellt.
    Dadurch haben sich alle Links des Webauftritts geändert. Bitte aktualisieren
    Sie Ihre Bookmarks."

http://www.bundesnetzagentur.de/cae/servlet/contentblob/38206/publicationFile/2580/ShortRangeDevicesSRD_ID17299pdf.pdf

deckt allerdings 868 ab ...

> Und in diesem Zusammenhang (damit wir dann so richtig off-topic werden
> interessiert mich auch, was fuer 433MHz gilt.

Siehe meinen vorigen Link, http://www.rn-wissen.de/index.php/Funkmodule schreibt
auch was zu 433
         kai

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

> > Was wäre, wenn man diese IMHO eher willkürliche 1%-Regel für CUN/CUL
> > modifizierbar macht ?
>
> Das wäre latent keine gute Idee, da diese "willkürliche 1%-Regel"
> Voraussetzung für die Nutzung des 868-MHz-Funks ist:
>
> http://www.rn-wissen.de/index.php/Funkmodule#Das_neue_868_MHz_Band
>
> imho allerdings widersinnig, da parallel der Bereich für Audioanwendungen
> ohne diese Einschränkungen freigegeben wurde --, die *Steuerung* der CUx
> nimmt ja FHEM vor, die mehreren CUx dienen ja grade der Umgehung der 1%-
> Grenze ...
>
Heißt: Es gibt ein Gesetz, das erfordert, zwei CUNs zu verwenden,
obwohl auch eins exakt diesen Job tun könnte, ohne dass sich im HF-
Kanal etwas ändert. Habe ich das richtig verstanden ? (no offense
meant)

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

Hi,

MSB wrote:

> Heißt: Es gibt ein Gesetz, das erfordert, zwei CUNs zu verwenden,
> obwohl auch eins exakt diesen Job tun könnte, ohne dass sich im HF-
> Kanal etwas ändert. Habe ich das richtig verstanden ? (no offense
> meant)

Jein; es gilt eine Allgemeinzuteilung, die Beschränkungen vorsieht. In CUx
ist diese Beschränkung implementiert (ich weiß nicht, ob culfw sendet und
meckert oder nur meckert; aus einem Posting von Rudolf würde ich fast auf
ersteres tippen).

Aus meiner laienhaften Sicht sollte es egal sein, ob FHEM über 1 oder n
CUx sendet, das Limit müßte IMHO für das Gesamtsystem gelten, sonst macht
es ja wenig Sinn. Aber, I Am Not A Lawyer, wenn es wirklich nur pro Sen-
der gilt, müßte die Nutzung mehrerer Sender und entsprechend die Aufteil-
ung in FHEM legal sein.
         kai

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[rudolfkoenig]

                                                   

> (ich weiß nicht, ob culfw sendet und meckert oder nur meckert; aus einem
> Posting von Rudolf würde ich fast auf ersteres tippen).

culfw ist natuerlich ehrlich, und sendet _nicht_ wenn das Limit erreicht ist.
Wieviel 10ms Einheiten noch gesendet werden koennen steht im zweiten
Antwort-Wort bei der Anfrage "X" (get CUL raw X)

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Zrrronggg!]

                                                     

>Stellt das jemand bitte ins Wiki ein?
Ja. Morgen aber.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Zrrronggg!]

                                                     

So, ich habe mal ein paar Wikiartikel verfasst.

Dabei ist mir aufgefallen:

- die Bundesnetzagentur schreibt:
"Für Anwendungen, die Frequenzsprung-Spektrumsspreizverfahren (FHSS),
Direktsequenz-Spektrumsspreizverfahren (DFSS) oder Adaptive Frequency
Agility (AFA) nutzen, bezieht sich der duty- cycle auf die gesamte
Aussendung, falls kein LBT angewendet wird."
Daraus ergibt sich für mich ANALOG, das Kai 'wusel' Sierings
Befürchtungen über die Legalität von 2 CULs zur Umgehung der 1%
zutreffend sein könnten.

- ELV sagt soweit ich bisher gesehen habe nirgends DIREKT was über die
Anzahl der maximal verwendbaren FHTs. Allerdings: Das
Wärembedarfsrelais  FHT8w unterstützt maximal 10 "Räume".

-  868,000 - 869,400 Mhz: "Die Übertragung von Audio- und
Sprachsignalen ist nicht erlaubt." damit düfte es eigentlich KEINE
"zugelassenen" Funkkopfhörer geben, die FS stören könnten. Problem
wird vermutlich die unsaubere Bandbreit sein.

- man KÖNNTE die 1% Regel umgehen, nämlich in dem man LBT-Verfahren
anwendet. "Listen before talk" ist ausdrücklich als Alternative zur
Beschränkung der relative Frequenzbelegungsdauer vorgesehen (Rudi ->
RFR). Hilft uns bei FHT <-> FHZ Kommunikation natürlich nicht.
Zumindest theoretisch könnte aber zeitunkritische FS20 Kommunikation
aus den 1% rausgehalten werden. Implementieren möchte ICH das aber
nicht! Mir wird schon mulmig, wenn ich über eine Defintion von "Kanal
ist frei" nachdenke.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[rudolfkoenig]

                                                   

> - man KÖNNTE die 1% Regel umgehen, nämlich in dem man LBT-Verfahren
> anwendet. "Listen before talk" ist ausdrücklich als Alternative zur
> Beschränkung der relative Frequenzbelegungsdauer vorgesehen (Rudi ->
> RFR).

Stimmt, RFR verwendet LBT jetzt schon, bei FS20 und FHT koennte man es auch
anwenden, obwohl besonders fuer FHT es nicht einfach sein wird.
Andererseits muesste FS20 senden dadurch in einem "lauten" Umgebung
zuverlaessiger werden.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Dr. Boris Neubert]

                                             

Rudolf Koenig schrieb:
> Stimmt, RFR verwendet LBT jetzt schon, bei FS20 und FHT koennte man es auch
> anwenden, obwohl besonders fuer FHT es nicht einfach sein wird.
> Andererseits muesste FS20 senden dadurch in einem "lauten" Umgebung
> zuverlaessiger werden.

LBT waere fuer FS20 das Megafeature!

In 5 bis 10% aller FS20-Schaltvorgaenge kommen bei mir die Befehle beim
Empfaenger nicht an und ich vermute, dass es an den reichlich
vorhandenen Geraeten liegt.

Ich experimentiere derzeit mit CUL, ob es hilft, mehr als 3x zu senden
oder laengere Pausen zu machen, bisher aber noch mit wenig Erfolg, weil
ein negativer Effekt aus der Positionierung des CUL (+/-20cm) bereits
den potentiellen Erfolg aus der Massnahme verdeckt.

Gruesse,
Boris

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.