Plug&Play: Help wanted

Hi all,

ich wirble gerade ein bisschen daran herum, den Plug-In und Plug-Out der FHZ PC USB Dinger im laufenden Betrieb sauber zu erkennen. Dabei könnte ich ein bisschen Hilfe gebrauchen, was die Geräteidentifikation angeht.

Ihr könntet mir helfen, wenn Ihr bei eingesteckter FHZ mal in den Gerätemanager von Windows geht, dort USB-Controller und das FHZ Device sucht und doppelklickt.

Auf der Details Seite gibt es einen Eintrag „Geräteinstanzkennung“ (im Deutschen Windows. Bei mir der erste Eintrag in der Liste. Da steht folgendes:

USB\VID_0403&PID_E0E8\EL3HRLD3

Weiter interessiert mich der „Friendly Name“ des Devices. Steht oben auf der Property Page. Bei mir „ELV FHZ 1300 PC“.

Ihr könntet mir helfen, wenn Ihr mir diese Infos für Eure Devices einstellt.

Merci Vielfalt, stararer

… mit einer solchen Resonanz habe ich nicht gerechnet. :slight_smile:

Cheers, starfarer

Die Bandbreite des Servers war nicht gros genug um dem Ansturm aller Antworten gerecht zu werden ! :smiley:

Nee, mal im Ernst, ich versteh mal die Frage nicht so richtig :confused:

mfG Franz

Hallo starfarer,

ich kann dem Franz nur zustimmen, ich verstehe Deine Frage auch nicht. Wenn Du direkt zur Hardware der FHZ Fragen hast, bist Du hier eh falsch, da musst Du Dich an ELV oder Ctr*cs wenden. Und was im Moment der Bezug oder die Frage zu IPSYMCON ist, wie gesagt, ich verstehe das im Moment auch nicht.

Gruss Torro

… ich wollte keine geheimen Informationen abfragen. :slight_smile:

Ich habe einen Windows Service implementiert, der USB FHZs steuern kann. Auch mehrere an einem Rechner, wenn es sein soll. Das Ding überträgt an und empfängt von Steuerungssoftware wie IP-Symcon, die gern irgendwo anders im Netz laufen kann. Installationen mit mehreren FHZs an verschiedenen Rechnern lassen sich durch eine zentrale IP-Symcon Instanz steuern, was aus meiner Sicht sehr viel mehr Charme hat, als mehrere IP-Symcon Instanzen zu installieren und auf Variablenebene den Programmablauf zu synchronisieren, um nur ein Beispiel zu nennen.

Weil ein Service robust funktionieren muss, sollte er auch das Rausreißen und Wiedereinstecken der FHZ ohne Neustart verkraften. Das ist weiter kein Problem, ich habe das spezifikationskonform implementiert. Es funktioniert ganz hervorragend mit den fünf FHZs, die neben mir liegen.

Ich wollte verifizieren, ob alle Devices im wirklichen Leben sich an die Spezifikation halten. Ich dachte, Ihr könntet einen halbwegs repräsentativen Set an IDs liefern. Aber egal.

Das Ding ist nicht, dass Ihr die Frage nicht versteht. Sie ist einfach genug. Es gibt kein Interesse zu antworten, weil nicht klar ist, was ich mit der Info will. Ich könnte das verstehen, wenn ich Eure Kreditkartennummer abgefragt hätte. In Bezug auf diese spezielle Information halte ich das für etwas kleinlich. Ich hatte ursrpünglich vor, mit dem fertigen Modul nicht so kleinlich zu sein. Auch deshalb war es mir wichtig, dass es mit Euren FHZs keine Probleme gibt. Ich lerne dazu.

Cheers, starfarer

Hallo starfarer,

den Sinn hab ich auch jetzt noch nicht verstanden. Wofür braucht man 5 FHZs und warum sollte man diese zwischendurch abziehen:confused:
Den Funktraffic kann man doch damit auch nicht überlisten.

Oder versuchst du mehrere Objekte/Locationen so auf einem Server zusammenzufassen, nach dem Motto Berlin, Paris, Tokyo und LA?:confused:

Weck doch mal unsere Neugier:D

Gruß

Kolja

säufts Wahrscheinlich muss man auch Progger sein um sein Anliegen zu verstehen.

Also:
Mehrere FHZ’s zu haben bietet einen Vorteil. Das „funken“ dieser Geräte ist auf 1% der begrenzt. Das Thema wurde vor kurzem hier besprochen. Man sollte nicht viel mehr als 4-5 FHT an einer FHZ anmelden oder man mus mit den daraus resultierenden Komforteinbußen leben. Wenn man nun aber 2 FHZ hat, und jede nur 1% sendet, sind das schon 2% (Milchmädchenrechnung, aber geht auf). Jede einzelne FHZ wird also ihr einzelnes Prozent voll ausschöpfen bis sie „auf stur“ schaltet. Zwei FHZ haben darüber hinaus zweimal so viel Puffer wie eine FHZ. Die Transaktionen der FHT sind also besser verteilt.

Gegen Kollisionen hilft das freilich nicht, die können aber auch bei einer einzelnen FHZ auftreten.

starfahrer hat nun einen Weg gefunden auf eine einfache und elegante Weise mehrer FHZ anzusteuern ohne dafür mehrere Instanzen IPS installieren zu müssen. Das bedeutet man braucht seine Scripte und Variablen nicht 2 mal schreiben, pflegen, anpassen, validieren. Und das hat noch weitere Vorteile. Weil man Variablen von einem IPS ind andere übertragen müsste (aufwendig). Mit starfarers Service stellt sich diese Problematik garnicht, weil nur einmal IPS auf dem Rechner läuft. Darum ist das Tool (ich nenn das mal so) für uns, der IPS-Community gut und sinnvoll. Auch weil, wenn ich ihn richtig verstanden habe, er aus einer USB-FHZ eine LAN-FHZ gemacht hat ohne das dabei die Garantie erlischt. Er benutzt dafür den LAN-Adapter einer Windows-Maschiene.

Wo sein Problem liegt:
Er möchte das Programm robust und pflegeleicht für den Anwender (euch, wenn ihr lieb fragt und ihm schön helft) schreiben. Ansonsten würde, im schlimmsten Fall, jedes mal nach dem ziehen des USB-Steckers einer der FHZs ein Neustart des Rechners notwendig werden. Das wäre nicht schlimm, ist aber auch nicht schön. Nach dem Wiedereinstecken sollte das Gerät automatisch als das Alte, was noch vor Sekunden/Minuten/Tagen dort steckte, wiedererkannt werden. Hiefür ist es wichtig dass das Programm korrekt den internen Namen der vielen in Deutschland/Luxemburg/Belgien verkaufen FHZs erkennt und zuweisen kann.

Aber wie können denn die Teile heissen? Haben vielleicht verschiedene Serien verschieden aufgebaute Namen oder ist das alles eine Wurst? Darum bittet er euch um eure hilfe. Sagt ihm wie eure FHZs heissen. Dann kann er das besser abschätzen. Wenn ihr etwas ängstlich seid wegen der Nummer könnt ihr ihm ja ne PM schicken. Ich glaub aber echt nicht, dass man damit irgendetwas (böses) anfangen kann.

@starfarer: Ich werd dich unterstützen wo ich kann, hab allerdings (noch) keine FHZ am werkeln.

Edit:

Achso, die genauen Fakten zu seinem Windows-Dienst kenne ich auch nicht. Ich hab hier nur die Informationen aus diesem Thread mit meinen Erfahrungen als Entwickler zusammengefasst.

Toni

Das Ding ist nicht, dass Ihr die Frage nicht versteht. Sie ist einfach genug. Es gibt kein Interesse zu antworten, weil nicht klar ist, was ich mit der Info will. Ich könnte das verstehen, wenn ich Eure Kreditkartennummer abgefragt hätte. In Bezug auf diese spezielle Information halte ich das für etwas kleinlich. Ich hatte ursrpünglich vor, mit dem fertigen Modul nicht so kleinlich zu sein. Auch deshalb war es mir wichtig, dass es mit Euren FHZs keine Probleme gibt. Ich lerne dazu.

Wäre das deine Frage gewesen:
Habt ihr Probleme mit der FHZ, wenn ihr den USB-Stecker ab- und kurze Zeit später wieder an- gestöpselt habt?
Nicht böse sein, aber habe ich auch nicht verstanden.
MfG
Helmut

Ihr könnt das Problem ja noch garnicht haben, weil das Problem nur auftritt mit der Software, die starfarar grade schreibt. Niemand ausser ihm hat diese Software… Seine Frage war schon korrekt so. Aber Programmierer, mich eingeschlossen, leben nun einmal manchmal in ner anderen Welt - und das muss auch so sein.

Er hätte höchstens mehr Hintergrundinformationen liefern können, was ich versucht habe nachzuholen.

Hallo starfarer,

dank Tonic hab ich glaub ich jetzt begriffen was du machen willst :rolleyes:…

Hast du auch interesse an den Daten einer FHZ 1000 PC?

Wenn ja kann ich dir die Daten heute abend liefern…

USB\VID_0403&PID_F06F\ELU0V90X

und

„ELV FHZ 1000 PC“

… das geht aber ab. Sorry, ich dachte, ich stelle nur ne harmlose Frage. :slight_smile:

Was Tonic schreibt, ist im Prinzip richtig. Kleine Korrekturen:
Man müßte im Falle des Plug Out und wieder Plug In nicht den Rechner neu starten, aber den Windows Service. Verwaltung Dienste, den Serive stoppen, wieder starten. Das ist lästig und blöd.

Einsatzmöglichkeiten: Zum einen die Erweiterung des Sendezeitlimits (wenn es an der FHT Front eng wird). Überlagerungsprobleme bei mehreren gleichzeitig sendenden FHTs kann man natürlich nicht beeinflussen, allerdings sorgt der Service dafür, dass mehrere angeschlossene FHZs nicht gleichzeitig senden. Hier gibt es also keine Überlagerungen.

Zum anderen kann man auch die Reichweite gezielt erweitern. Hat man mehrere Rechner in verschiedenen Bereichen stehen, kann IPS auf weitere Strecken „hören“, was die Schalter und Sensoren sagen. Und es kann Aktoren auf größere Distanz ansprechen. Nicht unintelligent wie über den Repeater, sondern über die direkte Zuordnung von Schaltern zu FHZs an verschiedenen Orten. Also, das Licht im Dachgeschoss schalte bitte mit der FHZ eine Etage darunter, das Licht in der Garage bitte über die FHZ im Keller. Da wird in diesem Fall nix repeated.

Aber auch ein intelligenter Repeater-Mode ist möglich. wenn man das möchte. Eine Haupt-FHZ, die sendet, eine weitere irgendwo, die empfangene Signale repeaten soll. Bessere Kontrolle wird dadurch erreicht, dass die als Repeater fungierende FHZ den Ihre Aktivitäten über das Netz zurückmeldet und so die Haupt-FHZ erfährt, dass die Repeater-FHZ das Signal übernommen und neu ausgestrahlt hat. Ist ein möglicher Anwendungsfall, ob der sinnvoll ist, lasse ich mal dahingestellt.

Ohne Garantieverlust eine Ethernet-FHZ. Man kann das technisch so sehen. Aber wie Torro schon sagt, ein PC fungiert als Schnittstelle zwischen Ethernet und FHZ. Ich nehme mal an, dass so ein PC wesentlich teurer ist als der maximale Schaden durch Garantieverlust. Buchhalterisch ist diese Sicht daher nur eingeschränkt sinnvoll. :slight_smile:

Vielen Dank für die Info zur FHZ 1000 PC! Die verwendet in der Tat eine andere PID als die FHZ 1300 PC, so dass ich ein Device mit dieser Kennung bis eben als inkompatibel klassifiziert hätte. Nun nicht mehr.

Ich habe hier nur FHZ 1300 rumliegen. (Weil ich im Stillen davon ausgegangen bin, dass sich die Dinger sowieso nur vom Aufdruck und vom „Friendly Name“ unterscheiden :D).

Hat vielleicht einer eine FHZ 1350 PC? Die hat vielleicht noch eine andere Kennung.

Es wird noch ein bisschen Zeit brauchen, bis ich Euch das Ding zum Test zurückspielen kann. Im Moment frühstücke ich die FHZ Seite ab, aber das ist nur die halbe Miete. Ich muss ja auch noch über eine der unterstützten Schnittstellen ins IPS.

Cheers, starfarer

Naja, für nen Laien wäre es wohl auf nen Neustart rausgelaufen.

Kommt drauf an. Wer eh nen zweiten Rechner stehen hat, der günstiger liegt (z.B. Mediaserver Wohnzimmer) als die IPS Maschiene, die vielleicht im keller steht kommt recht günstig weg. Und ne oller PII der im keller rostet ist auch immernoch billiger als der Xport. Glaube der liegt um die 70 Euro + Porto/Verpackung. Und eingebaut werden will der auch noch, was nicht jedermanns sache ist.

Hallo Tonic1024,

Deine Ausführungen zum Thema sind sehr umfassend und klingen auch sehr logisch.

Dennoch bich ich der Meinung in einem wesentlichen Punkt widersprechen zu müssen.

Ich habe mich ebenfalls schon mehrfach zu diesem Thema geäußert und musste immer wieder feststellen, dass es eine weit verbreitete Ansicht ist durch den Einsatz mehrerer FHZ die hier im Forum diskutierten Problem lösen zu können.

Das ist nicht der Fall.

In jüngster Zeit wurde ein neuer Sündenbock entdeckt, der für die im Puffer hängengebliebenen Telegramme verantwortlich gemacht wird: die 1%-Sende-Grenze. Leider bin ich daran nicht ganz unschuldig. Diese Beschränkung wird jedoch maßlos überschätzt, da kaum jemand eine Vorstellung davon hat, wie lange ein durchschnittliches Telegramm wirklich dauert. Bei einer mittleren Telegrammlänge von 100ms (für FHTs) steht also pro Stunde eine Sendekapazität von 360 Telegrammen zur Vefügung. Es könnten also (rein theoretisch!!) ca 90 FHTs pro Stunde mit jeweils zwei Telegrammen versorgt werden. Daran sieht man, das der begrenzende Faktor auf keinen Fall die ominöse 1%-Grenze sein kann. In Wirklichkeit ist die Kapazität sogar fast doppelt so hoch, da ja nur die reine Sendezeit hier zu berücksichtigen ist. Im Mittel besteht ein Datenstrom aber aus etwa gleichviel Einsen und Nullen. Da die FHZs eine 100% Amplitudenmodulation verwenden, wird also nur während der Hälfte der Telegrammzeit wirklich gesendet.

Die 1%-Grenze wird also auch bei großen Funknetzen in der Praxis nicht erreicht.

Wir alle wissen natürlich, dass es bereits mit sehr wenigen FHTs zu Problemen kommen kann. Und hier komme ich auf den eigentlichen Verursacher zurück: die Kollisionen. Hierzu habe ich bereits eine ausführliche Beschreibung geliefert: http://www.ipsymcon.de/forum/showthread.php?p=7197#post7197
Das Problem ist 1. das Übertragungsmedium und 2. der Mangel des Protokolls mit Kollisionen umzugehen zu können.

Das Übertragungsmedium ist hier der Raum (oder die Luft), und der ist für alle beteligten der selbe, auch für den Nachbarn, der evtl. ebenfalls Besitzer von FS20 Komponenten ist. Dieses Medium müssen sich alle Beteiligten teilen. Kollisionen sind für alle Telegramme fatal. Selbst wenn nur eine Überlappung von wenigen Millisekunden stattfindet, sind beide Telegramme bereits verfälscht und damit verloren.

Das Protokoll bietet hierfür keine Lösung, wie das etwa bei Ethernet der Fall ist. Kollisionen werden weder erkannt, geschweige denn aufgelöst.

Die Verwendung mehrerer FHZs am selben Standort bringt überhaupt nichts.

Je mehr Sender vorhanden sind, umso größer ist die Gefahr für Kollisionen. Der Versuch hierdurch eine Art Arbeitsteilung zu erreichen ist sinnlos. Ein Telegramm, das gerade gesendet wird, wird von allen im Umkreis befindlichen Empfängern aufgenommen, obwohl es ja nur für einen einzigen bestimmt ist. Die anderen verwerfen alles, was nicht an sie selbst adressiert ist. Um aber festzustellen ob man selbst oder eine anderer der rechtmäßige Empfänger ist, muss das Telegramm auf jedenfall erst einmal geprüft werden. Eine FHZ kann also nicht zur selben Zeit erfolgreich mit einem anderen Teilnehmer kommunizieren.

Eine Aufteilung ist nur dann sinnvoll, wenn Kapazitäten ungenutzt sind. Da aber nicht die FHZ am Anschlag ist sondern das verwendete Übertragungsmedium (die Funkstrecke), hat es keinen Sinn dort zu entlasten, wo es gar keine Last gibt. Keine der beteiligten FHZs wird ihr 1%-Kontingent ausschöpfen können und zwar weil sie überhaupt nicht dazu kommt. Es gibt leider keine Möglichkeit die Anfragen der FHTs in irgendeiner Weise zu beeinflussen. Daher muss man (bis heute zumindest) damit leben, dass die FHTs ständig durch Kollisionen ihre eigenen Telegramme vernichten. Somit bleibt eine FHZ eben häufig auf ihren Telegrammen sitzen, da die zugehörigen Anfragen verlorengegangen sind.

Die Einteilung eines Funknetzes in Dachgeschoss, erster Stock, Erdgeschoss und Keller klingt unheimlich einleuchtend für alle, die sich nicht darüber im Klaren sind über welche Wege hier kommuniziert wird. Es ist nun mal nicht möglich diese Wege zu trennen (Metallwände zur Abschirmung oder riesige Wohnungen, wo man die nächste FHZ außer Funkreichweite der anderen platzieren kann…).

Tonic1024, Du hast eine sehr überzeugende Begründung geliefert, wenn da nur nicht dieses eine kleine nicht ins übrige Bild passende Puzzle-Steinchen wäre. Ausgrechnet das ist aber die Grundlage.

Nichts für ungut…

Gruß
HJH

Also ich habe nun nicht so die Ahnung vom Programmieren…
Liegt es nur an der FHZ und dessen Möglichkeiten?
Wäre nicht eine bessere Hardware, mit mehr Buffer für die zu sendenden- und empfangenden- Daten, eine Hilfe, geschweige denn von den Kosten? Ein Programm, in Bascom, für einen AVR-MikroController, der HMS, FHT und FS20 empfangen und senden kann (über die ser. Schnittstelle) hätte ich anzubieten. Ist für private Anwender frei, darf nicht kommerziell ohne Zustimmung des Autors verwand werden. Wer Interesse hat schicke mir ein PM. Gibt es aber nur, wenn alle von der eventuellen Weiterentwicklung profitieren!
Sollte selbstverständlich sein!
MfG
Helmut

Hallo Helmut,

HJH hatte es ja schon ausfuehrlich und sehr anwenderfreundlich beschrieben: Das Problem ist nicht die Hardware, sondern das Uebertragungsprotokoll „FUNK“. Da kannst Du auch mit den geschicktesten Routinen nichts dran aendern.

Als Beispiel mal etwas bildlich:

Du hast einhundert Tennisbaelle, die jeweils 5 Leute erhalten sollen. Jetzt stellst Du Dich an die Tuer eines Zimmers, schmeist einen rein und sagst, der ist fuer Mann 1. Der holt ihn sich. Alles ok. Das kannst DU so 100mal machen, klappt perfekt. Jeder erhaelt genau den fuer ihn bestimmten Ball.

Jetzt neu:
Du nimmst 5 Baelle, schmeisst sie in das Zimmer, die 5 Mann holen sich die Baelle. Jeder erhaelt einen Ball, ist es aber der Richtige? Hoffentlich.
Wenn Du nun aber 10 Baelle reinschmeisst (passen ja auch in den Raum gluecklicheriweise rein), und die 5 Leute holen sich wieder 5 Baelle, dann wissen die aber nicht, welche. Also haben dann 2 vielleicht Glueck, der Rest hat Pech. Das heisst, 8 Baelle waren fuer den Muell…es hat kollidiert.

Da kann das Zimmer noch so gross sein, das nuetzt alles nix.

Gruss Torro

Usb\vid_0403&pid_f06f\eltkzqo6

Elv Fhz 1000 Pc

zuerst @HJH:

Die Verwendung mehrerer FHZs am selben Standort bringt überhaupt nichts.

Je mehr Sender vorhanden sind, umso größer ist die Gefahr für Kollisionen. Der Versuch hierdurch eine Art Arbeitsteilung zu erreichen ist sinnlos. Ein Telegramm, das gerade gesendet wird, wird von allen im Umkreis befindlichen Empfängern aufgenommen, obwohl es ja nur für einen einzigen bestimmt ist. Die anderen verwerfen alles, was nicht an sie selbst adressiert ist. Um aber festzustellen ob man selbst oder eine anderer der rechtmäßige Empfänger ist, muss das Telegramm auf jedenfall erst einmal geprüft werden. Eine FHZ kann also nicht zur selben Zeit erfolgreich mit einem anderen Teilnehmer kommunizieren.

Eine Aufteilung ist nur dann sinnvoll, wenn Kapazitäten ungenutzt sind. Da aber nicht die FHZ am Anschlag ist sondern das verwendete Übertragungsmedium (die Funkstrecke), hat es keinen Sinn dort zu entlasten, wo es gar keine Last gibt. Keine der beteiligten FHZs wird ihr 1%-Kontingent ausschöpfen können und zwar weil sie überhaupt nicht dazu kommt. Es gibt leider keine Möglichkeit die Anfragen der FHTs in irgendeiner Weise zu beeinflussen. Daher muss man (bis heute zumindest) damit leben, dass die FHTs ständig durch Kollisionen ihre eigenen Telegramme vernichten. Somit bleibt eine FHZ eben häufig auf ihren Telegrammen sitzen, da die zugehörigen Anfragen verlorengegangen sind.

Die Einteilung eines Funknetzes in Dachgeschoss, erster Stock, Erdgeschoss und Keller klingt unheimlich einleuchtend für alle, die sich nicht darüber im Klaren sind über welche Wege hier kommuniziert wird. Es ist nun mal nicht möglich diese Wege zu trennen (Metallwände zur Abschirmung oder riesige Wohnungen, wo man die nächste FHZ außer Funkreichweite der anderen platzieren kann…).

Tonic1024, Du hast eine sehr überzeugende Begründung geliefert, wenn da nur nicht dieses eine kleine nicht ins übrige Bild passende Puzzle-Steinchen wäre. Ausgrechnet das ist aber die Grundlage.

Nichts für ungut…

also, du weisst sicher, dass Theorie und Praxis oft weit auseinander liegen. Dein Post kling zwar ganz einleuchtend, und dennoch bin ich der Meinung, dass du hier viel Theorien „und-wie-es-funktionnieren-müsste“ aufgelistet, doch hast du das dann auch tatsächlich ausprobiert? Es sind in diesem Forum nicht viele, die mehr als 10 FHT’s zu verwalten haben.

Nichts für ungut…

@Torro:

Du nimmst 5 Baelle, schmeisst sie in das Zimmer, die 5 Mann holen sich die Baelle. Jeder erhaelt einen Ball, ist es aber der Richtige? Hoffentlich.
Wenn Du nun aber 10 Baelle reinschmeisst (passen ja auch in den Raum gluecklicheriweise rein), und die 5 Leute holen sich wieder 5 Baelle, dann wissen die aber nicht, welche. Also haben dann 2 vielleicht Glueck, der Rest hat Pech. Das heisst, 8 Baelle waren fuer den Muell…es hat kollidiert.

Es wird ja auch weiterhin nicht geplant 10 Bälle miteinandern reinzuschmeissen. Das zeitversetzte Versenden von Telegrammen wird weiterhin bestehen, also bei mir wäre das 10 Bälle einer nach dem anderen reinschmeissen, dann kommt es nicht zu Kollisionen (mit einer oder mehreren FHZ’s). Auf dem anderen Wege, also FHT > FHZ müsste es eine Bestätigung von der FHZ geben, ein Telegramm ist sicher angekommen, da ELV ja sicherlich das Thema bewusst war, dass mehrere FHT’s senden könnten und schon ab 2 FHT’s Datensalat ankommen würde. Mir geht es ja auch nur drum, die Wartezeit zwischen „IPS > FHZ“ und „FHZ>FHT“ zu verkürzen.
Und entgegengesetzt den Theorienvon HJH hat das auch geklappt. Ich hatte vor kurzem meine FHZ1300WLAN zusammen mit der FHZ1000 für eine kurze Zeit an der CONTR***CS Software laufen, und das hat tadellos geklappt. Ich konnte ganze Datenpakete, also Wochenprogramme, in kürzerer Zeit verschicken an 11 FHT als zuvor mit nur einer FHZ

ok, dies ist für einen Laien (mich) ein wenig kompliziert, doch das Grundprinzip habe ich verstanden.

Zu diesem Thema:

Und es kann Aktoren auf größere Distanz ansprechen. Nicht unintelligent wie über den Repeater, sondern über die direkte Zuordnung von Schaltern zu FHZs an verschiedenen Orten. Also, das Licht im Dachgeschoss schalte bitte mit der FHZ eine Etage darunter, das Licht in der Garage bitte über die FHZ im Keller. Da wird in diesem Fall nix repeated.

Ich dachte immer, IPS hätte diese Funktion? Ich kann ja im InstanzenFenster bestimmen, welche FHZ ich mit welchen FHT’s, F20 verknüpfe, oder nicht?
Ich habe noch keine zweite FHZ, wird aber demnächst kommen, sobald meine FHZ WLAN funktionnieren wird mit IPS.

Ich plane doch tatsächlich 2-3 WLAN FHZ’s zu installieren. Das soll jetzt nicht protzig sein oder Luxus, sondern will ich einfach meine FHT’s sauber und mit einer 3% Sendequote betreiben, um die Wartezeiten runterzuschrauben.
Thema Kollisionen weiss ich noch nicht, das wird sich ja dann raustellen !

Zu diesem Thema:

USB\VID_0403&PID_F06F\ELU0V90X

Wo bitte schön kann ich das auslesen und dann hier mitteilen?

mfG Francis

ahh, habe es gefunden:

USB\VID_0403&PID_F06F\ELU0VBFD

auch eine FHZ1000PC

mfG Franz

… Ihr habt recht, Kollisionen sind ein Thema. Aber eher auf der Seite der FHTs. Die senden Ihren Kram unabgestimmt mit anderen FHTs und wenn Ihr das große Pech habt, dass welche immer gleichzeitig wollen, kommt es zu Problemen.

Insbesondere wächst die Wahrscheinlichkeit solcher Kollisionen recht schnell recht stark an, was die Probleme schon bei geringen Zahlen von Geräten erklärt. Mit der Teilung der verfügbaren Sendezeit durch Telegrammlänge ist es nicht getan, es können keinesfalls 90 FHTs unterstützt werden. Auch lässt sich Zahl der FHTs, die man parallel betreiben kann, nicht durch Erhöhung der Zahl der FHZs steigern. Hier muss mit Kollisionswahrscheinlichkeiten gerechnet werden, beim Betrieb von 90 FHTs ist die Kollisionswahrscheinlichkeit sehr hoch. Auch schon bei sehr viel kleineren Zahlen an FHTs. Und die erzeugen munter Ihre Kollisionen, egal wieviele FHZs zuhören.

Was aber mehrere FHZs an einem Standort betrifft, so ist kann die Software das Senden der Instanzen koordinieren. Hier kommt es dann definitiv nicht zu Kollisionen. So könnte man die FHZs 1 an FHTs binden und den FS20 Funkverkehr über eine zweite FHZ machen, wobei die FHZs kollisionsfrei senden. Wie gesagt, das koordiniert die Software.

Grundsätzlich liegt es nicht am Medium Luft und Funk, dass Kollisionen auftreten können. Das ist auch anderen Medien der Fall, etwa im Ethernet. Die Kollisionen werden auf der Protokollebene behandelt. Wenn Du etwa ein TCP/IP-Package bekommst, dann ist das verifiziert. Ob vorher andere Versuche, das gleiche Paket zu übertragen, gescheitert sind, erfährst Du gar nicht, weil das auf tieferen Protokollebenen behandelt wird.

Wer das mit den Kollisionen im Ethernet nicht glaubt, schicke mal in einem Ethernet im gleichen IP-Subnetz von Rechner A eine große Datei nach Rechner B und gleichzeitig eine von Rechner C nach Rechner D. Da wird sehr schön deutlich, dass die Summe der Datenübertragungsraten weit unter der Bandbreite des Netzes bleibt. Ausnahme: Ihr habt Gigabit-Ethernet. Da liegen die Limitierungen im Rechner selbst, d.h. der Rechner kriegt die Daten nicht mit der Geschwindigkeit aufs Netz, wie das Netz sie abtransportieren könnte.
Mehr als (sehr optimistische) 50 MB pro Sekunde leistet hier kein normaler PC. Häufig sogar nur 20-30 MB /Sek. Von solchen Übertragungen kann es mehrere parallel geben, und das Netz lacht sich immer noch schlapp und es treten nicht allzu viele Kollisionen auf.

In einem 100 MBit Ethernet beträgt die theoretische max. Übertragungsrate 12,5 MB pro Sekunde. Ein gewisser Teil geht für Protokoll-Overhead drauf, zusätzliche Daten die neben den Nutzdaten übertragen werden müssen. Ein weiterer Teil geht für Kollisionen drauf. Eine schlechte Ethernet-Installation kann man auch daran erkennen, dass die Nutzdatenrate häufig unter 60% der Bandbreite fällt. Das heißt, zuviele Geräte im gleichen Subnetz, zu viele Kollisionen. In einer vernünftigen Installation sind 60-70% Datenrate zu erwarten.

Grundsätzlich geht Kollisionsbehandlung auch bei Funk, aber nicht bei einem unidirektionalen System wie FS20. Es sind aber Systeme nicht nur denkbar, sondern auch im Handel, die bidirektional arbeiten, d.h. die Schalter bestätigen den Eingang des Schaltsignals und die ausgeführte Schaltaktion. Eine einfache Art der Kollisionsbehandlung bei so einem System kann so aussehen, dass der Sender im Falle, dass die Bestätigung ausbleibt, solange wiederholt, bis er Bestätigung bekommt.

Man könnte aber auch auf Protokollebene mit Bustokens arbeiten (Funk ist nichts anderes als ein Bus). Die Geräte erhalten nach irgendeinem Schema ein Sendeberechtigungstoken, und nur das Gerät, dass das Token besitzt, darf senden. So werden Kollisionen vermieden. Im Bereich kabelgebundener Netze arbeitet der Tokenring nach so einem Schema. Das Token wandert nach irgendwelchen Kriterien von einem Gerät zum anderen, zeitlich gesteuert, oder die Geräte beantragen das (mit Kollisionsrisiko) solange, bis sie es bekommen. Der Heuristiken sind da viele.

Ein Prozent Sendezeit ist nicht mehr so furchtbar viel, wenn man den Bandbreitenverbrauch, der durch eine Kollisionsbehandlung entstünde, in die Kalkulation einbezieht.

Was IPS angeht, konzeptionell werden mehrere FHZs unterstützt, soviel ist klar. Du kannst mehrere von diesen Instanzen definieren und geeignet verbinden. Die Frage ist halt, wo sind die dazu gehörenden Geräte denn? Alle am IPS PC, wenn IPS auch auf der Geräteebene mehrere FHZs unterstützen sollte. Ich habe das nicht verifiziert.

Und auch wenn IPS mit mehreren FHZs arbeiten kann (wie gesagt, ich weiß es nicht), weiß ich weiter nicht, ob IPS dann managed, dass die kollisionsfrei senden.

Trotzdem, ich stimme zu, dass der Einsatz meines Services mit FHZs überlegt werden muss. Ich denke, es gibt sinnvolle Einsatzmöglichkeiten, aber auch gewisse Beschränkungen, die in diesem System liegen. Die Software ist aber in Ihrem Einsatz nicht auf FHZs beschränkt, es gibt andere Systeme, die von der Architektur stärker profitieren könnten.

Vielen Dank nochmal für die USB-Kennungen. Ich habe inzwischen auch offiziell verifizieren können, dass dies die Produktkennung der FHZ 1000 und FHZ 1300 sind.

Cheers, starfarer