Telegrammratenbegrenzung

[IBFS]

Kannst Du uns bitte möglichst bald das Programm und ESF schicken - reproduzierbare Fehler sind optimal.

wassennu - hat der EibPC nun einen FIFO (Größe??) oder nicht???

Frank

[enertegus]

@Michael: Wie habt Ihr das gelöst? Ich war davon ausgegangen, ihr habt einen FIFO, oder?

Ja, die Telegramme werden zwischengepuffert, das ist so.

Wir haben aber gemerkt, dass diese "Telegrammorgie" trotzdem die Schnittstelle überfordert, obwohl die Timeouts etc. eingehalten werden. Die FT1.2 hat sich Dir ja regelrecht aufgehängt.
Nunmehr ist eine Telegrammratenbegrzenung eingebaut und sie hängt sich nimmer auf (diese ist nun auch bei der IP wirksam, da der EiBPC - obwohl nach Standard richtig - offenbar die Schnittstellen überfordert).

Dass der Fehler von der GA abhängig ist und absolut reproduzierbar ist, macht mich stutzig, daher sind wir echt heiss auf dieses Programm (wenn deines auch immer sich falsch verhält, bitte sofort an uns!).

Und: bei einer Readanweisung in einer If-Schleife wird doch auch nicht auf das Ergebnis gewartet, oder?

Klaro.

Michael

[bmx]

Es ist noch zu früh zum denken oder lesen:
Nochmal um mitdenken und mitschreiben (für's Handbuch):

"Bei einer Readanweisung in einer If-Schleife wird nicht auf das Ergebnis gewartet. Das kommt später rein, wenn der Aktor, Sensor etc. geantwortet hat. Daher muß man seine Logiken und Ereignisketten auch mit Zustandsvariablen beschreiben die den derzeitigen Stand der Erkenntnis innerhalb einer Logik widerspiegeln".

Richtig so?

Gruß,
Bernd

[enertegus]

"Bei einer Readanweisung in einer If-Schleife wird nicht auf das Ergebnis gewartet. Das kommt später rein, wenn der Aktor, Sensor etc. geantwortet hat.

Genau.

Daher muß man seine Logiken und Ereignisketten auch mit Zustandsvariablen beschreiben die den derzeitigen Stand der Erkenntnis innerhalb einer Logik widerspiegeln".

Das versteh ich nicht bzw. ist das m.E. nicht eindeutig formuliert.
Alles, auch eine GA "hg-1/3/4" ist nichts anderes als ein Abbild des Zustands am Bus. Wenn z.b auf 1/3/4 ein Wert ungleich 0 gesendet bevor der EibPC gestartet wurde, ist der Zustand nicht richtig.
Außerdem ist es exakt gleichwertig

if "hg-1/3/4" then ..

und
a="hg-1/3/4"
if a then ...
zu schreiben.

[bmx]

Das versteh ich nicht bzw. ist das m.E. nicht eindeutig formuliert.

Sorry. Ich versuche es mal anders zu formulieren.

Der EibPC erstellt intern ein Prozessabbild. Das bedeutet, das der Wert jeder (nur bekannten?) GA gespeichert wird. Auf diese Weise weiß der EibPC z.B. immer welches Licht an oder aus ist.

Ausnahmen hiervon entstehen dann
a) wenn sich der Status eines Aktors ändert, ohne das es ein neues Telegramm einer GA ergibt oder
b) der EibPC zwischenzeitlich neu gestartet wird

Beispiel zu a):

Aktor Licht Wohnzimmer = 1/1/40
Status Licht Wohnzimmer = 1/2/40
Zentral aus = 1/1/0

Der Aktor hört auf "Zentral aus" und auf "Aktor Licht Wohnzimmer"

Wir am Schalter das Licht eingeschaltet, so weiß der EibPC, das das Licht an ist. Wird aber beim Verlassen des Hauses Zentral aus geschaltet, bekommt der EibPC das nicht mit, da sich die 1/1/40 nicht ändert.

Beispiel zu b)
Temperatursensor Bad schickt ein Telegramm, wenn sich die Temperatur um 0,5°C ändert. Die Temperatur im letzten Telegramm war 37°C
Jetzt spielt Papa die neue Software auf den EibPC auf. In der Zwischenzeit klettert die Temperatur auf 50°. Der EibPC kriegt es nicht mit. Clevererweise gibt es da den Befehl systemstart() der dann die aktuelle Temperatur mit read( GA Temperatursensor) abffagen kann.

