Das Microlink ist keine USB Verlängerung. Ein paar User haben hier schon diverse USB -> LAN Geräte versucht, aber es hat mit der FHZ nicht richtig Funktioniert. Die einzige vernünftige Lösung die FHZ per LAN anzusteuern die die Anleitung die in der Wiki beschrieben ist. (Ja, die Anleitung ist getestet und funktioniert einwandfrei 
)
Grüße, paresy
@ Torro,
An, Aus, An, Aus, An, Aus, An, Aus, An, Aus, An, Aus, …(siehe Grafik © by Torro)
Ganz normale Gastherme…
Gruß MST
Hallo paresy,
ich hoffe aber, das ihr die IPS User die schon ein haufen Geld in FHT’s investiert haben, nicht im Regen stehen lasst :(. Ich denke da so an den fehlenden FHT Puffer im IPS und einer Rückmeldung, ob die FHT Befehle in der FHZ angekommen sind oder ob man sie im Nirwana versenkt hat.
Grüße, Keule
Mich würde in diesem Zusammenhang interessieren ob es sich hierbei um eine hardwaremässige Begrenzung handelt oder ob diese per Software vorgegeben ist?
Bisher von meinung das es der HW puffer ist die probleme gibt.
Es gibt einen Max Hardwarepuffer von 10 FHT Befehlen. Dieses Problem wird softwareseitig noch nicht abgefangen, ist aber in Arbeit.
Grüße, paresy
Hier ist dauernd von irgendwelchen Pufferüberläufen und so die Rede was sicherlich auch ein Problem darstellen wird, aber eines wird hier ganz vergessen bzw. tritt komplett in den Hintergrund.
Die Genehmigung für das 868,35Mhz Funknetz setzt vorraus, dass die den Sender ( Sendeplatine ) ansteuernde Hardware ( FHZ1000PC / FHZ1300PC ) Sorge dafür trägt, das die maximale Sendezeit von 36 Sekunden pro Stunde nicht überschritten werden kann.
Die Funkwellen breiten sich zwar in Lichtgeschwindigkeit aus, dennoch dauert die Übertragung eines Datenrahmens zwischen 47,2ms ( alles Lows ) und 70,8ms ( alles Highs ), was demnach Durchschnittlich 59ms für einen Datenrahmen bedeutet.
Gehen wir jetzt also davon aus, das der Sender selber davon die halbe Zeit sendet, dann lassen sich demnach max. 36000ms/29,5ms= 1120 Datenrahmen je Stunde übertragen.
Ihr habt Recht, das ist eine ganze Menge, aber bei der Übertragung der FS20-Befehle wird der Datenrahmen gleich 3 mal gesendet, was 406 FS20-Befehle entspricht. Ups, ist ja immer noch eine ganze Menge gelle?
Bei der FHT sieht es schon wieder anders aus, hier wird nicht wie bei FS20 ein einzelner Befehl übermittelt sondern ein ganzes Datenpaket. Jeder übermittelte Wert bedeutet dabei ein Datenrahmen!
Im Unterschied zur FS20 wird der Datenrahmen hier allerdings nicht 3 mal wiederholt, da wäre die Grenze des erlaubten ( Sendezeit ) schnell überschritten, sondern nur einmalig gesendet.
Was die Sendezeit entlastet bedeutet allerdings eine höhere Störanfälligkeit bei der Übertragung und so kann natürlich in einem größeren Funknetzwerk wie die Kommunikation der FHZ1000PC mit 26 FHT80b´s schon mal etwas verloren gehen.
Vom praktischem sieht es so aus:
FHT 1 sendet eine Stellgröße zum Ventil, die FHZ1000 bekommt den Anfang des Datenrahmens mit und beginnt die Bits zu speichern ( insg. 59 Bit ).
FHT 2 möchte seine IST-Temp./ Fensterkontakt o. ä. melden und beginnt während FHT 1 beim 25 Bit ist.
Jetzt gehen wir mal davon aus, dass das Signal der FHT 1 trotz Überlagerung der Funkwellen weiterhin einwandfrei empfangen werden kann, dann wird die FHZ1000PC immer noch das garnicht für sie bestimmte Signal der FHT 1 auswerten und das für sie bestimmte Signal von FHT 2 verpassen.
Es ist nämlich erst nach dem Empfang des 59. Bit´s einwandfrei feststellbar, für wem bzw. von wem der Datenrahmen ist.
Das gleiche gilt jetzt natürlich auch bei der Datenübertragung vom FHZ1000PC zum FHT.
MfG Hansi
Leuchtet mir ein ! Eigentlich kann man das ganze nur umgehen, indem man mehrere FHZ1x00´s mit IPS steuert. Hiermit kann man die Begrenzung der Regulierungsbehörde umgehen.
Ja so ist es, schließt Du 100 FHZ´s an Deinem PC an, dann kannst Du ganz legal das 868,35MHz Funknetz Deiner Nachbarschaft lahmlegen 
Hm, das die Sendezeit begrenzt ist, ist ein Problem. Aber war am Anfang der Diskussion nicht die Rede davon das Informationen > NULL gehen? Auch oder besser gerade wenn die Sendezeit so streng kontigentiert ist bedarf es hier eines geschickten Managements des Sendepuffers 
Ich vermute mal, das der Sender selber weiss was er wie oft senden darf und das vorgelagerte System die Daten in die Pipeline schaufelt.
Logischerweise müsste dann entweder Hardwarepuffer vergrössert werden oder aber eine clevere Softwarelösung her um diesen begrenzten Puffer zu verwalten. Am besten wäre natürlichen ein cleveres Übertragungsprotokoll.
In diesem Zusammenhang eine andere Frage: Bietet diese Funktechnik tatsächlich nur einen Kanal? Gäbe es zwei, einen zum senden und einen zum Empfangen, bräuchten die Datenpäckchen ja nicht immer im Raum zu kollidieren… 
Das diese Lösung evtl. nicht implementiert ist, ist eine andere Frage.
Wer eh soviele Endgeräte betreibt, wird, denke ich, eine zweite FHZ verkraften…
die antwort ist ganz einfach : kollisionen -> @Crazy : es kommt keine 59er bit rein wenn ein anderen sendet ! die botschaft des anderen kommt auch nicht rein… also bevor man es weisst bekommt man Italianischer salat wo nicks mehr schmekt ! Got behute dich
Hatte mal gerne die diskussion gehort zwichen 2 FS20 nachbaren in ein appartement „ich bin dran“ - „'tschuldige mich aber meine frau …“ - „ist endlich fertig mit meine waschmachine …“ - „also wirklich : der vibrator ?? neee“ - „halt deine klappe …“
Gleiche geschochte mit die FS-repeater : mehrere FHZ’s werden es nicht lösen … die 868Mhz ist schuld nicht die FHZ o. IpS (das laetzte mit a b s o l u t e r sicherheit)
Jaja, der liebe Repeater.
Auch der führt öfters zu Datenkollisionen, nämlich dann, wenn Du mehrere Aktoren direkt nacheinander schalten möchtest ( z.Bsp. die Rolläden ).
Ich habe mittlerweile in den Scripts nach jedem Schaltbefehl eine Pause eingebaut.
MfG Hansi
… es muss ja nicht immer Funk sein. Das gute alte X10-Protokoll tut es für Schaltaufgaben auch.
Unsere Testgeräte habe ich bei www.reichelt.de bezogen.
Für die Heizungsregelung (LM12 & thermischer Stellantrieb) leider nicht geeignet,
da es keine Rückmeldung der Temperatur gibt.
MST