KNX/EIB [EIBD] Telegramme gehen bei Zentralfunktionen verloren

[jonofe]

Guten morgen,

ich hätt da gern mal'n Problem ... und zwar folgendes ...

Ich hab' verschiedene Status und Zentralfunktionen und frage mich, wie man das Zusammenspiel von zentralfunktion und Zentralstatus am besten realisiert. Und zwar handelt es sich um ca. 50 Schaltkanäle (Beleuchtung), die jeweils eine aktive Rückmeldung Ihres Status (bei Änderung) auf den Bus senden. Zum einen möchte ich Zentral die Beleuchtung ein- und ausschalten können und natürlich auch den Zentral-Status anzeigen, d.h. wenn noch mind. eine Lampe an ist, dann soll die LED am Zentralschalter an sein und wenn alle Lampen aus sind, soll die Status LED aus sein.

Ich hatte zunächst eine zentrale GA (7/0/0), welche ich als hörende Adresse auf alle Kanäle gelegt hab und natürlich auf den Taster. Den Status (7/0/1) berechne ich mit einer ODER-Verknüpfung alle Rückmeldeobjekte und sende ihn bei Änderung auf den Bus. Wenn ich aber nun die Zentralfunktion (7/0/0) schalte, dann kommen im "schlimmsten" Fall 50 Rückmeldungen zugleich. Dabei gehen dann scheinbar Rückmeldungen verloren, so dass der Gesamt-Status (7/0/1) nicht korrekt angezeigt wird.

Inzwischen habe ich es nun so geändert, dass ich keine zentral GA als hörende Adresse mehr verwende, sondern diese zentrale GA nur noch vom Zentraltaster gesendet und dann nur in meiner Logik verarbeitet wird. Aus der Logik heraus wird dann an alle Kanäle je ein einzelnes Telegramm (AN bzw. AUS) gesendet. Dies löst natürlich dieselbe Anzahl an Rückmeldungen aus, allerdings nicht genau zum gleichen Zeitpunkt. Dies lieferte immernoch keine zufriedenstellendes Ergebnis. Dann hab ich noch eine Zeitverzögerung von 0,1 Sekunden zwischen 2 Telegramme eingebaut, was die Situation deutlich verbessert, da jetzt nur maximal 20 Telegramme pro Sekunde auf den Bus kommen (10 Schalttelegramme + 10 Rückmeldungen). Es dauert aber bei ca. 50 Leuchten dann auch eine ganze Zeit bis alle Aktionen ausgeführt sind.

Meine Frage: Wie realisiert man/ihr solche Zentralfunktionen? (z.B. im HS)

Ist es normal, dass wie oben beschrieben, Telegramme verloren gehen können, oder könnte dies auch ein Problem der Schnittstelle oder des eibd sein?

[mkoegler]

Ist es normal, dass wie oben beschrieben, Telegramme verloren gehen können, oder könnte dies auch ein Problem der Schnittstelle oder des eibd sein?

Im EIBD geht nichts verloren . Der bcu1driver bei PEI16 wäre eventuell eine Fehlerquelle - bei USB hat dein PC sicher genug Rechenleistung, um die 9600 Baud Daten von der Schnittstelle zu verarbeiten.

Ob die Schnittstelle Telegramme verliert, kann ich bei besten Willen nicht beantworten. Am ehsten würde ich es bei einer TPUART Schnittstelle ausschliessen, da sie nur wenig selbst macht.

Aufgrund der Vorgeschichte wäre meine erste Vermutung, das deine LKs schuld sind.

[Aendu007]

Hallo André
Eigentlich sollten ja keine Telegramme verloren gehen......

Schaue doch mal mit dem Busmonitor der ETS wie hoch die Buslast wirklich ist.

Mit dem HS würde ich das folgendermassen lösen.

Zentraladresse löst verschiedene Unterzentraladressen aus.
dies Unteradressen würde ich über Sequenzen auslösen. Mit der Zeitlichern Verzögerung sollte es dann zu keinem Engpass mehr kommen.

Oder man arbeitet nicht mit effektiver Rückmeldung.

Gruss Aendu

[jonofe]

Im EIBD geht nichts verloren .

Das dachte ich mir.

Aufgrund der Vorgeschichte wäre meine erste Vermutung, das deine LKs schuld sind.

Die LKs hatte ich nach den Erlebnissen mit der Programmierung schon abgehängt, allerdings ohne Verbesserung.

Kann es denn sein, dass die Aktoren ihre Rückmeldung nicht loswerden? Evtl. weil der BUS überlastet ist, oder weil ein x-fach Aktor ja gleichzeitig x Statustelegramme senden müsste? Dann würde das Telegramm schon im Absender verloren gehen. Ist das denkbar?

