Ja, muss ich nachinstallieren. Aber was muss ich als Host angeben? Ich denke die KNX-Befehle gehen nicht raus, also EDOMI Server 127.0.0.1 oder die Adresse im Netz 192.168.5.22 ? Wenn ich die Rückantworten kontrollieren möchte das KNX Gateway?
Danke für die Mühe.
-
Per ssh einloggen und dann
Wobei Du 0.8.1.5 durch die IP von Deinem Absender ersetzen musst. Dann solltest Du die Multicasts sehen koennen.Code:tcpdump host 0.8.1.5
Abbrechen/Beenden mit CTRL-C...
EDIT: falls tcpdump nicht installiert sein sollte, einfach mit
nachinstallieren.Code:yum install tcpdump
Einen Kommentar schreiben:
-
Wenn du mir sagst was ich dazu machen muss, gerne....Zitat von wintermute Beitrag anzeigen
Im übrigen geht's jetzt aktuell wieder normal schnell....Einen Kommentar schreiben:
-
Mach doch mal in der Console nen tcpdump, dann siehste schonmal wann das Paket tatsaechlich in der VM ankommt. So zum Fehler eingrenzen...Einen Kommentar schreiben:
-
Hab' gerade EDOMI (ohne Server) neu gestartet und wieder die ca. 1 Minute Verzögerung, mal sehen, wann sich das wieder einpendelt.Zitat von Winni Beitrag anzeigen
Aber warum nur?Einen Kommentar schreiben:
-
Oder eine Progression:
Rot = EDOMI inaktiv
Orange = Kein Projekt aktiv
Gelb = Projekt in der Aktivierungsphase
Grün = Alles in OrdnungEinen Kommentar schreiben:
-
Ist in Arbeit...
Gelb-grün ist halt irgendwie schwer zu unterscheiden, ich überlege noch (orange?!)....
Einen Kommentar schreiben:
-
Sieht doch chic aus!Zitat von gaert Beitrag anzeigenPreview "Designänderung" - das gibt Mecker
Was ich noch schön fände wäre eine bessere Unterscheidbarkeit zwischen Initialisierungs- und Betriebsbereit-Status. Da finde ich die Unterscheidung zwischen grüner Ring (OK, bald grünes Rechteck) mit gelbem Schatten und grünem Ring mit grünem Schatten nicht sehr gut unterscheidbar. OK, vielleicht gehts auch nur mir so und ich hab eine gelb-grün-Schwäche?
Einen Kommentar schreiben:
-
Ich hab jetzt einen Snapshot von 1.43 aktiviert -> alles in Butter,
danach das Backup von 1.45 von heute nachmittag eingespiel -> wieder die Verzögerung aller KNX Kommandos
das kann doch nicht an der VM liegen, bin verzweifelt, brauch jetzt aber noch zumindes 4 Stunden Schlaf, evtl. hilft das ja....Einen Kommentar schreiben:
-
Koennte am (virtuellen) Treiber fuers (virtuelle) NIC liegen. Unter ESXi zB wars mal ne Zeitlang so, dass mit einer bestimmten "Emulation" Multicast generell nicht ging. Waere also moeglich, dass der Hypervisor da schon "dicht" macht.
Das liesse sich aber mittels tcpdump in der Console rausfinden...Einen Kommentar schreiben:
-
Hilfe, ich weiß, dass VMs hier immer wieder als Grund für einige unerklärliche Sachen herangezogen werden. Nachdem ich nun aber wirklich etwas habe, was ich überhaupt nicht verstehe und ich auch das System nicht neu aufsetzen möchte, frag ich dochmal nach:
Ich habe heute einen Snopshot meiner VM gezogen um danach einiges wegen meiner UDP-Multicast-Probleme auszuprobieren. Nachdem dies erfolglos war, wollte ich wieder auf den alten Snapshot zurück. Soweit so gut.
Hat auch auf den ersten Blick alles gut ausgehen, aber meine Aktionen in der Visu werden um fast 1 Minute zeitversetzt an den KNX-Bus ergeben, egal ob Visu oder Monitor. Hab die VM schon mehrfach aus EDOMI durchgebootet und einfach keine Idee mehr. Kurz vor dem Snapshot habe ich noch die 1.46 eingesppielt. Halte es aber für unwahrscheinlich, dass es daran liegt.
Hat jemand eine Idee was ich da probieren könnte? Systemlast ist nicht das Problem.Einen Kommentar schreiben:
-
Schon wahr, allerdings ist das Runde auch ziemlich verschwenderisch in Sachen Platz Und ich habe mich inzwischen satt gesehen... Eigentlich ist es ja auch schwachsinnig runde Fenster in eckige Bildschirme zu bringen
Darum habe ich beschlossen auf eckig umzusteigen, denn dadurch steigt der Bedienkomfort doch spürbar an (Widgets usw.). Nach dem Motto: Form follows function
Einen Kommentar schreiben:
Einen Kommentar schreiben: