Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
- die Netzwerkverbindung zum Router wurde kurzzeitig unterbrochen
Nicht erreichbare Kameras etc. sollten nicht dafür sorgen, dass der Router nach 30 Minuten zu macht
Einfach mal das KNX-Log anwerfen und stöbern...
Oder der Server macht von der VM gerade ein Backup, dabei wird natürlich erst mal ein Snapshot erstellt
das erklärt warscheinlich auch, das es nur auf dem Testsystem passiert. Das sich EDOMI immer wieder bei den INiT Scans verzählt (ERROR 0 Abfragen fehlgeschlagen) laste ich eher dem doch schon arg gebeutelten Testsystem an. Auf der Produktiven Maschine passiert das nicht.
Oder der Server macht von der VM gerade ein Backup, dabei wird natürlich erst mal ein Snapshot erstellt
Wie machst Du das genau?
Meiner einer betreibt seit über einem Jahr einen ESXi mit EDOMI als VM (produktiv) und nutze seit ca. 2 Monaten Veeam Endpoint. Bare-Metal Recovery funktioniert damit auch wunderbar.
Dabei sind bisher auch noch keine Fehler-Meldungen bzgl. KNX aufgelaufen...
Meinst Du damit, dass Dein Testsystem, wie es so schön heißt, auf Unterkante Oberlippe arbeitet?
Mit VMs stehe ich (im EDOMI-Kontext) auf Kriegsfuss... Daher empfehle ich ja auch ausdrücklich keine VM für das Produktivsystem zu verwenden. Ich möchte jetzt keine Diskussion darüber lostreten und bin mir durchaus bewusst darüber, dass viele das ganz anders einschätzen werden. Jedoch zeigt mir meine Erfahrung (auf meinem System mit VMware-Fusion) immer wieder, dass zeitkritische Operationen auf Netzwerkebene in der VM nicht immer zuverlässig und reproduzierbar funktionieren. Das liegt in meinem Fall evtl. auch am Host (recht betagter iMac von 2007), der vermutlich einfach in die Knie gezwungen wird sobald er noch eine VM bewirten muss.
Letztlich ist eine VM "nur" Software und eben keine echte Hardware. Der Host wird stets priorisiert - dies wird wohl jedes OS so handhaben. Und wenn der Host gerade ausgelastet ist (wenn auch nur für wenige Millisekunden) wird das virtuelle LAN vermutlich mal kurz durchatmen müssen. Und schon kommt irgendein Tunneling-Ack zu spät oder was auch immer.
Das KNX-IP-Protokoll ist nunmal ziemlich 80er irgendwie (jedes Bit zählt...). Bei einem Webserver in einer VM werden solche Dinge nicht auffallen - die Anfrage wird halt 10 ms später beantwortet. Aber bei KNX-IP kommt's dann halt schnell mal zu Timeouts, Wiederholungen oder Verbindungsabbrüchen. So zumindest meine Erfahrung, wie gesagt auf meinem (bewusst) veraltetem Testsystem.
Fazit: Leute... Bitte investiert ein paar Kröten in dedizierte Hardware - EDOMI sollte es Euch wert sein. Der Vollprofi wird's schon alles richtig machen (VM, Docker, etc.), aber dem geneigten Amateur oder Laie suggeriert eine "Mediamarkt-VM-Software" einen tollen PC für wenig Geld - und da lauert eben die Gefahr in diesem Kontext. Für Word und Co. reicht das allemal, aber für eine 24/7 Hüttensteuerung vielleicht nicht unbedingt...
EDOMI - Intelligente Steuerung und Visualisierung KNX-basierter Elektro-Installationen (http://www.edomi.de)
Bei mir treten immer mal wieder Verbindungsabbrüche auf in der 1.6.1. Die summieren sich recht schnell auf in der Übersichtsseite, weil der Router danach offensichtlich erstmal "pennt" und die erneuten Verbindungen in ein Timeout laufen.
Hat jemand eine Idee, wie ich das noch weiter tracken könnte? Hab zwar eine SD-Karte im Gira Router zum Loggen, aber da steht ungefähr nichts drin.
Mit VMs stehe ich (im EDOMI-Kontext) auf Kriegsfuss... Daher empfehle ich ja auch ausdrücklich keine VM für das Produktivsystem zu verwenden. Ich möchte jetzt keine Diskussion darüber lostreten und bin mir durchaus bewusst darüber, dass viele das ganz anders einschätzen werden. Jedoch zeigt mir meine Erfahrung (auf meinem System mit VMware-Fusion) immer wieder, dass zeitkritische Operationen auf Netzwerkebene in der VM nicht immer zuverlässig und reproduzierbar funktionieren. Das liegt in meinem Fall evtl. auch am Host (recht betagter iMac von 2007), der vermutlich einfach in die Knie gezwungen wird sobald er noch eine VM bewirten muss.
Letztlich ist eine VM "nur" Software und eben keine echte Hardware. Der Host wird stets priorisiert - dies wird wohl jedes OS so handhaben. Und wenn der Host gerade ausgelastet ist (wenn auch nur für wenige Millisekunden) wird das virtuelle LAN vermutlich mal kurz durchatmen müssen. Und schon kommt irgendein Tunneling-Ack zu spät oder was auch immer.
Das KNX-IP-Protokoll ist nunmal ziemlich 80er irgendwie (jedes Bit zählt...). Bei einem Webserver in einer VM werden solche Dinge nicht auffallen - die Anfrage wird halt 10 ms später beantwortet. Aber bei KNX-IP kommt's dann halt schnell mal zu Timeouts, Wiederholungen oder Verbindungsabbrüchen. So zumindest meine Erfahrung, wie gesagt auf meinem (bewusst) veraltetem Testsystem.
Fazit: Leute... Bitte investiert ein paar Kröten in dedizierte Hardware - EDOMI sollte es Euch wert sein. Der Vollprofi wird's schon alles richtig machen (VM, Docker, etc.), aber dem geneigten Amateur oder Laie suggeriert eine "Mediamarkt-VM-Software" einen tollen PC für wenig Geld - und da lauert eben die Gefahr in diesem Kontext. Für Word und Co. reicht das allemal, aber für eine 24/7 Hüttensteuerung vielleicht nicht unbedingt...
Diese ganzen Punkte sind für mich alle nachvollziebar...
Jedoch ergaben meine Recherchen das es mit dem eingesetzten Beriebssystem(CentOS 6.5) schwierig ist eine aktuelle Hardware zu kaufen auf der Edomi läuft.
Oder hat hier jemand noch Tipps für eine gute aktuelle Hardware?
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar