ich habe inzwischen bei meheren Häusern etwas umfangreichere EIB Anlagen vorgefunden und mich haben die Latenzen (drücken --> Reaktion, z.B. Licht) erschreckt.
Von einigen Hausbesitzern wurde mir auch bestätigt, dass sie schon öften mal einen Schalter dreimal betätigen, bevor „Licht an“ ist und dass dieses gerade bei den Frauen doch zeitweise zu Unmut geführt hat.
Meine Frage: Gibt es hier im Forum Leute, die auch schlechte (oder gute) Erfahrungen gemacht haben?
Speziell die zusätzliche Einschaltung der IPS und deren Wirkung auf die Latenz (einigermassen saubere Programmierung vorausgesetzt) würde mich interessieren.
Die Latenzen von Webfront und FS20 System sind teilweise schon deutlich spürbar, das kann aber natürlich auch an der HTTP abfrage und Umsetzung liegen.
Nun interessiert mich, wie das kabelgebunden aussieht.
Die Latenzen von Webfront und FS20 System sind teilweise schon deutlich spürbar, das kann aber natürlich auch an der HTTP abfrage und Umsetzung liegen.
…wenn ich im Webfront Ein oder Aus schalte wird der Befehl sofort umgesetzt(±250ms)
Ich hatte mal mit einem Besitzer größerer Wohnanlagen gesprochen. Der war von KNX ab entsprechender Größe auch genervt. Bei ihm waren zur Problemlösung dann immer separate Bereiche zusammengefasst und über LAN verbunden. Die Busbandbreite ist halt irgendwann erschöpft. Sind schließlich nur 9600 Bit/s.
Das WebFront aktualisiert spätestens 200ms nach Änderung einer Variable in IPS deren Status, die Netzwerklatenz dabei sollte im LAN zu vernachlässigen sein. Wann IPS die Daten erhält kommt in erster Linie auf Gateway und Bus an.
Die meisten Problemen mit Latenzen kommen beim KNX von einer schlechten Planung bzw. Programmierung.
Richtig ist: KNX hat nur 9600 baud - aber - das bekommt man in den Griff. Erstens: Linien per IP Koppler (z.B. Siemens N146) verbinden. Das ist dann der Linienkoppler aber nicht per TP sondern per IP.
Weiterhin muss man sich Gedanken machen was man alles auf dem Bus sendet. Manche bauen sich zyklische Sender ein und lassen sich die Temperatur alle 5 Sekunden senden. Sowas müllt den Bus zu. Weiterhin gibt es die Möglichkeit über Filtertabellen Telegramme in den einzelnen Linien zu begrenzen. Sowas muss man in größeren Anlagen nutzen - sonst gibt’s wirklich Probleme.
Aber wie schon gesagt: Das meiste sind Planungs bzw. Programmierfehler. KNX läuft sonst sehr stabil und auch schnell.
Moin Moin,
diese Latenzen sind mir auch aus LCN-Anlagen bekannt (je größer die Anlage, desto größer die Chance).
KNX hat nur 9600 baud
LCN arbeitet hier intern mit 19200 - IMO hat das damit nichts zu tun.
Hier muss man anscheinend bei allen Anlagen die interne Parametrierung optimieren.
Ein Problem scheinen bei uns (im LCN) auch die an heutigen Laptops notwendigen USB-Adapter zu sein. USB überträgt ‚Pakete‘, das hat mit ‚baud‘ nichts zu tun. Es scheint das hier was ‚verschluckt‘ wird - mehrfach drücken wäre das Ergebnis dazu.
Wäre für mich jetzt interessant zu wissen ob auch bei den KNX-Latenzen irgendwas an USB-Teilen im Spiel ist.
Bei KNX werden die meisten User hier wohl über LAN oder RS232 rangehen.
Ich kann aber von meinem Z-Wave-Stresstest mit 7000 Anfragen pro Sekunde nach der Z-Wave-Version meines USB-Sticks über mehrere Stunden sagen, dass da nichts verloren gegangen ist. Ich sehe bei USB eher das Problem, dass sich die Geräte mal aufhängen. Meine alte FHZ hat das mal geschafft. Bei paresy hängt auch irgendwas am Server, dass er ca. 1-2x im Jahr neu reinstecken muss.
Moin Horst,
bei direktem RS232 solltest du auch kein Problem haben, da laufen die ‚bauds‘ ggf. ja sogar mit einem Hardwarehandskake. Den Netzwerkanschluß hat LCN ja derzeit nur über die FritzBox (und da ist auch wieder ein USB/RS232-Adapter im Einsatz) oder über LCN-PCHK (wir schauen mal wie lange ein PC mit direkter RS232 da durchhält).
Vielleicht kann jwka ja noch mal sagen was dort im Einsatz ist …
Latenzen gibt es bei einem digitalen Bussystem immer - es stellt sich nur die Frage wie groß diese sind und ob man sie als Benutzer als störend empfindet. Eine Verzögerung beim einschalten von Licht von beispielsweise 200 Milisekunden empfinde ich meist als störend.
Nun zu EIB/KNX - wie bereits oben beschrieben arbeitet dieses Bussystem mit 9600 Baud und das Sendeverfahren entspricht dem Ethernet CSMACD. Somit können mehrere Sensoren gleichzeitig auf den Bus senden und es kann zu Kollisionen kommen. In diesem Fall senden die Sensoren ihre Telegramme mehrmals - was die Buslast, und damit die Kollisionen, nicht unbedingt verringert.
Trotzdem funktioniert auch ein größeres EIB-System normalerweise ohne spürbare Latenzen sofern es richtig konfiguriert wurde. In unserer Firma (Büros, Produktion, Lager und Labor) wird via EIB das Licht, Heizung, Jalousien und die Dachluken gesteuert - insgesamt sind ca. 1500 EIB Gruppen definiert (Schalter, Bewegungsmelder, Wetterstation, Tempertaurfühler für die Raumheizungen, Fensterkontakte). Beim schalten von z.B. Licht spürt man keine Verzögerung.
Eine Möglichkeit die Buslast des EIB aufzuteilen existiert z.B. in Form von verschiedenen Linien - bei uns sind jedoch alle Linienkoppler auf ‚durchzug‘ bzgl. ihrer Daten konfiguriert damit der IPS-Server alle Telegramme ‚abhören‘ kann. Die Linien dienen bei uns eher der Ausfallsicherheit (wird eine Linie beschädigt gehen die anderen Bereiche noch).
Falls man Probleme mit den Reaktionszeiten im EIB hat sollte man sich mal die Buslast genauer ansehen - wer sendet wann, wie oft und warum auf den EIB. Die ETS hat einen entsprechenden Busmonitor integriert.
Hier ein paar Beispiele welche die Buslast unnötig erhöhen:
Temperatursensoren die im Sekundentakt ihre Temperaturen auf den Bus schicken -> für die Haussteuerung reicht es wenn Temperaturen alle 5 Minuten gesendet werden
Bewegungsmelder die im Milisekundentakt ihren aktuellen Status auf den Bus senden (ja, sowas hat es gegeben!) -> es reicht wenn die Bewegungsmelder nur bei einer Statusänderung auf den Bus senden
Sender die auf eine Bestätigung eines gesendeten Telegramms warten welches jedoch nicht bestätigt wird - die Sender werden nach einem Timeout ihr Telegramm wiederholen…
ein wildgewordenes Serverskript welches unnötige Mengen an Telegrammen in kurzer Zeit raushaut
Also… wenn’s Probleme mit dem Reaktionsverhalten des EIB gibt, erstmal in aller Ruhe die Buslast studieren und überlegen ob alles wirklich so abläuft wie man es sich vorstellt.