@Aendu007: Hab ich mir schon mit der ETS angeschaut. Ging bis 106% Buslast. Meist aber nur bis. 60%-70%. Aber nach den 106% ist mein Vertrauen in die Buslast-Berechnung der ETS nur noch recht eingeschränkt.

Wenn ich Sequenzen sende mit max 10 Telegrammen pro Sekunde, dann funktionierts zuverlässig.

[jonofe]

Zentraladresse löst verschiedene Unterzentraladressen aus.
dies Unteradressen würde ich über Sequenzen auslösen. Mit der Zeitlichern Verzögerung sollte es dann zu keinem Engpass mehr kommen.

so mache ich es ja jetzt prinzipiell auch. Zentraladresse löst Einzeltelegramme aus, welche jeweils mit 100ms verzögert gesendet werden.

Oder man arbeitet nicht mit effektiver Rückmeldung.

Wie würde man denn dann eine zeitnahe Rückmeldung bekommen?

Ich habe nämlich eine AJAX basierte Visu, welche 10x pro Sekunde die Stati der angezeigten Objekte aktualisiert. Das könnt ich dann wohl knicken. Derzeit wird nämlich ein Schaltvorgang auf einem Taster quasi zeitgleich in der Visu angezeigt und zwar bei mehr als 20 Objekten, die auf einer Seite angezeigt werden.

Ich müsste ja dann mit Read_Requests arbeiten, um den aktuellen Status zu bekommen, oder?

[jonofe]

Im EIBD geht nichts verloren . Der bcu1driver bei PEI16 wäre eventuell eine Fehlerquelle - bei USB hat dein PC sicher genug Rechenleistung, um die 9600 Baud Daten von der Schnittstelle zu verarbeiten.

Ob die Schnittstelle Telegramme verliert, kann ich bei besten Willen nicht beantworten. Am ehsten würde ich es bei einer TPUART Schnittstelle ausschliessen, da sie nur wenig selbst macht.

Ich könnte ja eigentlich ähnlich zum Routing-Programmier-Test ein Monitoring des Busses mit der zweiten Schnittstelle machen und dann würde ich zumindest sehen, ob die Statustelegramme, die mir fehlen überhaupt gesendet werden. Sollte ich dann besser mit der PEI16 oder der USB Schnittstelle monitoren?

[mkoegler]

Kann es denn sein, dass die Aktoren ihre Rückmeldung nicht loswerden? Evtl. weil der BUS überlastet ist, oder weil ein x-fach Aktor ja gleichzeitig x Statustelegramme senden müsste? Dann würde das Telegramm schon im Absender verloren gehen. Ist das denkbar?

Bei einer BCU1 kann ich mir das durchaus vorstellen. Diese Dinger habe ja nicht viel Speicher (viel, viel weniger als 1k). Meiner Schätzung nach passen da max. 4 Nachrichten gleichzeitig im Speicher.

[mkoegler]

Ich könnte ja eigentlich ähnlich zum Routing-Programmier-Test ein Monitoring des Busses mit der zweiten Schnittstelle machen und dann würde ich zumindest sehen, ob die Statustelegramme, die mir fehlen überhaupt gesendet werden. Sollte ich dann besser mit der PEI16 oder der USB Schnittstelle monitoren?

Du kannst mit den Busmonitor schauen, ob BUSY Telegramme am Bus auftreten. Dann hast du (neben deinen LKs) noch ein Gerät, das nicht mitkommt.

Etwas könntest du noch Prüfen:
Ist jede der Rückmeldungsaddressen auf irgendeinen EIB Gerät als Empfangsadresse eingetragen? Wenn nein, bekommt der Sender kein e ACKs und wiederholt es, was zu einer höheren Buslast führt (sollte auch im Busmonitor zu sehen sein).

Bei den PEI16 Busmonitor hatte ich das Gefühl, das etwas fehlt., wie ich beide Logs verglichen habe. Da das fürs Problem egal war, habe ich die aufwändige Prüfung nicht gemacht.

Persönlich glaube ich nicht, das du abgesehen von Test auf BUSY und Wiederholungen neue Infos damit gewinnst.

[makki]

Noch meine Erfahrungen, teils von mkoegler abgeleitet
Meine Meinung: einfach Finger weg von BCU1 ! Mehr als "Schönwetter-Betrieb" ist damit nicht drin..
Wenn dann die USB, die gingen bei meinen Tests (ausgiebig, mit Prüfung auf vollständigkeit,Verluste etc.) eigentlich auch sauber.

Ansonsten:
Telegrammwiederholungen ? (sollte nicht, das schauckelt sich bei sowas dann schnell hoch)
Busy ? (darf eigentlich nicht, mein Bus läuft wenn die RGB-Sequenzer an sind auch mit 5-10 tps und 0,0000 Verlusten)

Makki