Diskussionsthread EDOMI-Releases/Updates

[dpoth]

1.60... läuft.. endlich wieder der grüne Kreis.....

Danke & Gruss
Detlef

[vento66]

gaert bezgnehmed auf https://knx-user-forum.de/forum/proj...02#post1255902

Kann es sein, das der Queue momentan immer wieder mal falsche (alte) Daten enthält? Hat mich heute so den halben Nachmittag beschäftigt.... Habe schon an mir gezweifelt

[gaert]

Eigentlich eher nicht - wäre mir zumindest nicht bewusst. Ich habe die Queue durchaus intensiv getestet (mit Zählern usw.), die Reihenfolge stimmt schon.

Der Fehler ist ein anderer: Das Array wird byReference übergeben und hier spinnt's irgendwie ganz selten - warum weiß ich noch nicht. Leider tritt der Fehler derart selten auf, dass eine Analyse äußerst mühsam ist. Aber ich arbeite daran, am Ende ist es wahrscheinlich nur eine Kleinigkeit (wie immer).

Wichtig ist aber, dass nach dem Auslesen der Queue der entsprechende Eintrag (natürlich) gelöscht wird. Wenn Du die Queue also mehrfach ausliest (an versch. Stellen im Code), erhältst Du natürlich jeweils andere Werte. Ich bin selbst zunächst darauf reingefallen...

EDIT:
Du kannst den o.g. Fehler provisorisch zumindest feststellen, indem Du die Länge des zurückgegebenen Arrays aus der Queue verifizierst. Normalerweise entspricht die Länge der Anzahl der Eingänge - falls nicht, spinnt's...

[gaert]

Noch ein kleiner Bug:

Im Logikeditor werden zyklisch-laufende LBS nicht immer hervorgehoben (blinkende Titelleiste) - in der Live-Hilfe zu dem LBS passt es aber. Der Fehler ist natürlich schon behoben (in der nächsten Version) - sorry.

[gspsteve]

Ich bekomme auch nach Upgrade auf 1.60 folgende Fehler:

Handshake.PNG

Als Schnittschelle ist ein MDT Interface im Einsatz

[saegefisch]

gespenstisch...so lange so ruhig im Forum war es noch nie nach einem Update...

Nachtrag: Update problemlos, Init war nie mein Problem (meist 30s) und schien mir jetzt wenige Sekunden schneller. Ohne zu wissen, wie schnell vorher tatsächlich war - es hat mich bislang nie gekümmert, weil es lief/hinreichend schnell war.
Im Monitor sah ich tatsächlich einige Momente die 30T/s als Sende-Burst im Init, die ich als Max eingestallt habe. Wenn es fehlerfrei bleibt, werde ich vielleicht noch höher gehen und damit testen; das GW sollte mehr können.

Keinerlei Fehler im Log trotz der Rate (edomi-System: Dedizierte HW mit core i3, keine weiteren Dienste)

Neu ist: Queued ist wirklich 0 (bislang stand da meist was einstelliges länger drin, habe aber keine Auswirkungen gespürt).

-> Prima, Christian, Danke!

[rdeckard]

Als längerer MDT-Router / KNX-Fehler "Geplagter" möchte ich auch noch mein aktuelles Feedback abgeben.
Habe am Dienstag Nachmittag (14.8.) auf 1.60 upgedatet und seit dem noch keinen einzigen KNX-Fehler im Log gesehen. Gut, es sind erst 2 Tage, aber normalerweise hatte ich innerhalb von 24 Std. immer "ein paar" KNX-Fehler drin. (Früher wars ja noch schlimmer.)
Somit kann ich bei mir bestätigen, dass diese Version (für mich) schon mal was gebracht hat. Wie immer danke, gaert!

Habe vorhin auf 1.61 aktualisiert, wobei ich vermutlich nicht von den Änderungen betroffen bin.

Mit 1.61 dauert die Projektaktivierung ca. 3 Min. (bis es grün wird) und die Queue ging von ca. 12 sofort auf 1 runter. Das blieb dann aber fast 4 Min. lang so.
Visu ist dann zwar erreichbar, aber z.B. verschwindet der Logfehler-Indikator nicht von alleine. Und auch andere Werte (Aussentemp z.B.) sind noch leer.
Als dann die Queue auf 0 ging (eben nach 4 Min.) verschwand der Fehler-Indikator und alle Werte waren da.

Weiss jetzt nicht, ob diese 4 Min. normal für die Queue sind. Aber zumindest bin ich froh, im Moment mal keine KNX-Fehler im Log zu haben.

