Originally posted by: <email address deleted>
Hallo
habe FHZ 1300 PC an fhem (OpenSuse 11.1) laufen. Leider steht der
Server ungünstig im Keller, so dass nicht alle Devices zuverlässig
empfangen werden, wenn sich der Empfänger nur 1,8 m vom Server
entfernt befindet. Habe folgendes probiert:
1. USB Verlängerung 3 m dazwischengeschaltet: FHZ wird nicht erkannt
2. ATEN USB Extender mit 10 m CAT-5 Kabel dazwischen geschaltet: FHZ
funktioniert "meistens", muss durch gelegentliches Neuladen des ftdi-
Treibers reaktiviert werden
3. ATEN USB Extender mit 20 m CAT-5 Kabel dazwischen geschaltet: FHZ
funktioniert "meistens", muss durch gelegentliches Neuladen des ftdi-
Treibers reaktiviert werden, manchmal hängt sich FHZ so auf, dass ein
Kaltstart des FHZ erfolgen muss (Kabel herausziehen und wieder
einstecken)
4. ATEN USB Extender mit 20 m CAT-5 Kabel dazwischen geschaltet und
Versorgung des Remote-Anschluss per 5V-Netzteil: keine Änderung zu 3.
5. ATEN USB Extender mit 10 m CAT-5 Kabel dazwischen geschaltet,
Anschluss an gepowertem Hub vom PC: FHZ wird nicht erkannt
Welche Alternativen gibt es ? Ich brauche 10 m, besser jedoch 20 m
Distanz zwischen FHZ und Server.
Danke für jeden Hinweis.
Martin
--
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.
Originally posted by: <email address deleted>
MSB wrote:
> habe FHZ 1300 PC an fhem (OpenSuse 11.1) laufen. Leider steht der
> Server ungünstig im Keller, so dass nicht alle Devices zuverlässig
> empfangen werden, wenn sich der Empfänger nur 1,8 m vom Server
> entfernt befindet. Habe folgendes probiert:
>
[...]
> Welche Alternativen gibt es ? Ich brauche 10 m, besser jedoch 20 m
> Distanz zwischen FHZ und Server. Danke für jeden Hinweis.
Mittel der Wahl wäre ein CUN im EG/wo auch immer passend anbringbar. Das
setzte natürlich voraus, daß Du außerhalb des Kellers (drahtgebundenes)
Netz hast.
Option Zwei: Sofern ein (Linux-) Rechner always on außerhalb des Kellers
sich befindet, socat nutzen und damit die Schnittstelle über's Netz ver-
längern.
Option Drei: USB-Extender kaskadieren mit *extern* bestromten USB-Hubs
dazwischen; bei mir konnte ich so *einige* (lies: definitiv nicht jede!)
USB-Cams bis zu 10m vom (Linux-) PC im Wohnzimmer im Garten betreiben
(PC -> aktive USB-Verlängerung, busgespeist -> USB-Hub, fremdgespeist ->
aktive USB-Verlängerung, busgespeist -> [USB-Hub, fremdgespeist ->] USB-
Cam). DAS ist aber eine ziemliche Frickellösung und ob es mit der FHZ
überhaupt geht, weiß ich nicht.
Falls Du den CUN nicht kennst: http://busware.de/tiki-index.php?page=CUN
Ciao,
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.
Oder FHZ 1300 PC verkaufen, 2x CUL kaufen, eines an den Rechner, das
andere als RFR (Funkrouter) einsetzen.
Klappt bei mir bestens.
On 30 Apr., 15:54, "Kai 'wusel' Siering"
wrote:
> MSB wrote:
> > habe FHZ 1300 PC an fhem (OpenSuse 11.1) laufen. Leider steht der
> > Server ungünstig im Keller, so dass nicht alle Devices zuverlässig
> > empfangen werden, wenn sich der Empfänger nur 1,8 m vom Server
> > entfernt befindet. Habe folgendes probiert:
>
> [...]
> > Welche Alternativen gibt es ? Ich brauche 10 m, besser jedoch 20 m
> > Distanz zwischen FHZ und Server. Danke für jeden Hinweis.
>
> Mittel der Wahl wäre ein CUN im EG/wo auch immer passend anbringbar. Das
> setzte natürlich voraus, daß Du außerhalb des Kellers (drahtgebundenes)
> Netz hast.
>
> Option Zwei: Sofern ein (Linux-) Rechner always on außerhalb des Kellers
> sich befindet, socat nutzen und damit die Schnittstelle über's Netz ver-
> längern.
>
> Option Drei: USB-Extender kaskadieren mit *extern* bestromten USB-Hubs
> dazwischen; bei mir konnte ich so *einige* (lies: definitiv nicht jede!)
> USB-Cams bis zu 10m vom (Linux-) PC im Wohnzimmer im Garten betreiben
> (PC -> aktive USB-Verlängerung, busgespeist -> USB-Hub, fremdgespeist ->
> aktive USB-Verlängerung, busgespeist -> [USB-Hub, fremdgespeist ->] USB-
> Cam). DAS ist aber eine ziemliche Frickellösung und ob es mit der FHZ
> überhaupt geht, weiß ich nicht.
>
> Falls Du den CUN nicht kennst:http://busware.de/tiki-index.php?page=CUN
>
> Ciao,
> 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 unterhttp://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.
--
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.
Originally posted by: <email address deleted>
On 30 Apr., 15:54, "Kai 'wusel' Siering"
wrote:
> Mittel der Wahl wäre ein CUN im EG/wo auch immer passend anbringbar. Das
> setzte natürlich voraus, daß Du außerhalb des Kellers (drahtgebundenes)
> Netz hast.
... das ist kein Problem. Zum Einsatz von CUN muss ich wohl eine extra
Firmware laden, oder ? Hat das Teil einen DHCP-Client ?
> Option Zwei: Sofern ein (Linux-) Rechner always on außerhalb des Kellers
> sich befindet, socat nutzen und damit die Schnittstelle über's Netz ver-
> längern.
heißt also, ich stecke das FHZ1300 an den Remote-Rechner (z. B. Plug-
PC). socat hat ja zillionen Möglichkeiten. Angenommen, der Remote-
Rechner hätte den Namen remotefhz und der Server den Namen masterfhz,
wie konfiguriere ich dann socat ? Muss ich das auf beiden Rechnern
laufen lassen ?
> Option Drei: USB-Extender kaskadieren mit *extern* bestromten USB-Hubs
> dazwischen; bei mir konnte ich so *einige* (lies: definitiv nicht jede!)
> USB-Cams bis zu 10m vom (Linux-) PC im Wohnzimmer im Garten betreiben
> (PC -> aktive USB-Verlängerung, busgespeist -> USB-Hub, fremdgespeist ->
> aktive USB-Verlängerung, busgespeist -> [USB-Hub, fremdgespeist ->] USB-
> Cam). DAS ist aber eine ziemliche Frickellösung und ob es mit der FHZ
> überhaupt geht, weiß ich nicht.
... heißt, dass ich in diese Möglichkeit besser keine Zeit
investiere ...
Gruß
Martin
--
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.
Originally posted by: <email address deleted>
Salve,
MSB wrote:
>> Mittel der Wahl wäre ein CUN im EG/wo auch immer passend anbringbar. Das
>> setzte natürlich voraus, daß Du außerhalb des Kellers (drahtgebundenes)
>> Netz hast.
>
> ... das ist kein Problem. Zum Einsatz von CUN muss ich wohl eine extra
> Firmware laden, oder ? Hat das Teil einen DHCP-Client ?
Eine aktuelle culfw drauf, damit geht dann DHCP als Client, ja.
>> Option Zwei: Sofern ein (Linux-) Rechner always on außerhalb des Kellers
>> sich befindet, socat nutzen und damit die Schnittstelle über's Netz ver-
>> längern.
>
> heißt also, ich stecke das FHZ1300 an den Remote-Rechner (z. B. Plug-
> PC). socat hat ja zillionen Möglichkeiten. Angenommen, der Remote-
> Rechner hätte den Namen remotefhz und der Server den Namen masterfhz,
> wie konfiguriere ich dann socat ? Muss ich das auf beiden Rechnern
> laufen lassen ?
Wenn ich mich recht entsinne, läuft auf remotefhz dann socat und in
der fhem.cfg sprichst Du dann die FHZ statt über /dev/whatever über
remotefhz:port an. In Verbindung mit socat & Deinem Rechner "remotefhz"
ist dann der CUL für FHEM quasi ein CUN ...
MfG,
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.
Originally posted by: <email address deleted>
On 2 Mai, 04:26, "Kai 'wusel' Siering" wrote:
>
> > ... das ist kein Problem. Zum Einsatz von CUN muss ich wohl eine extra
> > Firmware laden, oder ? Hat das Teil einen DHCP-Client ?
>
> Eine aktuelle culfw drauf, damit geht dann DHCP als Client, ja.
>
Hab die Hardware bestellt und checke das Ganze mal aus.
>
> Wenn ich mich recht entsinne, läuft auf remotefhz dann socat und in
> der fhem.cfg sprichst Du dann die FHZ statt über /dev/whatever über
> remotefhz:port an. In Verbindung mit socat & Deinem Rechner "remotefhz"
> ist dann der CUL für FHEM quasi ein CUN ...
>
Wäre 'ne gute Anwendung für einen Plug. Aber nach meinen Recherchen
ist für Sheeva im Moment Lieferstopp. Also teste ich erst einmal die
CUN-Lösung.
1000 Dank
Martin
--
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.
Originally posted by: <email address deleted>
MSB wrote:
[CUN]
> Hab die Hardware bestellt und checke das Ganze mal aus.
Das freut den Herrn Tostmann sicherlich ;)
>> Wenn ich mich recht entsinne, läuft auf remotefhz dann socat und in
>> der fhem.cfg sprichst Du dann die FHZ statt über /dev/whatever über
>> remotefhz:port an. In Verbindung mit socat & Deinem Rechner "remotefhz"
>> ist dann der CUL für FHEM quasi ein CUN ...
>
> Wäre 'ne gute Anwendung für einen Plug. Aber nach meinen Recherchen
> ist für Sheeva im Moment Lieferstopp. Also teste ich erst einmal die
> CUN-Lösung.
Aha? Naja, beim Hersteller steht »Note: We are receiving weekly
shipments of both GuruPlugs and SheevaPlugs. However, because of
the popularity of both products deliveries will be around 2-4 weeks
from date of ordering. Please check this site regularly for updates.«
Da würden mich doch glatt mal Verkaufszahlen SheevaPlug vs. iPad in-
teressieren; fänd' ich ja cool, wenn von den Sheevas wenigstens 100.000
unter die Leute gebracht worden wären bislang ...
kai
P.S.: Ich hatte bei NewIT eben nachgefragt bzgl. Lieferzeiten und ob das,
was im Shop bestellbar ist, auch geliefert werden kann. Antwort kam
grade rein -- zur Info:
"Our website reflects what we have in stock, and we have both the
standard White SheevaPlug and the eSATA Black SheevaPlug. If ordered
before 2pm (UK time) tomorrow orders will be shipped on that day."
PPS: Nein, ich bekomme keine Provision und will auch niemanden zur Bestellung
in UK mit den latenten Problemen konvertieren. Aber ich bin bislang ein
sehr zufriedener NewIT-Kunde, und wer jetzt Sheeva'n möchte und aus D ihn
nicht bekommt, dem kann ich jenen Laden aus meiner Erfahrung empfehlen.
YMMV, as always ;)
--
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.
Originally posted by: <email address deleted>
On 3 Mai, 17:03, "Kai 'wusel' Siering" wrote:
> MSB wrote:
>
> [CUN]
>
> > Hab die Hardware bestellt und checke das Ganze mal aus.
>
> Das freut den Herrn Tostmann sicherlich ;)
>
So, ich habe inzwischen zwei CUNs geflasht (ist nix für DAUs) und
angeschlossen. FHEM war zuvor auf 4.9 aktualisiert und anschließend
die cfg-Datei angepasst. Alles läuft soweit sehr gut, Kompliment an
die Entwickler. Ungewohnt sind nur die Hinweise auf die vorhandenen
Fensterkontakte, die CUL/CUN wohl direkt auswerten kann, sowie in
einer Installation periodische "LOVF"-Meldungen, die vermutlich
anzeigen, dass kein Senden auf dem HF-Kanal möglich ist.
Wieviele FHTs lassen sich denn maximal an einem CUN betreiben ? Hilft
der Betrieb mehrerer Interfaces (CUNs / FHZs) ?
--
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.
> Wieviele FHTs lassen sich denn maximal an einem CUN betreiben ?
Bei idealen Bedingungen beansprucht die 15-minuetlich stattfindende
Temperaturmeldung von einem FHT ca 6% der Sendekapazitaet der FHZ oder CUL, bei
schlechten Empfang mehr. Ueblicherweise ab 10 FHT's kommt damit auch ohne
andere Sendeaufgaben (von fhem getriggerte FHT Umstellungen oder FS20
Schaltbefehle) zu Problemen.
> Hilft der Betrieb mehrerer Interfaces (CUNs / FHZs) ?
Fuer die 1% Grenze ja, fuer die "Funkversmutzung" natuerlich nicht.
--
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.
Originally posted by: <email address deleted>
On 7 Mai, 08:28, Rudolf Koenig wrote:
> > Wieviele FHTs lassen sich denn maximal an einem CUN betreiben ?
>
> Bei idealen Bedingungen beansprucht die 15-minuetlich stattfindende
> Temperaturmeldung von einem FHT ca 6% der Sendekapazitaet der FHZ oder CUL, bei
> schlechten Empfang mehr. Ueblicherweise ab 10 FHT's kommt damit auch ohne
> andere Sendeaufgaben (von fhem getriggerte FHT Umstellungen oder FS20
> Schaltbefehle) zu Problemen.
Könnte man nicht die Frequenz der Temperaturmeldung automatisch
herabsetzen, wenn mehr als 10 FHTs in der config-Datei definiert
sind ? Lässt sich dieser Wert von 15 Minuten irgendwo im Code ändern ?
Momentan habe ich 18 FHTs angeschlossen, zwei weitere sind in
Planung ...
--
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.
> Könnte man nicht die Frequenz der Temperaturmeldung automatisch
> herabsetzen, wenn mehr als 10 FHTs in der config-Datei definiert
> sind ?
Gerne, muss man halt irgendwie das FHT80b firmware modifizieren. Bin aber
sofort dabei, wenn das "irgendwie" geklaert ist. Oder auch: _NEIN_ :)
> Momentan habe ich 18 FHTs angeschlossen, zwei weitere sind in
> Planung ...
Tapfer.
--
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.
Was Rudi meint ist:
Die FHTs bestimmten wann sie senden, es müsste also die Software der
FHTs verändert werden.
20 FHTs... sportlich.
--
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.
Originally posted by: <email address deleted>
> > Könnte man nicht die Frequenz der Temperaturmeldung automatisch
> > herabsetzen, wenn mehr als 10 FHTs in der config-Datei definiert
> > sind ?
>
> Gerne, muss man halt irgendwie das FHT80b firmware modifizieren. Bin aber
> sofort dabei, wenn das "irgendwie" geklaert ist. Oder auch: _NEIN_ :)
>
Dann habe ich die Fehlermeldung "LOVF" nicht verstanden. Ich dachte,
die bedeutet, dass CUN nicht mehr senden kann, da die Sende/
Empfangsratio überschritten wurde. Wenn die FHT80b Firmware involviert
ist, bedeutet es doch, dass die FHTs selbstständig senden, und das ist
CUN doch egal, oder nicht ? Bestimmt habe ich hier was elementares
nicht verstanden ...
> > Momentan habe ich 18 FHTs angeschlossen, zwei weitere sind in
> > Planung ...
>
> Tapfer.
>
Das Logging funzt ja ganz gut. Bekomme nur zwischendurch die besagten
"LOVF"s. Gibt es einen Trick, wie man beispielsweise mit einem zweiten
CUN die Sache verbessern könnte ?
M.
--
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.
Naja, zweites CUN oder CUL anschliessen, einrichten und dann die
Hälfte der FHTs per IODev auf die beiden CUN/CUL verteilen.
In etwa so:
define HZG_Kueche FHT abcd
attr HZG_Kueche IODev CUL1
Das sollte die 1% Regel entspannen.
--
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.
Originally posted by: <email address deleted>
MSB wrote:
>>> Könnte man nicht die Frequenz der Temperaturmeldung automatisch
>>> herabsetzen, wenn mehr als 10 FHTs in der config-Datei definiert
>>> sind ?
>> Gerne, muss man halt irgendwie das FHT80b firmware modifizieren. Bin aber
>> sofort dabei, wenn das "irgendwie" geklaert ist. Oder auch: _NEIN_ :)
>>
> Dann habe ich die Fehlermeldung "LOVF" nicht verstanden. Ich dachte,
> die bedeutet, dass CUN nicht mehr senden kann, da die Sende/
> Empfangsratio überschritten wurde. Wenn die FHT80b Firmware involviert
> ist, bedeutet es doch, dass die FHTs selbstständig senden, und das ist
> CUN doch egal, oder nicht ? Bestimmt habe ich hier was elementares
> nicht verstanden ...
Naja, immerhin habe ich es dann auch nicht verstanden ;)
Rudolf hat es in <20091221143518.GA16264@bzzz.fritz.box> am 2009-12-21 wie
folgt erklärt:
> LOVF = Limit-OVerFlow = 1% Sendezeit ueberschritten
>
> Die zweite Zahl beim "get CUL raw X" zeigt die verbliebene Sendezeit in 10ms
> Einheiten an. Eine der viertelstuendlichen Nachrichten von einer FHT
> entgegenzunehmen braucht ca. 53 Einheiten. Eine FS20 Nachricht senden ca 20
> Einheiten. 10 FHT's belegen ca 60% der Sendezeit eines CULs nur mit der
> Temperatur-Meldungen. Mehr wenn Nachrichten wegen schlechten Empfang wiederholt
> werden.
Ich sehe hier einen Widerspruch, und zwar "eine der viertelstuendlichen Nach-
richten von einer FHT entgegenzunehmen braucht ca. 53 Einheiten", wieso zählt
eine empfangene Nachricht -- ich gehe davon aus, auch die FHT80B senden nur bulk,
nicht bidirektional? --, das ist für mich ersteinmal widersinnig. Weil: dann
*kann* ein zweiter CUN nie nicht helfen, denn der müßte ja genauso *alles* rum-
gefunkte mitzählen, um die Sauberkeit des Kanals zu gewährleisten.
Ich interessiere mich nicht für das bestimmt lustige Regelwerk für 868 MHz (da
ich mir nicht erklären kann, wie IT+ mit 3-Sekunden-Intervallen auf der gleichen
Basis funktionieren könnte, wenn 10 Telegramme in 15 Minuten schon den Kanal zu
60% dicht machten), und ich schätze mal, das geht der Mehrheit hier so, daher
wäre ggf. doch mal eine gründlichere Erklärung, warum FHT-Empfang zu Lasten der
culfw-Sendezeit geht, hilfreich. Any takers? Danke ;)
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.
> 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.
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.
> 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.
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.
> 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.
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.
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.
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.
> (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.
>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.
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.
> - 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.
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.