Dann befürchte ich, dass du irgendwie Recht hattest mit obigem Post vor längerer Zeit.
Wenn Symbox und IP-Interface in derselben (einzigen!) Linie hängen sind deine Beobachtungen kaum anders erklärbar. Zwar sagt der Mittelwert der Busauslastung wenig aus und eine kurzzeitige Telegrammflut könnte zu Verlusten führen, aber bei GA wie Fensterkontakten dürfte der Status ja zeitlich entzerrt gesendet werden. Oder ist das ein vielfach-Eingangsmodul was die alle synchron sendet?
Vielleicht verliert die Symbox mit kBerry-Interface wirklich Daten, wenn zu viel an Telegrammen in kurzer Zeit aufläuft.
Hast du irgendwie eine Möglichkeit das zu provozieren? Mir sind bisher 3 Kundenfälle bekannt, bei denen das Nachweisbar passiert - ich konnte es bisher hier im Büro aber nicht nachstellen, egal wie sehr ich das Interface „zumülle“ mit Telegrammen.
Also wir haben noch eine sublinie, für außen, mit linienkoppler, aber das funktioniert knx intern ja alles reibungslos. Ip interface und symbox hängen an der innenlinie.
Hab die logs mal mitlaufen lassen und tatsächlich baut sich ja teilweise ein backlog bis ich glaub maximal knapp unter 30 auf. Laut den logs baut er den aber ja auch wieder ab. Fehlermeldungen dass er was verwirft oder so habe ich noch nirgends gesehen
Die wiederholungen (siehe oben) tauchen im bus- und gruppenmonitor der ets nicht auf. Nur im log der symbox
Provoziert hab ich es noch nicht gekriegt. Selbst wenn ich alle 20 jalousien gleichzeitig schließe und dann ja jede menge werte für höhen auf den bus gesendet werden und ich gleichzeitig das wohnzimmer mit mehreren dimmbaren bereichen beleuchte.
Der telegrammverlust scheint gefühlt nicht dadurch beeinflusst zu sein
Zudem noch obiges “problem” dass sie discovery die mdt knx schnittstelle immer wieder findet auch wenn ich sie schon angelegt habe
Hmm ja, es gibt schon Fehlerquellen die zu Telegrammwiederholungen führen können wenn die Topologie nicht passt und GA durchgeleitet werden, die in dem Zweig nicht bestätigt werden.
Wenn die Innenlinie die 1.1.x hat, welchen GA hat dann die Außenlinie?
Mir ist bewusst, dass du bisher keine Wiederholungen in der ETS gesehen hast, aber dein Beispiel mit der Wetterstation spricht schon für einen Fehler in diesem Zusammenhang. Das Interface der Symbox erfindet die Wiederholungen nicht, da bin ich ziemlich sicher.
der Linienkoppler in der Außenlinie filtert gruppen und physikalische.
die telegrammwiederholungen sind mir auch bei GA aufgefallen, die rein auf der innenlinie laufen und gar nicht nach außen gehen. (siehe post 27. 4/1/0 ist eine Raumtemteratur, die geht sicher nicht auf die außenlinie)
siehe post 32. helligkeitswert der wetterstation wird in symcon wiederholt. der gruppenmonitor zeugt zum exakt gleichen zeitpunkt und auch um den zeitpunkt herum keinerlei wiederholungen
TRANSMIT ist halt die SENDE Richtung. Klar kommt das aus der Symbox. Allerdings natürlich durch ein Script oder eine Variablenänderung ausgelöst.
Zur MAC-Adresse: die gehört ja zur Netzwerkschnittstelle, die Symbox hat für KNX kein Netzwerk, also auch keine Netzwerkschnittstelle. Die Kommunikation erfolgt intern über TTL.
fragt sich warum die “antwort” also das “ incoming 4x kommt. gibts da also ggf. doch n problem mit der bus schnittstelle?
das komische ist halt ich bekomme nirgends auch nur ansatzweise einen fehler angezeigt. trotzdem gehen immer wieder mal telegramme verloren oder werden nicht verarbeitet.
Was ist das überhaupt? Hast du das KeepAlive und CheckDevice eingestellt?
Und da wird doch gar nichts auf den Bus geschickt, sonst würde da doch auch eine GA dabeistehen. Sieht für mich so aus, als sein das nur irgendwas SymBox internes?
Vielleicht hat das auch gar nichts mit deinem Telegramm Verlusten zu tun? Oder hast du das mal in einen zeitlichen Zusammenhang gebracht? Das weiß ich gerade nicht mehr.
Aber stell es doch einfach mal ab, oder auf 1h statt 1min.
ich hab das nicht eingestellt. wüsste auch nicht wo ich das ändern könnte.
dachte, dass ich mal nen zusammenhang gesehen hab, aber wenn das minütlich kommt, dann kann das natürlich schnell überschneiden mit zeitpunkten wo man telegrammverlust hat. sieht halt auf den ersten blick anders aus als alles andere.
bei laufendem BUS-Monitor werden 3 GA “not acknowledged” (Zeit, Datum und Zeit+Datum)
in dem Fall bekommt auch die Variable in symcon keine aktualisierung/veränderung mit
bei laufendem GRUPPENmonitor ist das nicht der fall. da wird in der ets alles fehlerfrei angezeigt und auch symcon bekommt eine veränderung/aktualisierung.
kann die problematik ggf. aus einer differenz von systemzeiten KNX und Symcon entstehen?
Wieso gibt es den o.g. unterschied bei den Monitoren in der ETS?
Mit diesen Fragen wärst du im KNX User Forum besser aufgehoben. Nach meiner Erinnerung bestätigt die ETS je nach Monitormodus selbst, wenn sie am Bus mitliest. Aber frag besser im KNXUF, da sind die Experten und diese Punkte sind unabhängig von IPS.
Bezüglich der 3 Zeit-GA scheint mit dein Zeitgeber etwas “überdefiniert” zu sein, der sollte nur die GA senden für die es am Bus auch “Abnehmer” gibt. Was von keinem der Geräte benötigt wird (und somit natürlich auch nie bestätigt wird) sollte gar nicht erst gesendet werden.
So ist das. Die ETS ist im Modus Gruppenmonitor ei Teilnehmer am Bus und sendet daher auch ein Acknowledge für jedes Telegramm. Im Busmonitor macht sie das nicht und es lohnt sich daher auch immer mal den Busmonitor laufen zu lassen um solche GA’s ausfindig zu machen, die keine Abnehmer haben und daher 3x wiederholt werden.
Welche Variablen werden in IPS dann nicht mehr aktualisiert? Die für Zeit, Datum und Zeit+Datum?
Dann kann ich mir nicht erklären, warum die im Busmonitor kein ACK bekommen? Könnte es evtl. noch an den Linienkopplern und den eingestellten Filtertabellen liegen? Wobei ich da jetzt auch nicht wüsste, was man da falsch machen kann, denn wenn die Telegramme korekt weitergeleiten werden, dass schickt glaube ich sogar der LK das ACK und nicht der Teilnehmer auf der Sub-Linie.
Dann ist das seltsam, irgendwas ist in deiner KNX Installation nicht korrekt. Ich hatte oben mal nach deiner Topologie gefragt, weil da gerne mal was falsch gemacht wird wenn man mit 1.1.x startet und dann noch eine zweite Linie erweitert. Das war aber unbeantwortet geblieben.
Nein, da gibt es keinen Zusammenhang der zu solchen Effekten führen könnte. Das sind nur “irgendwelche” Daten für Bus und IPS.
die innenlinie ist 1.0.x - die außenlinie ist 1.1.x - der Linienkoppler in der Außenlinie filtert gruppen und physikalische. (das hatte ich oben bereits geschrieben ;-))
sobald der BUS monitor läuft bekommen alle 3 variablen (datum, uhrzeit und datum+uhrzeit) keine aktualisierung mehr, sobald der BUS monitor aus ist bekommen die variablen wieder alles normal mit
