EDOMI-Releases/Updates | Aktuell: Version 2.03

[SeatSLF]

War wohl ein Zufall, es ist beim "aufräumen" hängen geblieben

Habe dann noch mal Rebootet, aber es hat alles geklappt.

Edomi Error.jpg

[Robby]

Kann ich nicht bestätigen....bei mir ist das Update ohne Probleme durchgelaufen und der Rechner von alleine wieder hochgefahren.

[SeatSLF]

Ich weiß nicht ob es jetzt bei mir Zufall war, aber nach dem Update, ist der Rechner nicht von alleine hochgekommen.
Als ob er beim Reboot hängen geblieben ist.

Nach einem Manuellen Neustart funktioniert jedoch alles

Diagramme sind wieder in Ordnung, super Arbeit

[gaert]

So... Und mal wieder ein Update - so ist das in der Beta-Phase

Diesmal also Version 1.08 - WICHTIG: Auf 1.08 kann nur von 1.07 ausgehend geupdated werden! Dies betrifft alle Versionen, d.h. es müssen immer alle Updates bis zum Erreichen der "Zielversion" nacheinander eingespielt werden. Ab Version 1.07 wird dies von EDOMI überprüft, d.h. es kann nichts schiefgehen.

Changelog für EDOMI 1.08:

• in der edomi.ini ist die Konstante "global_debugTrace" hinzugekommen:
  • true = es wird ein "TraceLog" angelegt, d.h. es werden alle möglichen Ereignisse geloggt
  • aktuell betrifft dies nur die KNX-Kommunikation, d.h. es wird der komplette "Dialog" zw. EDOMI und dem IP-Router in das TraceLog geschrieben (da manche Nutzer Probleme mit Read-Requests haben, können wir so der Sache besser auf den Grund gehen)
  • WICHTIG: Das TraceLog wird nach jedem Reboot gelöscht! Damit das Log nicht "überquillt", sollte im Normalfall global_debugTrace=false sein
  • Zugriff auf das Log erhält man wie immer in der Verwaltung
• Probleme mit Diagrammen behoben: Durch Einführung des NTP-Dienstes in Version 1.07 kam es zu Problemen mit Diagrammen (Zeitzoneneinstellung). Dies sollte nun behoben sein.
• edomi.ini: global_knxWriteTimeout wird nun per Default =1 gesetzt (ist laut KNX-Spec empfohlen)
• edomi.ini: global_knxServerPort wird nun per Default =51000 gesetzt (statt zuvor 3672 - dies sorgte bei einigen Nutzer für Verwirrung)
• und die üblichen Kleinigkeiten, die man nicht sieht und die meiste Arbeit machen...

Upload folgt in Kürze...

[MarkusS]

Hm. Lt. Standard 03_08_10 "The description of the project part of the XML Scheme can be downloaded at any time from any customer account of the KNX Online Shop.".

Im Shop finde ich aber nix.

Dann schreibe ich mal eine Mail nach Brüssel ...

[MarkusS]

Helfen kann jeder der KNX Member ist und Zugriff auf das Manufacturing Tool hat, die XML-Deklaration ist Bestandteil des MT und darf von einem Hersteller in eigenen Produkten genutzt bzw. mit eigenen Produkten (Toolchain) weitergegeben werden.

Eine ältere Version der XML-Deklaration steht sogar offen auf der Konnex-Webseite http://www.knx.org/fileadmin/support...escription.pdf eine neuere Version aber immer noch ETS4 gibt es da in diesem widerlichen Fileverschlinger http://www.scribd.com/mobile/doc/216...14-Description

[vento66]

goto makki , der hat das letztens erst für das WG und ETS5 gemacht

[coliflower]

Klaus Gütter
Vielleicht kann Klaus helfen ?

tuxedo
Oder Alex ?

[MarkusS]

Ich weiß nicht ob die knxproj im Standard dokumentiert ist, vermute aber eher nicht.

Ich schreibe nachher mal eine Mail an jemanden der sich damit (knxproj) auskennt.

[gaert]

Klar - das ist schon lange in der Pipeline, erste Gehversuche habe ich schon hinter mir. Der einfach OPC-Import genügte mir bislang, da ich im Grunde eine physisch fixe KNX-Installation habe und nicht jeden Tag irgendwelche Änderungen vornehme. Aber natürlich werde ich den Import noch optimieren, bzw. die knxproj zu parsen versuchen. Gibt's da eine Doku zu?

[coliflower]

Der Pflegeaufwand wäre dadurch schon gering da nur eine "Quelle" die .knxproj ...
Auch zusätzliche Fehlerquellen wären damit vermeidbar ...

[MarkusS]

Der Import der Knxproj wäre sinnvoll. Die Knxproj ist nur ein gezippter xml-Haufen, von daher übersichtlich.

Der Vorteil der Knxproj ist dass da alle GAs drin sind und die Datentypendeklaration ist vollständig. Die esf enthält nur die verknüpften GAs und bei weitem nicht alle GAs haben eine Typdeklaration. Deswegen hatte Makki vor Jahren mal experimentiert, die GAs direkt aus dem SQL zu extrahieren.

Zwischenzeitlich kann auch der Gira Experte die Knxproj importieren und ich denke dass das der Weg der Zukunft ist.

Theoretisch könnte man mit der Knxproj deutlich mehr machen, z.B. eine Gebäudestruktur anlegen oder Funktionen generieren (so in der ETS gepflegt).

[coliflower]

Macht es Sinn an dieser Stelle anstatt der ESF die .knxproj zu importieren ? Ich vermute da wäre ein gröberer Eingriff notwendig ... oder :-) ?

[nbe]

Okay, danke für die schnelle Antwort.
Ist es denn geplant das der Import später auch Veränderungen übernimmt oder sie bemerkt und nachfragt wie mit der Veränderung umgehen soll?
Übernehmen oder ignorieren?

[gaert]

Aber Achtung: Der Import ist noch nicht fertig implementiert. Zunächst werden alle GAs importiert. Wenn man später etwas in der ETS ändert, werden die Änderungen nicht(!) importiert - nur neu hinzugefügt GAs werden auch beim Import hinzugefügt. Mit anderen Worten: was einmal importiert wurde, wird nicht mehr verändert.

und du musst nach dem Import die meisten DPTs von Hand einstellen, da der Export diese Information nur sehr lückenhaft enthält.