[Wunsch] 90.at.pm - timespec Definition als timestamp ermöglichen

[rudolfkoenig]

Und was passiert mit *1448751600 oder gar +*1448751600 ?

[betateilchen]

Nichts unerwartetes:

(http://up.picr.de/23644993wg.png)

(http://up.picr.de/23644994jb.png)

(http://up.picr.de/23644995ya.png)

+ und * machen bei einem absoluten timestamp ja nicht viel Sinn.

[betateilchen]

Hallo Rudi,

ich bitte Dich, Dich zwischen folgenden Varianten zu entscheiden.

• Entweder timestamps als timespec so zu verarbeiten, dass der korrekte Zeitpunkt gesetzt wird, der durch den timestamp eindeutig definiert ist.
• Oder die in GetTimeSpec() eingeführte Änderung für timestamps wieder auszubauen und keine timestamps zuzulassen (was ich sehr schade fände).

Aktuell generiert das at-Modul kommentarlos völlig sinnlose (falsche) at-Devices, wenn der Timestamp mehr als 24 Stunden in der Zukunft liegt. Das ergibt keinen Sinn und ist absolut verwirrend.

[rudolfkoenig]

Ich habe die Sekunden aus GetTimeSpec entfernt, und zur at Definition die Moeglichkeit einer Datumsangabe im Form von Sekunden seit 1970 oder ISO8601 hinzugefuegt. Ein + oder * mit Datumsangabe wird nicht erlaubt, weiterhin ist die Datumsangabe dokumentiert.

Was weiterhin nicht geht, und vermutlich noch Arbeit fuer mich verursachen wird:
- falls at per Datum definiert ist, macht ein gesetztes aligntime Attribut alles kaputt
- der Wizard in der FHEMWEB Detail-Ansicht beherrscht die Datumsangabe nicht.

[betateilchen]

Hallo Rudi,

danke, dass Du das Thema nochmal aufgegriffen hast, ich werde das die Tage mal testen, bin allerdings aktuell noch ausser Haus unterwegs.

Zum Thema "alignTime" fällt mir spontan ein: Das alignTime macht doch ohnehin nur dann Sinn, wenn es sich um ein wiederholendes at handelt. Das aber ist nach Deiner Beschreibung bei Datumsangaben ausgeschlossen. Insofern müsste man das Problem doch in der AttrFn einfach abfangen können, wenn man prüft, ob das at überhaupt eine Wiederholung besitzt und dann gar nichts tut (ausser vielleicht einen Fehler loggen)?

Zum Wizard kann ich nicht viel beitragen, der ist mir ohenhin schon immer suspekt, vor allem wenn man darin per Mausklick versucht, ein wiederholendes at in ein relatives umzuwandeln - da passieren die merkwürdigsten Dinge 

[betateilchen]

ich traue es mich ja fast nicht zu sagen... aber mit deiner jetzigen Implementierung ist die Möglichkeit weggefallen, die "Sekunden seit 1970" als Rechenergebnis in {EvalPerl} zu übergeben.

Das alignTime Problem sollte sich nach einem ersten Blick in den Code in der AttrFn lösen lassen, wenn man dort auf $hash->{PERIODIC} prüft und einfach nichts tut, wenn es kein periodisches at ist.

[rudolfkoenig]

alignTime ist doch kein Problem: es prueft selber auf periodic, und das ist bei der absoluten Zeitangabe nicht erlaubt.