Zeitupdate wertet Schaltuhren nicht erneut aus

[ginkel]

Moin,

mir ist heute folgendes Verhalten des Logikmoduls aufgefallen:

Wenn das komplette System nach Spannungswiederkehr wieder hochläuft ist u.U. noch eine falsche Uhrzeit (und Datum) auf dem Bus (im MDT-IP-Interface), da der NTP-Server noch keine aktuelle Zeit hat.

Wird dann später eine (korrekte) Uhrzeit gesendet, scheint es mir so, als würden die Zeitschaltuhren nicht neu ausgewertet. Das passiert erst nach Geräteneustart (oder vmtl. beim jeweils nächsten Schaltzeitpunkt - so lange wollte ich aber nicht warten).

Viele Grüße
Thilo

[mumpf]

Hi,

hier ist doch ganz klar nicht das Logikmodul schuld, oder? Das kann doch nichts dafür, dass das MDT-Interface eine ungültige Zeit auf den Bus schickt! Von Seite des Logikmoduls hast Du ja auch die Möglichkeit, das Logikmodul entsprechend später starten zu lassen. Oder Du baust Dir eine Logik, die - sobald Du feststellst, dass die Zeit gültig ist (mir ist nicht klar, wie das gehen sollte) - das Logikmodul neu startet.

Am Sinnvollsten wäre es, MDT dazu zu bringen, dass sie erst eine Zeit senden, wenn die gültig ist.

Schaltzeiten werden auf jeden fall nur einmal nachgeholt, alles andere wäre ein rumraten und nicht deterministisch.

Gruß, Waldemar

[ginkel]

MDT trifft hier keine Schuld. NTP macht hier ein Raspberry Pi, der hängt im selben Sicherungskreis wie die Buskomponenten und das DSL-Modem. Heißt: Wenn die Spannung weg ist, dauert es nach Wiederkehr eine Weile bis es es wieder Internet gibt und damit eine gültige Uhrzeit. Vorher startet ein Raspi mit irgendwelchen Defaults... Ich kann dem Raspi ne RTC verpassen, dann hat sich das auch erledigt...

Das Verhalten des LM ist für mich ok, wenn das "works as designed" ist. Dachte mir nur, ich teile meine Beobachtung mit. ;-)

[mumpf]

Ich werde ab dem nächsten Release auch DPT19 für den Zeitempfang unterstützen. Das erlaubt es, dem KNX-Zeitserver auch mitzuschicken, ob die Zeit valide ist. Wenn nicht, ignoriere ich solche Telegramme. Aber das wird in Deiner Situation auch nicht helfen, weil MDT wahrscheinlich denkt, die haben einen gültigen NTP-Server, oder?

[ginkel]

So ist es, der Raspi hat (mangels Referenz) keine Ahnung, dass er eine falsche Zeit versendet, das IP-IF noch weniger. Hab hier auch schon ein RTC-Modul liegen, aber das in "kritische Infrastruktur" reinzubasteln überlegt man sich mehrfach und sehr gut. ;-)

Andererseits ist die gute Nachricht, dass der Fix bzgl. PA-Verlust on Power-Loss funktioniert.

[mumpf]

Ich werde folgendes machen: Wenn ein Telegramm ein ungültiges Datum enthält, wird das Telegramm verworfen. Wenn allerdings Dein Zeitserver ein gültiges, aber altes Datum sendet, dann sehe ich keine Option bzw. dann müsstest Du mal schreiben, was der schickt.

Wo ich nicht weg von möchte: Nach dem empfangen des ersten Telegramms (in Zukunft das erste gültige) werden die Zeiten nachgeholt.

Was Du noch probieren könntest: Nicht das ganze Logikmodul später starten lassen, sondern nur die Zeitkanäle, die nachgeholt werden sollen. Allerdings ist das nur ein Versuch, ich bin mir ziemlich sicher, dass die mit der ersten empfangenen Datum/Zeit nachgeholt werden und dann nur nach der Startzeit ihren Wert senden.

Andererseits ist die gute Nachricht, dass der Fix bzgl. PA-Verlust on Power-Loss funktioniert.

Danke für die Rückmeldung, ich hatte es inzwischen hier so oft probiert, ich bin mir inzwischen auch selber sicher, dass es nicht mehr passieren wird.

Ich mach das erstmal wieder auf, und werde passend die Korrektur mit dem ungültigen Telegramm kommentieren.

[mumpf]

So, da ich sowieso an der Applikation bin, werde ich noch eine Verzögerung für "Schaltzeiten nachholen" einbauen. Das löst dann alle Probleme, bei denen die Leute am Anfang gültige, aber falsche (meist alte) Zeiten empfangen.

Anders gesagt: Man muss dann eine Verzögerung einstellen, bei der man sich sicher ist, dass eine gültige Zeit auf dem Bus ist.

Ich denke, das wird das Problem von allen lösen, die nach dem Neustart - wodurch auch immer - zwar gültige, aber veraltete Zeittelegramme haben.

Ich gehe mal davon aus, dass das Dein Problem auch lösen würde, oder?

[mumpf]

Ok, nach einigem Hin- und Her wird die finale Lösung doch ein ignorieren aller Datum-Telegramme, die ungültig oder veraltet (<2022) sind. Die Änderungen werden gerade getestet.

[mumpf]

Das ist jetzt in 1.7 implementiert (im Branch new-time). Ich teste das jetzt auf meinen produktiven Instanzen und wenn bis zum Wochenende keine gravierenden Fehler auftauchen, wird es am 14. freigegeben.