EDOMI-Releases/Updates | Aktuell: Version 2.03

[WagoKlemme]

Danke für das Update.
Die Performanceoptimierung hat bei mir merklich die Projektaktivierung verkürzt.
Im LBS Systemauslastung verwendest Du procStatus_getData(2). Könntest Du bitte ein paar erklärende Worte hierzu "verraten" ? Auch zu dem Wert in Klammern.
ESF-Import -> TOP

Ich hätte aber gerne meine geliebte Bahnhofsuhr zurück. Ich habe schon verschiedene Einstellungen durch, schaut aber nicht so aus wie das Original.

[gaert]

Die "Analoguhr" wurde nur um einige Optionen erweitert, jedoch nicht im Aussehen verändert?! Wenn Du alles auf "automatisch" (=0) belässt, sollte die Uhr wie zuvor aussehen.

procStatus_getData() liefert diverse interne Prozess-Informationen und sollte normalerweise nicht weiter interessieren... Hier mal meine internen Notizen - Grammatik und Rechtschreibung sind zu ignorieren

    Id 1: proc_main.php

        [0]=Startdatum (EDOMI wurde zu diesem DateTime gestartet - also nach der Init-Phase usw.!)
        [1]=PID von proc_main.php (wird von getEdomiStatus() benötigt)

        [19]=Status von proc_main.php:
                (ungenutzt)


    Id 2: proc_sysinfo.php
        [0]=CPU-Last in %
        [1]=RAM belegt(!) in %
        [2]=HDD belegt(!) in %
        [3]=Systemlast
        [4]
        [5]
        [6]=Anzahl der PHP-Prozesse
        [7]=Anzahl der HTTPD-Prozesse (Apache)
        [8]=Anzahl der DB-Tables (###)
        [10..18]=wie 0..8, aber als Peaks (seit Neustart)

        [19]=Status von proc_sysinfo.php:
                0=läuft nicht
                2=läuft


    Id 3: proc_knx.php
        [0]=Anzahl der aktuellen Telegramme (KNX) in der Write-Queue (Read-Queue wird von serverLogic.php ermittelt)
        [1]=Gesamtanzahl "unbekannte Nachrichten" (empfangene Nachrichten vom IP-Router, die das Gateway nicht einordnen kann)
        [2]=Gesamtanzahl Read: unbekannte GAs (also GAs, die EDOMI nicht kennt)
        [3]=Gesamtanzahl Write = Tx
        [4]=Gesamtanzahl Read (IP-Router / lokal)
        [5]=Gesamtanzahl Read = Rx (KNX)
        [6]=Gesamtanzahl Read/Write-relevante Fehler (ohne [7])
        [7]=Gesamtanzahl Verbindungsrelevante Fehler,z.B. Open-Fehler, Heartbeat-Timeout, etc. (ohne [6])
        [8]=Gesamtanzahl Verbindungsversuche (normal wäre 1)
        [9]=Verbindungsstatus: 0=disconnected, 1=connected
        [10]=wie [0], aber als Peak (seit Neustart)
        [11]=
        [12]=
        [13]=Telegrammrate (letzten 5s) Write = Tx
        [14]=
        [15]=Telegrammrate (letzten 5s) Read = Rx (KNX)
        [16]=
        [17]=
        [18]=

        [19]=Status von proc_knx.php:
                0=läuft nicht
                1=bereit (Prozess ist gestartet, verrichtet aber noch nicht seinen Dienst)
                2=läuft


    Id 4: proc_logic.php
        [0]=Anzahl der arbeitenden Logikbausteine, also alle aktuell getriggerten (ohne [4])
        [2]=Anzahl der aktuellen Telegramme (KNX oder intern) in der Read-Queue
        [3]=Anzahl der aktuellen Befehle von einer Visu (CMD-Liste, Button geklickt, ...)
        [4]=Anzahl der laufenden Logikbausteine, z.B. Timer

        [1]=Anzahl der Logikbausteine, die korrekt initialisiert wurden (gehört zu [11])
        [11]=Anzahl der Logikbausteine, die zu initialisieren sind (gehört zu [1])

        [10,12,13,14]=wie 0,2,3,4 aber als Peaks (seit Neustart)

        [19]=Status von proc_logic.php:
                0=läuft nicht
                1=bereit (Logic ist deaktiviert (Initialisierungsphase in serverMain.php), d.h. nur Telegramme empfangen und in db.(RAM)ko schreiben)
                2=läuft (Logic ist aktiviert (normaler Zustand))
                3=läuft (Logic ist deaktiviert (Initialisierung der Bausteine))
                4=wird beendet (Logic wird deaktiviert)


    Id 5: proc_queue.php
        [0]=Anzahl der aktuellen Befehle mit Status=0 (warten auf Start) in der Queue
        [1]=Anzahl der aktuellen Befehle mit Status=1 (laufen gerade) in der Queue
        [10..18]=wie 0..9, aber als Peaks (seit Neustart)

        [19]=Status von proc_queue.php:
                0=läuft nicht
                1=bereit (Prozess ist gestartet, verrichtet aber noch nicht seinen Dienst)
                2=läuft
                Hinweis: der Status wird beim Start von EDOMI in dieser Reihenfolge verändert:
                    - während des Wartens auf Start/Projektaktivierung ist der Status=2 (damit in dieser Phase Queue-Befehle abgearbeitet werden können)
                    - bei der anschließenden Initialisierung ist der Status=1 (quasi "Pause")
                    - und schließlich beim echten Start ist der Status=2 (Queue-Befehle ganz normal abarbeiten)


    Id 6: proc_phone.php
        [0]=Status (1=Connected, 0=Disconnected)

        [19]=Status von proc_phone.php:
                0=läuft nicht
                1=bereit (Prozess ist gestartet, verrichtet aber noch nicht seinen Dienst)
                2=läuft


    Id 7: (frei)
        - reserviert für "proc_7.php"


    Id 8: (frei)
        - reserviert für "proc_8.php"



    Id 9: Prozess-Steuerung: proc_main.php steuert hiermit die anderen Prozesse (diese greifen nur lesend zu)
        [0]
        [1]
        [2]=proc_sysinfo.php:    1=Beenden (ist per default aktiviert, bzw. steuert sich selbt)
        [3]=proc_knx.php:         1=Beenden (ist per default aktiviert, bzw. steuert sich selbt)
        [4]=proc_logic.php:     1=Beenden (ist per default aktiviert, bzw. steuert sich selbst über sysKO[2])
        [5]=proc_queue.php:        0=Warten, 1=Beenden, 2=Aktivieren (Normalzustand)
        [6]=proc_phone.php:        0=Warten, 1=Beenden, 2=Aktivieren (Normalzustand) Achtung: Nachdem der Phonemonitor aktiviert wurde (2), kann er nur noch beendet werden (1), aber NICHT pausiert (0)!
        [7]=reserviert für "proc_7.php"
        [8]=reserviert für "proc_8.php"
        [9..19]=dto.

[SeatSLF]

Reagiert Edomi bei irgendwem mit zunehmender Laufzeit immer träger?

Nach einem Neustart, läuft alles bestens, nach ein paar Stunden läuft die Visu zwar und auch die Logiken aber Edomi sendet mit bis zu 5sek später erst auf den Bus, selbst bei einfachem an und aus.

gaert kann es mit der "neuen" option bei verhalten von seq. Fehlern zusammenhängen, das werde ich wohl morgen erst testen können.

Im Projekt selber habe ich nichts geändert, nur das Update eingespielt.

[gaert]

Diese Ente der neuen Option bezüglich der SequenceCounter-Fehler ist einfach nicht totzukriegen... Aber gerne nochmal: Bei einem SeqCounter-Fehler wird ggf. die KNX-Verbindung neu aufgebaut - nicht mehr und nicht weniger. Wenn dies alle paar Sekunden passiert, wird dies natürlich zu gravierenden Geschwindigkeitseinbußen in Sachen KNX führen...

[tger977]

nun ja, die seq. counter Einträge hab ich leider auch seit V1.44 (und nun auch bei 1.45) bei unveränderter Schnittstelle immer täglich kurz nach Mitternacht (20-40s danach) mit 3-4 Einträgen. Danach ist den Rest des Tages Ruhe...

da nun ja offensichtlich nichts geändert wurde was dies erklärt würde ich einfach mal folgenden Wunsch in den Raum stellen:
kann man die seq.count Errors nicht auch in der edomi.ini abschaltbar machen? Ist dann halt nur ein Pflaster, würde mich aber nicht weiter stören. Nur die tägliche Anzeige in der Visu (ja, ich weiß man kann das deaktivieren, aber dann bekomm ich "echte" Fehler halt auch nicht mehr zeitnah mit...) und auch die ständigen Hinweise auf der Adminseite und Fehlerlog Löschaktionen sind echt unschön. Das System funktioniert sonst ja absolut einwandfrei bis auf diese eine Minute nach Mitternacht...

und jetzt duck und weg...

[starwarsfan]

Hallo miteinander

nun ja, die seq. counter Einträge hab ich leider auch seit V1.44 (und nun auch bei 1.45) bei unveränderter Schnittstelle immer täglich kurz nach Mitternacht (20-40s danach) mit 3-4 Einträgen. Danach ist den Rest des Tages Ruhe...

Ack, geht mir genauso. Am Setup drumherum hat sich absolut nichts geändert.

da nun ja offensichtlich nichts geändert wurde was dies erklärt würde ich einfach mal folgenden Wunsch in den Raum stellen:
kann man die seq.count Errors nicht auch in der edomi.ini abschaltbar machen? Ist dann halt nur ein Pflaster, würde mich aber nicht weiter stören. Nur die tägliche Anzeige in der Visu (ja, ich weiß man kann das deaktivieren, aber dann bekomm ich "echte" Fehler halt auch nicht mehr zeitnah mit...) und auch die ständigen Hinweise auf der Adminseite und Fehlerlog Löschaktionen sind echt unschön. Das System funktioniert sonst ja absolut einwandfrei bis auf diese eine Minute nach Mitternacht...

+1 von mir, fänd' ich auch sehr praktisch. Zumal ich auch nicht nachvollziehen kann, warum das Problem auftritt...

[SeatSLF]

Diese Ente der neuen Option bezüglich der SequenceCounter-Fehler ist einfach nicht totzukriegen... Aber gerne nochmal: Bei einem SeqCounter-Fehler wird ggf. die KNX-Verbindung neu aufgebaut - nicht mehr und nicht weniger. Wenn dies alle paar Sekunden passiert, wird dies natürlich zu gravierenden Geschwindigkeitseinbußen in Sachen KNX führen...

Ich habe gestern Abend nochmal, das Verhalten bei Seq. auf "true" gesetzt.
Davor und jetzt habe ich KEINE Seq. Fehler.

Nach ca. 1-2Std. nach Neustart des Projektes reagiert Edomi nur noch verzögert,
im Livemonitor sehe ich z.b. das der Fensterkontakt sofort sendet, Edomi aber darauf erst 5sek.
später reagiert.
Das selbe bei normalem Schalten aus der Visu herraus.

Ich habe seit 1.43 nichts mehr geändert, auch die Firmware von Enertex ist die selbe.

Irgendwas muss ja innerhalb Edomi passiert sein was sowas hervorruft.

[BadSmiley]

1. Grundgesetz: Edomi macht keine Fehler!
2. Grundgesetz: Geart macht keine Fehler
3. Grundgesetz: siehe 1. Oder 2.

Ergo, der Fehler muss an euch liegen.

Ps: ich hoffe, ich habe 1 und 2 nicht vertauscht.

[heckmannju]

Du hast das mit dem Aktivieren vergessen Roman.
VG
Jürgen

[WagoKlemme]

SeatSLF
Was sagt denn deine CPU-Last wenn der "Fall" dann soweit ist ?

BadSmiley
1. Edomi ist das was Du daraus machst.
2. gaert macht tatsächlich seehhhr wenige Fehler, was bei dem Paket und mit der Sprache (bäh) schon fast an ein ...
3. bettelst Du förmlich um ein blaues Auge..

[gaert]

Das Deaktiver-Thema hatten wir doch schon... Fehlermeldungen einfach weg zu konfigurieren ist irgendwie eine denkbar ungünstige Lösung Aber ich pack's gerne auf meine Liste - kann ja jeder selbst entscheiden, ob er die Option nutzt oder nicht.

Verwendet ihr eine VM oder echte Hardware? Um Mitternacht werden diverse Aufräumarbeiten und ggf. ein Backup durchgeführt (natürlich im Hintergrund). Ich könnte mir vorstellen, dass eine VM in Sachen Timing ins Trudeln kommen könnte (oder schlicht zu lahm ist, v.a. wenn das Hostsystem zufällig auch noch irgendwelche Aufräumarbeiten durchführt).

[SeatSLF]

SeatSLF
Was sagt denn deine CPU-Last wenn der "Fall" dann soweit ist ?

BadSmiley
1. Edomi ist das was Du daraus machst.
2. gaert macht tatsächlich seehhhr wenige Fehler, was bei dem Paket und mit der Sprache (bäh) schon fast an ein ...
3. bettelst Du förmlich um ein blaues Auge..

Das System ist völlig entspannt, kein hoher Load, nix verdächtiges im RAM, der Seitenaufbau ist völlig geschmeidig.

Auf dem Bus selber ist auch nix los.

gaert ich habe momentan kein Seq Fehler,
daher verwundert mich es umso mehr.

Nach Projekt Neustart läuft eine Stunde lang alles völlig geschmeidig, danach kommt es immer mehr das Edomi verzögert auf den Bus sendet.
Der Rest läuft ja völlig geschmeidig.

Edomi läuft auf einem eigenen Rechner wo auch nichts weiter läuft.
Das verhalten ist ERST NACH dem Update auf 1.45.

Es wurde NICHTS am Projekt geändert.

[gaert]

Was soll ich dazu sagen?! Bei mir läuft's seit eh und je völlig geschmeidig SeqFehler hatte ich noch keinen einzigen in nunmehr fast 2 Jahren... Und das, obwohl ich EDOMI sehr intensiv nutze - meine gesamte KNX-Installation wird ausschließlich von EDOMI gesteuert.

Vielleicht hast Du irgendwelche LBS oder zusätzliche Dienste im Einsatz, die das Problem verursachen?! Gibt es irgendwelche Hinweise in den Logs?

[crewo]

Ich weiß nicht ob das hier hilfreich ist, aber ich habe festgestellt das es diese SeqFehler hagelt wenn ich mit der ETS auf dem Bus unterwegs bin. Dazu kommen dann noch "TUNNELING_REQUEST / ErrMsg: Unbekannter Fehler / Raw..." Meldungen im Log wenn man hier Programmierungen durchführt - und ich habe auch ein bisschen Woli im Verdacht zu "stören", das läuft noch auf dem Tablet und verbindet sich direkt mit dem Router. Eventuell als Idee für die Fehlersuche hier. Bei mir sind auch seit 1.44 SeqFehler im Log, hatte ich davor auch nicht. Verhalten ist soweit ich sehe aber stabil, aber bei mir läuft auch noch sehr wenig im Testbetrieb.

[SeatSLF]

Ich werde das System wohl einfach mal neu aufsetzen, ist ja relativ schnell erledigt.