EDOMI-Releases/Updates | Aktuell: Version 2.03

[vento66]

Das kommt sicher auf die Power vom Host an, mein Apu kommt auch immer um Mitternacht ins straucheln, und macht 2-3 seq Errors. Das Abschalten des Automatischen Backups brachte bis jetzt keine Fehler mehr.

[crewo]

Wird nicht auch die Datenbank gelockt während eines Backups (Dump)? Evtl. entsteht so das Problem? Wenn das wirklich das Problem ist (Last) dann wäre ich auch stark dafür nur die SeqErrors per Einstellung optional zu ignorieren.

[gaert]

In der Tat wird die Datenbank kurzzeitig geblocked (geht nicht anders) und dann die Dateien schnellstens kopiert. Das Abschalten der Backup-Funktion könnte also helfen, v.a. wenn die DB sehr groß ist (Datenarchive).

[crewo]

Aber verursacht das dann auch die Fehler? Sonst könnte man ja an Timeouts drehen... oder während des Backups die Errors in einem eigenen Log erfassen, welcher keine Fehler in der Visu wirft.

Oder mit Single Transaction? http://dba.stackexchange.com/questio...ads-and-writes

[gaert]

Das Problem ist, dass die DB auf Dateiebene kopiert wird (geht u.a. schneller). Daher müssen die Tables mit einem READ-LOCK versehen werden und geflushed werden (so empfiehlt es mySQL). Macht auch Sinn, denn sonst hat man schnell ein Problem: Wenn während des Backups die DB verändert wird ist die Datei "korrupt".

Ich werde dies in der nächsten Version geringfügig optimieren, indem einige Tables nicht geblocked werden (diese werden nämlich ohnehin nicht kopiert). Vielleicht hilft's. Transactions sind keine Lösung und ohnehin nicht sinnvoll in EDOMI, da viel zu langsam

[tger977]

Also bei mir ist echte Hardware im Einsatz....

die DB ist aber noch recht klein.

[SeatSLF]

gaert hast du eventuell und falls gar nichts mehr geht die 1.44 Version zur Inst. noch irgendwo liegen?

Ich habe jetzt das ganze neu aufgesetzt und nur das Projekt neu eingespielt, und werde mal schauen wie es nach ein paar Stunden reagiert.

[gaert]

Sicher, aber wie schon gesagt: 1.43, 1.44 und 1.45 sind absolut gleich in Sachen KNX... (bis hinab zu 1.3x)

[saegefisch]

Meine Erfahrung dazu: Bis vor 2 Wochen habe ich seit Version 1.06 alle Versionen bis 1.32 mit gemacht und dies in einer VM. Es lief alles problemlos , aber ich hatte regelmäßig Seq-Fehler. Dann hatte ich eine Zwangspause und mehr als 5 Monate nicht mehr in Edomi geschaut: Der erste Blick danach - mehr als 9.000 Fehler! Der Host war offensichtlich nicht stark genug (NAS mit core i3). Gateway: Enertex IP-Router.

Vor 2 Wochen Umzug auf dedizierte HW (NUC i3) mit V1.44 und 1.45. Seit 2 Wochen nicht ein einziger Fehler. Und das, obwohl nach dem Projekttransfer spürbar mehr Logik dazu kam und auch mehr genutzt wird - denn den gira HS habe ich nun vor 4 Tagen abgeschaltet. Weiterhin kein einziger Fehler - auch nicht um 0:00.

Wenn ich mir die Historie dieses Themas anschaue, so ist mein persönliches Resümee: edomi ist sparsam und sehr schlank - da braucht es nicht viel HW. Je nach Nutzungsgrad (Kamera, Datenarchive,...) scheint die Infrastruktur um edomi herum (DB, TCP/IP-Stack, Netzwerk,...) in bestimmten Situationen eben für - wenn auch sehr kurze - Augenblicke in Summe doch ein Quäntchen mehr zu brauchen. In nicht optimaler Umgebung - und das kann eine VM auf einer nicht hinreichend starken Host-Umgebung sein - gibt es in der Auswirkung wohl problemlose, aber faktisch vorhandene Seq-Fehler. Die KNX-Strecke über die TCP/IP-Strecke zum Gateway scheint ohne diese Fehler zu funktionieren, wenn man dedizierte HW einsetzt (Rat des Entwicklers) oder mit sehr potentem Host mit VM. Oder man lebt mit den Fehlern. Jeder muss selbst bewerten, was ihm die Zeit mit den Fehlern wert ist oder nicht oder es akzeptiert. Und ich vermute (ohne Prüfung): ein schlankes Docker neigt zu weniger Seq-Fehlern als eine volle VM. Daher mag das Angebot hier im Forum auch entlasten.

In der Konsequenz halte ich es aber auch für nicht optimal, die Fehler auszublenden. Nun, wer es will, soll es halt machen. Eine Option in der ini würde das Thema entlasten - das muss dann jeder selber für sich wissen. Ich würde es nicht wollen, denn mein Haus(!) hängt da dran. Oder edomi nicht verwenden. Auf jeden Fall sollte man die Fehler nicht ausschalten und dann irgendwann zum Ergebnis kommen, edomi wäre nicht verlässlich auf dem KNX-Bus. Vielleicht sollte auf der Verwaltungsseite bei ausgeschalteten Seq-Fehlern daher ein Hinweis stets daran erinnern, dass man sich dafür entschieden hat.