[luck789]

Seit kurzem, nehm an seit Update 1.59, funktioniert die Verschiebung deltaX bzw. Y im Zusammenhang mit split() bei mir nicht mehr (richtig). Das Universalelement wird nicht mehr angezeigt. Ist mir erst jetzt aufgefallen. Nutze es mit Behaglichkeit nach Frank zur "Indikator" Verschiebung und bisher hat es funktioniert.

Testweise hab ich es mit:

split(0)

{split(0)}

{str_split(#,0)}

probiert.
Bei {str_split(#,0)} z.B. wird zwar das Element angezeigt, aber ganz links oben auf der Visuseite, also Position (0|0)

„Funktionen left/mid/right/split bzw. str_left/str_mid/str_right/str_split modifiziert: der Rückgabewert ist jetzt stets ein String (z.B. wird "001" nicht mehr in "1" konvertiert)“

Diese Änderung in 1.59 hab ich im Verdacht dafür verantwortlich zu sein.

Muss ich die Formel anders schreiben, oder kommt das „Feld“ delta-X-Position mit der Neuerung von Split als String nicht klar? gaert Bug oder Feature?
Split()-Funktion ansich funktioniert auch, z.b. KO: 142|-60|#ffd700 ergibt bei Feld „Beschriftung“ {100-split(0)} die Augabe „-42“, nur im Feld delta-X eben nicht.

Kann das Verhalten, dass ein Element nicht mehr zu sehen ist, wenn Split bei delta-X-Position verwendet wird, jemand bestätigen?


Aktuelle Edomi Version ist 1.61.

[gaert]

rdeckard
Aktiviere doch mal das KNX-Log - vielleicht ist dort eine Ursache für die doch recht lange Wartezeit zu finden. Die Queue wird jetzt sofort abgearbeitet - ohne weitere Bedingungen. Natürlich setzt dies voraus, dass die gewünschten Telegramme auch zeitnah in der Queue landen

[powell]

Update auf 1.61 hat funktioniert, hatte danach aber wieder einen Aussetzer der KNX Verbindung mit dem MDT Router.
Mit 1.60 gab es keine Probleme.

Weiterhin dauert bei mir der Punkt Logs/Archive/Autobackups aufräumen immer recht lange(5min). In der Zeit geht leider gar nichts.
Wie bereinige ich das am besten? Hat da jemand einen Tipp dazu?

Danke!

Gruß
Patrick

[gaert]

Wenn der Router nicht auf einen connectionstate-request antwortet, hat er offenbar irgendein Problem (bzw. ein solches festgestellt). Das könnte aber auch ein Netzwerkproblem sein, oder ein Busspannungs-Einbruch ("Überlast") oder irgendetwas anderes in diese Richtung.

Aktiviere einfach mal das KNX-Log und dann wirst Du vermutlich sehen, dass EDOMI alle 30s einen connectionstate-request absetzt, der Router aber nicht innerhalb von 5s (default) antwortet.

Das Aufräumen dauert eben so lange, wie es dauert Wenn Du große Archive etc. hast (in Kombination mit einer "lahmen" CPU) dauert es eben entsprechend länger. Blockieren sollte dies natürlich die anderen Prozesse nicht, daher vermutlich ich mal, dass Deine Hardware zu schwach ist?!

[powell]

Danke für die Antwort!

Dann werd ich den KNX-Log besser wieder aktivieren.


Muss ich mir eventuell doch mal eine leistungsstärkere Hardware zulegen, aktuell läuft alles auf einer APU 2C4. Eigentlich läuft diese zwar immer bei max 30% CPU Leistung, aber vielleicht mal einfach was anderes testen.

Gruß
Patrick

[wintermute]

Kann das Verhalten, dass ein Element nicht mehr zu sehen ist, wenn Split bei delta-X-Position verwendet wird, jemand bestätigen?

Ja, ich...
Mach mal aus dem "{split(0)}" ein "parseInt({split(0)})".

[luck789]

wintermute Vielen Dank.
mit

"parseInt({split(0)})"

klappt es wieder.
Vielleicht könnte man das in der Hilfe unter Funktionsreferenz aufnehmen

Gruß
Andreas

[gaert]

str_stringornum() bzw stringornum() sollten es eigentlich auch tun. Aber ich kann parseInt() natürlich auch mit reinnehmen, dann als toInt() oder so.

Generell kann man natürlich sämtliche JS-Funktionen nutzen, aber bei manchen Funktionen ist dies nicht ohne Weiteres möglich. Daher die eigenen Implementierungen, um nicht zu verwirren.