Etwas schwieriger wird es bei Regelungen, weil da noch nicht immer der aktuelle Zustand bekannt ist der auch gewünscht ist. Beispiel hier ist der Doppelklick-Taster. Die Ausgabe darf erst dann erfolgen, wenn ein Einfach- oder Doppelklick zweifelsfrei erkannt worden ist. Darum gibt es hier eine Variable für den derzeitigen Zustand.

Ich hoffe, es ist nun verständlicher.

Gruß,
Bernd

[saft6luck]

Kannst Du uns bitte möglichst bald das Programm und ESF schicken - reproduzierbare Fehler sind optimal.

Zumindest ein Logging würde wohl noch Sinn machen. Die ESF bildet ja nicht seine Konfiguration ab. Wenn z.B. ein Aktor den Status auf den Bus sendet und dadurch mehr Last am Bus verursacht (und durch Verschieben der Reihenfolge eben später sendet), müsstet Ihr seine Installation nachbilden.

[enertegus]

Aktor Licht Wohnzimmer = 1/1/40
Status Licht Wohnzimmer = 1/2/40
Zentral aus = 1/1/0

dafür gibt dann bald comobject()

[saft6luck]

Unter der Voraussetzung, das so eine GALERIE von WRITEs innerhalb einer IF-Aweisung wirklich ohne FIFO STACK GLEICHZEITIG herausgesendet werden, ist das beschriebene Verhalten völlig normal.

Alle write() gleichzeitig bzw. kein FIFO macht ja keinen Sinn bei solch einem Gerät. Die Frage ist das Management, die Größe etc. des FIFO UND ob es Retries gibt. Und dann gibt es noch den Buffer in der jeweiligen Schnittstelle, der auch ohne Rückmeldung überlaufen kann/wird.

In einer Installation ohne EibPC würde exakt das gleiche passieren.

Eben, in einer Installation passiert das auch. Wenn ein Gerät einen zu kleinen FIFO besitzt bzw. zu viele Telegramme senden möchte bzw. der Bus immer ausgelastet ist bzw. alle Retries nichts genutzt haben, gehen Telegramme verloren.

So sehr ich den Wunsch verstehe OHNE echte Zentralbefehle auskommen
zu wollen - das Thema hatten wir schon - aber man sollte seine KNX-Installation
eben doch MIT Zentralbefehlen programmieren und nicht alle Zentral-Logik
in den EibPC packen.

Genau, Zentralbefehle erledigen das mit einer GA! Daran sollte man nicht sparen! Dann kann man mit dem eibPC genau steuern, WANN diese Zentral-GAs geschickt werden, und ist nicht auf bestimmte Taster festgelegt.

N.B. das ganze Problem wird noch schlimmer wenn bei dieser Programmierung jemand die Taster für ein und aus schnell, mehrfach betätigt. Da "freut" sich der eibPC für längere Zeit ...

[bmx]

comobject()

Hi Michael,

dafür gibt dann bald comobject()

Prima, dann können wir also nur hörende GA berücksichtigen.

StatusAktor=comobject("GA_a-1/2/3","GA_b-1/2/4","GA_c-1/2/5")

Dabei ist "StatusAktor" dann also der Wert der Variablen, der sich als letzter verändert hat.

Gruß,
Bernd

[saft6luck]

dafür gibt dann bald comobject()

Bei der Kürze der Antwort ist mir der Zusammenhang nicht ganz klar.

Bei

a = comobject( blah, blub, blubber)

spare ich mir also

if event(blah) then a = blah
if event(blub) then a = blub
if event(blubber) then a = blubber

Nun hat ja a den aktuellen Wert der Variablen, gell? Da hat man vorhar drauf achten müssen, welche GAs den Zustand bestimmen und nacher auch. comobject() ist evtl. verständlicher und deutlich kürzer und kann evtl. mit Variablen umgehen(?).

Oder meinst du: in if then Statements verwendet könnte man sich evtl. Variablen sparen? Und daher ist keine Zustandsabbildung über Variablen mehr nötig?