EDOMI-Releases/Updates | Aktuell: Version 2.03

[gaert]

Dann hattest Du wohl Glück Dieser Thread bezieht sich ausschließlich auf die "Release-Version" - nicht auf die Demo-VMs... Daher heißt der Thread ja auch "Release"

PS: Die VMs habe ich jetzt bei GoogleDrive entfernt, damit es nicht zu Verwirrungen kommt...

[SeatSLF]

bei mir hat es mit der letzten VM funktioniert

[gaert]

Welche Version war denn vor dem Update in der VM?

Und: Wie geht's in dem Screenshot weiter?

By the way: Das Update bezieht sich AUSSCHLIESSLICH auf die Version 1.05 in der INSTALLIERBAREN Version. Also NICHT für die VM-Versionen (die sind alle veraltet...).

[Winni]

Update Einspielen ging flott, nur leider fährt EDOMI nicht mehr vernünftig hoch:
EDOMI.jpg

im Admin ist ein roter Kreis um EDOMI, alles ausser Console ist "nicht verfügbar"
Das ganze läuft in einer VM, das Live-Projekt war aktiv.
Die Möglichkeit den Autostart von EDOMI abzubrechen, hab ich auch nicht mehr.... Dumm, dass ich aufgrund der positiven Feedbacks weder die VM gesichert habe, noch das Projekt vor lauter schnell schnell

[SeatSLF]

Du bist echt fix mit Features und Bugixes.

Top Job den du da erledigst.

[Robby]

Hallo Christian,

Update einspielen war ja ganz einfach. Den dazugehörigen Changelog auf der Seite finde ich auch klasse!!! Dann kann ja jeden Tag ein neues Update kommen, wenn es soooo einfach ist.

Gruß
Robby

[gaert]

Version 1.06

Inzwischen habe ich eine neue Version erstellt (1.06). Diese steht als Installations-ZIP zu Verfügung oder als Update-Datei:

Installation auf einem frischen(!) CentOS:
"edomi_beta_1-06.zip.edomi" ist AUSSCHLIESSLICH für eine komplette Neuinstallation gedacht, d.h. CentOS muss frisch(!) installiert sein. Also NICHT "über" eine vorhandene 1.05 installieren - dies ist nicht vorgesehen.

Update von Version 1.05:
Für alle, die bereits Version 1.05 installiert haben, gibt es die Update-Datei "EDOMI-Update_20160116_1-06.edomiupdate". Diese wird einfach auf der Adminseite (GUI) unter "Verwaltung -> Update" ausgewählt (muss natürlich lokal auf dem Rechner liegen) und der Rest wird automatisch erledigt.

Wichtig: Aufgrund eines Fehlers startet die Update-Prozedur nur, wenn ein Live-Projekt vorhanden ist und "läuft". In der Version 1.06 ist dieser Fehler behoben, d.h. die Update-Prozedur funktioniert auch ohne aktiviertes Projekt.


Changelog:

• NTP-Abgleich eingeführt: EDOMI gleicht die Zeiteinstellungen nun automatisch per NTP ab.
  • als Zeitzone kann während der CentOS-Installation nun z.B. "Europa/Berlin" gewählt werden (betrifft nur die Neuinstallation)
  • wenn das Update verwendet wird, wird automatisch "Europa/Berlin" eingestellt
  • die Zeitzone kann natürlich auch manuell angepasst werden - unter CentOS ist das allerdings etwas kniffelig (ich werde es später noch erklären)
  • Wichtig: Bei einer Zeitumstellung (Sommer/Winter) wird EDOMI zur Sicherheit automatisch neu gestartet. Ich arbeite aber daran, dass dies in Zukunft nicht mehr erforderlich ist.
• diverse kleinere Fehler wurden behoben

Viel Spaß

[Ferengi]

installation von centos und edomi hat soweit gut funktioniert.
Allerdings wäre es schön wenn man bei der Installation auch die Subnetzmaske verändern könnte, wahrscheinlich bin ich der einzige der 255.255.0.0 benutzt, und es ist ja auch sofort in der config sofort geändert, wollte es aber trotzdem anmerken.

[gaert]

Die IP des KNX-IP-Routers/Schnittstelle (und vieles andere) muss nach der Installation in der edomi.ini angegeben werden - so wie in der VM auch...

[vento66]

gaert Danke für das Installationsfile und Deine Arbeit, die Du in das Projekt steckst. Wäre es noc möglich, bei der Installation das KNX-Gateway mit anzugeben? Oder stehe ich hier auf den Schlauch, und hab das einfach übersehen?

[coliflower]

Hallo Christian,

ich finde es super wenn dass du es immer erklärst warum etwas so sein muss wenn es heißt dass es so sein muss - hier die NTP Problematik.
Dadurch wird es der Community klarer warum … ;-)