Darüber hinaus könnte es hilfreich sein, wenn man das Backup von den 00:00 verschieben könnte, statt es nur ausschalten zu können. Wäre ein Offset möglich oder eine Uhrzeit als Option , könnte man Kollisionen mit anderen Jobs auf Host oder im Netzwerk vermeiden. Oder statt 0:00 einfach so etwas krummes wie 0:13 fest einstellen...

just my 2 cents

[gaert]

Kurz zum "Verschieben" (zeitlich) des Backups: Du kannst das automatische Backup um Mitternacht deaktivieren und dann z.B. per ZSU und dem entsprechenden Logikbefehl das Backup selbst anstoßen. Dieses Feature existiert also bereits

[SeatSLF]

Sicher, aber wie schon gesagt: 1.43, 1.44 und 1.45 sind absolut gleich in Sachen KNX... (bis hinab zu 1.3x)

Das sich am KNX nichts geändert hat, mag ich ja gern glauben.

Selbst jetzt mit komplett sauberer Neuinstallation, habe ich wieder das selbe verhalten.

Nach Projektaktivierung werden alle Logiken und Visubefehle direkt umgesetzt.
Nach ca. 1Std. werden Logikergebnisse und Visubefehle nun mehr mit 2sek. Differenz umgesetzt.
Nach jetzt 7,5Std kommen Logikergebnisse mit mind. 10sek. "Verspätung" auf den Bus, genauso wie Visu Befehle.

In den Logs finde ich keine Fehler, der Bus arbeitet zuverlässig.
Edomi braucht halt "nur" sehr lange um selbst einfachste Logikergebnisse auf den Bus zu senden.
Selbst ein einfaches Ein und Ausschalten braucht mehr als 10sek.

Der Seitenaufbau in der Edomi Config oder Visu läuft ohne Probleme.
Edomi läuft auf einem eigenen Rechner, im Sys Monitor sieht man auch keine Auffälligkeiten.
Es scheint also intern etwas schief zu laufen.
Die Edomi.ini ist absolut in dem Zustand wie nach einer Neuinstallation,
nur die IPs und die Mail Config sind angepasst.

Dieses Problem kam erst mit 1.45, unter 1.44 lief alles sehr geschmeidig.
Daher würde ich gern auf 1.44 zurückkehren, um das mal zu testen.

Es sei den du hast noch eine andere Idee.

Anbei ein Screenshot vom Systemmonitor der Buskommunikation, als Beispiel:
IMG_0452.PNG

Der Stromwert läuft über einen Vergleicher und soll einfach nur den PM sperren,
hier sieht man deutlich den Versatz.
Nach direkter Projektaktivierung ist die Logik samt Ergebniss in knapp 1 Sek. auf dem Bus,
nach 7,5Std. braucht Edomi inzwischen über 10sek.
Und da ist kein Community Baustein drin/dazwischen oder was auch immer.

Die 2Fehler da unten sind einfach nur, weil momentan mein Internet streikt,
und Edomi den Update server nicht erreicht.

Noch mal ein Bild des Systems:
IMG_0453.PNG

IMG_0454.PNG

[jonofe]

Hast du das ganze mal mit einem einfachen Projekt ausprobiert?
ggf. kann es an "defekten" LBS liegen, die vielleicht lange Wartezeiten in der EDOMI Logikschleife verursachen.
Welche Community LBS verwendest Du?

[gaert]

Ein "Downgrade" wird nicht ohne Weiteres möglich sein, da Du das Projekt dann nicht importieren kannst (bzw. wird dies zu Problemen führen, da nicht vorgesehen). Vielleicht hast Du ja noch ein (Auto)Backup der 1.44 mit Projekt?!

Ausserdem kann man wohl ausschließen, dass Dein Problem mit 1.45 zusammenhängt - sonst wäre das Forum wohl prall gefüllt mit ähnlichen Schilderungen Ich kann Dir nur raten, sämtliches Logging zu aktivieren (insb. Monitor-Log) und wie André schon schrieb mal ein Minimalprojekt aufzusetzen.

[SeatSLF]

Wenn es an einem Community LBS liegen könnte werde ich heute Abend mal schauen,
ob die einzelnen Logiken Stück für Stück rausnehme.

[jonofe]

Wenn es an einem Community LBS liegen könnte werde ich heute Abend mal schauen,
ob die einzelnen Logiken Stück für Stück rausnehme.

Hattest du denn schon diese Probleme vor deinen Internet-Problemen.
Ansonsten könnte ich mir vorstellen, dass irgendein LBS versucht eine TCP/IP Verbindung aufzubauen und damit die Logik blockiert.

Die Logik Schritt für Schritt zu deaktivieren ist sicher der beste Weg, um der Ursache auf die Spur zu kommen.