EibPC-Fusion?

[enertegus]

Wenn tatsächlich soooo viele Telegramme pro Sekunde ankommen

Deswegen bin ich ja so skeptisch (ob das sich tatsächlich so verhält) - ich kann es hier leider noch nicht testen, aber mein neues Apfelzeugs ist schon unterwegs...
Zumindest müsste der Anwender die Slider so konfigurieren können, dass eben nicht soviele Telegramme verarbeitet werden müssen. Das mit dem Wegschmeißen ist nicht so einfach: Um zu wissen, ob ein Telegramm unwichtig ist, müsste es ja angeschaut=verarbeitet werden. Naja, ich denke ich schick auch noch vor Ostern was an die Betatester raus, dann sehen wir ja was Sache ist - wenn der neue Apfel-I-dings nicht schon vorher bei mir ist.

[saft6luck]

Wenn ich mir vorstelle, dass der EibPC pro 1ms im besten Fall alles verarbeitet, würde der Slider ja erst nach 20000/s x 0.001s =20s alles verarbeitet haben. Ich kann mir auch nicht vorstellen, dass der HS 20000 Telegramme pro Sekunde verarbeitet, oder wo ist da der Hack?

Wenn tatsächlich soooo viele Telegramme pro Sekunde ankommen, sollte der eibPC mehr als ein Telegramm pro 1ms 'verwerfen' können. Abgesehen davon, dass man Reaktionszeiten <100ms praktisch nicht wahrnimmt, können das meine Dimmer auch nicht, weder in der Auflösung, noch der Geschwinndigkeit.
Daher geht es dann nur noch darum, die Latenzen durch den Signalweg (TCP -- eibPC - KNX - DALI) möglichst gering zu halten.

[saft6luck]

EDIT: Bei Analog-join's können beim sliden durchaus so 20000+ Telegramme/s ankommen, da der Slider von 0-65535 skaliert.

Und dann kann man ja auch noch in die andere Richtung sliden und wieder zurück und nochmal und gleich nochmal, puh.
Das werden dann fast schon Millionen Telegramme pro ... ach, pro Was eigentlich?

[enertegus]

Noch eine Frage:
Erwartet der CF auf jeden joint eine Bestätigung?
also CF sendet d1=1
der EibPC schickt als Acknowledge ein d1=1 zurück?

[enertegus]

EDIT: Bei Analog-join's können beim sliden durchaus so 20000+ Telegramme/s ankommen, da der Slider von 0-65535 skaliert.

Das wäre aber heftig, demnach müsste ja eine Netzwerklast auf mehrere MBit enstehen, bei a565=65323h03 => 10 Zeichen x 8 Bit + 32 Bit TCP Overhead x 20000= 2.2 MBit
Wenn ich mir vorstelle, dass der EibPC pro 1ms im besten Fall alles verarbeitet, würde der Slider ja erst nach 20000/s x 0.001s =20s alles verarbeitet haben. Ich kann mir auch nicht vorstellen, dass der HS 20000 Telegramme pro Sekunde verarbeitet, oder wo ist da der Hack?

[NilsS]

keine minimale Zeit.

d1=1\x03d2=0\x03 können direkt in einem String kommen.

maximal sind es 3 sekunden danach muss ein Heartbeat kommen.

EDIT: Bei Analog-join's können beim sliden durchaus so 20000+ Telegramme/s ankommen, da der Slider von 0-65535 skaliert.

[enertegus]

Ja, ist es

Eine letzte Frage (vorerst): Wieviel Zeit ist zwischen 2 Kommandos von CF minimal?

[NilsS]

Ja, ist es

[enertegus]

Es wird immer Hex:0x03 am Ende gesendet wie deine Plattform das bzgl. \ und \0 interpretiert weiß ich nicht in Python ist es \x03 also 1Byte und nicht 4 Zeichen

Zur Sicherheit: wie ist das bei den Verknüpfungspunkten:
wird also "d1=1" als reines ASCI gesendet?

Michael

[Uwe!]

und alls "Apps" laufen uneingeschränkt auf iPod und iPhone, solange keine Telefonverbindung und kein GPS benötigt wird.

[fireblade]

Ipod Touch

Kommuniziert mit dem Netz bzw. eibPC dann über WLAN. Beim Touch gibts Hardware-Unterschiede: der aktuelle 8-GB für 170€ hat einen langsameren Prozessor als die 32 oder 64 GB Variante, aber zum Testen und Einrichten sollte das keinen nennenswerten Unterschied machen.

[Bodo]

Hoi

Gleiche Auflösung, gleiches Verhalten, halt ohne Telefon.

[enertegus]

Ein Ipod touch tut es ja auch, das schont das Investitions-Budget

Klär mich mal auf: Ist das das Telefon ohne Telefon oder ist das auch Auflösung etc. reduziert?

[enertegus]

Wenn ihr noch einen Tester mit eibPC und Touch braucht, gerne! Wär das genial!
Thilo

Ich machs dann einfach so, dass da jeder das zeitnah testen kann.

[fireblade]

Tester

Wenn ihr noch einen Tester mit eibPC und Touch braucht, gerne! Wär das genial!

Thilo