[gaert]

Ja, das ist mir natürlich bewußt - ich schreibe hier auf Layer 2, damit jeder versteht worum es geht aber ganz so einfach wie du es beschreibst ist es nicht: NTP liefert die aktuelle Zeit - und ein paar Metadaten. Was die Software daraus macht, ist ihre Sache.

Zum Verständnis: mir geht es nicht um die Nutzung von NTP auf OS-Ebene - das wäre trivial. Vielmehr soll EDOMI mit dem NTP-Server plaudern und gezielt an der Zeit schrauben. Insbesondere wegen Sommer/Winterzeit, aber auch um die Kontrolle nicht and OS abzugeben (z.B. Millisekunden-genauer Timer in der Logik).

unabhängig davon soll EDOMI nicht driften, auch nicht etwas/wenig/kaum... Der HS macht es ja vor: Hier wird quasi ein Deltawert per NTP ermittelt und intern angewendet.

Aber: Wer mag kann ja den NTP-Dienst auf OS-Ebene aktivieren. Allerdings wird das mit GMT0 etwas kniffelig Das Thema Timezone wird noch angegangen - war für mich bislang nicht wichtig. GMT0 ist übrigens deshalb so wichtig, da es keine Sommer/Winterzeit kennt. Daher erfolgt auch keine automatische Umstellung - den diese ist zur Zeit noch kontraproduktiv...

Bezüglich der blöden Sommerzeit/Winterzeit: absolut korrekt! Gehört abgeschafft.

[starwarsfan]

Hoi Christian

EDOMI muss intern quasi mit relativen Zeiten arbeiten, damit bei einer plötzlichen Zeitanpassung keine Merkwürdigkeiten entstehen: Z.b. läuft irgendein Timer und schwupp ist es ne Stunde später (oder auch nur ein paar Sekunden) - was nun?

Das wird aber mit ntp nicht passieren, da es ja genau der Witz von ntp ist, dass die Systemzeit nicht hart korrigiert wird. Sonst würde das Problem nicht nur Edomi sondern jeder andere zeitkritische Service auch haben. ;-)

Ntp gleicht die Systemzeit langsam an, um keinerlei Sprünge in der Zeit zu haben. Man kann sich das so vorstellen, dass die Systemuhr in gewissem Masse "langsamer" oder "schneller" läuft. Aus diesem Grund kann man i.d.R. einerseits die Systemzeit nicht setzen, wenn der ntp-Dienst gestartet ist und andererseits beendet sich ntp, wenn die Zeit zu schnell aus dem Ruder läuft und ntp mit der Korrektur nicht hinterher kommt. Das kann man schön auf alten Boards beobachten, auf denen die Hardware-Uhr bspw. aus Alterungsgründen extrem ungenau ist.

Die dumme Sommer-/Winterzeit-Umschaltung ist natürlich ein anderes Thema. Wird Zeit, dass das wieder abgeschafft wird...

[gaert]

Die Zeitzone muss bleiben wie sie ist (GMT). Dies spielt für die Systemzeit erstmal keine Rolle (ist ja nur ne Uhr). Aktuell muss man die Zeit manuell einstellen, sprich zweimal im Jahr (Sommer/Winter). Mit NTP habe ich schon längst gespielt (ist auch schon implementiert), aber da gibt es noch ein paar Probleme: EDOMI muss intern quasi mit relativen Zeiten arbeiten, damit bei einer plötzlichen Zeitanpassung keine Merkwürdigkeiten entstehen: Z.b. läuft irgendein Timer und schwupp ist es ne Stunde später (oder auch nur ein paar Sekunden) - was nun? Lösbar ist das natürlich, aber ich arbeite noch daran (ist im Detail ziemlich komplex). Daher bleibt zunächst nur das manuelle Einstellen, aber es gibt schlimmeres: Die Uhren in moderner Hardware arbeiten inzwischen recht präzise und zweimal im Jahr wird (manuell) ja neu kalibriert. Sollte fürs erste genügen denke ich.

Einen (relativ) einfachen Kompromiss habe ich bereits in der Schublade: EDOMI könnte z.B. einmal täglich Nachts einen NTP-Abgleich durchführen und solange (paar Sekunden) quasi "einfrieren". Derweil auflaufende Ereignisse würden natürlich gepuffert werden und nach der Synchronisation abgearbeitet werden. Der quasi unerwartete "timeshift" betrifft nämlich in erster Linie bestimmte Logikbausteine (Timer-Funktionen), d.h. die Logik müsste einen Moment pausieren. In der Praxis wäre dies kaum zu bemerken, es ginge ja nichts verloren, sondern wird nur ein paar Sekunden später ausgeführt.

[Jever]

Stimmt, da sollte Christian noch ein paar Hürden einbauen ;-)