LBS 19000153 Zeitformatierung/Addition: Falsche Ausgabe der Stunden

[wintermute]

Ja, mehr oder minder. Damals ging es um die Zeitzone, nicht ums Locale, aber das Prinzip ist dasselbe: es werden Einstellungen zur Laufzeit des Skriptes geaendert (sogar prozessweit, also nichtmal andere Threads waeren davor sicher) und da der LBS (weil ohne EXEC-Teil) Bestandteil der Edomi-PHP-Logik ist, sollte man es vermeiden dort die Zeitzone, locale, Time-Limits usw usf zu aendern.
Ich bin nicht der PHP-Gott und hab keine Ahnung wie man das ohne derart weitreichende Aenderungen oder extrem grossen Aufwand in den Griff bekommen koennte. Wenn da jemand was zu weiss, immer her damit.
Die vorgeschlagene Loesung werde ich so nicht implementieren da ich nicht sagen kann welche Auswirkungen das haben koennte. Tatsaechlich (kann man im Changelog sehen) konnte der LBS das frueher mal, die Funktionalitaet wurde in Version 0.5 aber (durchaus bewusst ) entfernt.

Aber natuerlich hindert dich keiner dran deine Version zu verwenden

[wintermute]

Das ist eigenartig. Meines Wissens ist die locale bei meiner Installation (CentOS) auf "de_DE" gestellt. Dennoch ist die PHP-Ausgabe stets Englisch...

Edomi zieht ein eigenes PHP-Setup mit auf - weiss grad nicht, vielleicht wird es da definiert...

[eghetto]

Spielen mit den Regionaleinstellungen für Edomi ist scheinbar tatsächlich keine gute Idee: Bei mir zeigten sich plötzlich seltsame Effekte. Einfachste Addition-Bausteine haben nicht mehr funktioniert - als Summen-Ergebnis wurde plötzlich Komma als Dezimaltrennzeichen statt Punkt verwendet. Die Werte sind in dieser Form unbrauchbar.

Ein Update auf 1.55 hat dem Spuk ein Ende bereitet - ich lass in Zukunft die Finger von den Locales... Wieder was gelernt.

[wintermute]

Du kannst setlocale ja auch so aufrufen, dass nur Einstellungen fuer Zeitformatierungen gesetzt werden... vielleicht funktioniert das besser?

[eghetto]

Bin leider kein PHP-Experte und kann ggf. nicht alle evtl. Seiteneffekte überblicken. Da ist mir das Nutzen-Aufwand-Verhältnis hier zu groß.
Setze nun den Übersetzer-Baustein (19000310) ein, um die Wochentags-Bezeichner zu transformieren - und hoffe in der Zwischenzeit auf andere Mutige an der Front...

[ak68]

Spielen mit den Regionaleinstellungen für Edomi ist scheinbar tatsächlich keine gute Idee: Bei mir zeigten sich plötzlich seltsame Effekte. Einfachste Addition-Bausteine haben nicht mehr funktioniert - als Summen-Ergebnis wurde plötzlich Komma als Dezimaltrennzeichen statt Punkt verwendet. Die Werte sind in dieser Form unbrauchbar.

Ein Update auf 1.55 hat dem Spuk ein Ende bereitet - ich lass in Zukunft die Finger von den Locales... Wieder was gelernt.

Das MUSS ich leider so bestätigen- Finger weg von der locale !

Ich musste das Update einspielen, um Edomi wieder lauffähig zu bekommen

Nach Änderung der locale sind auch bei mir seltsame Fehler wie falsche Berechnungen, falsche Visu-Ausgaben etc. aufgetreten !

[JimBeamJD]

Hab ein kleines Problemschen mit dem LBS:
LBS_19000153.JPG
obwohl das Ganze gerade erst initiert(Projekt neugeladen) wurde und noch keiner der Trigger ausgelöst sein sollte(Zeiitgeteuert), schein das Modul einen leeren String am A1 rauszugeben was das folge LBS dann natürlich versucht auszuwerten... In diesem Fall wird es sogar als positiv und somit mit einer 1 ausgewertet.

Erst durch anpassen des LBS quellcodes an folgender Stelle. komme ich zu einer Funktionsweise die dem zweck entspricht und keine Falschmeldungen nach der Initierung versacht:
Original:
...
if (($E[1]['refresh'] && $E[1]['value']!="") || ($E[6]['refresh'] && $E[6]['value']!="")) {
...
Angepasst:
...
if ($E[1]['refresh']==1 && $E[1]['value']!="") {
...

Es mag vielleicht an der späten Stunde liegen oder aber auch an mir selbst aber ich kan das ursprüngliche Verhalten nicht nachvollziehen...
Sehe ich vielleicht den Wald vor lauter Bäumen nicht?...

[wintermute]

Ich erlaube mir an dieser Stelle aus der (doch ueberaus umfangreichen) EDOMI-Hilfe zu zitieren:

Beim Start von EDOMI wird der LBS zudem über ggf. vorhandene Initialwerte an einem Eingang getriggert.

Das ist also kein Bug sondern ein Feature (steht sogar so im Changelog des LBS) und daher ein Layer-8 Problem.

Ich finde allerdings auch, dass der LBS da voellig artfremd eingesetzt wird. Der LBS ist zur Formatierung von Zeitangaben gedacht, will man Zeiten vergleichen gibt es passendere Bausteine, zB 19000152 (mit dem treffenden Namen "Zeitvergleich")

Man koennte aber auch gleich 19000151 nehmen, da ist eigentlich alles drin was man fuer ein solches Unterfangen braucht.

Man koennte aber auch voellig ungeeignete LBS solange umschreiben bis sie... egal, lassen wir das

Schau dir den 19000151 an, der sollte dich weiter bringen...

[JimBeamJD]

Layer-8 ist wie gesagt nicht asugeschlossen , aber nochmal auf die Zieldefinition/Zweck des ganzen:

Es soll zu einen bestiummten Zeit, einmal am Tag, in diesem Fall eine Minute vor dem Sonnenuntergang, eine Aktion durchgeführt werden.

Mit dem 19000151 verschiebe ich nur die Umschaltung zwischen Tag und Nacht, das ist in dem Fall wenig hilfreich denn die Aktion soll nur einmal zur einen bestimmten Zeit ausgeführt werden und nicht andauern nach Sonnenuntergang.

Mit dem 19000152 bekomme ich tatsächlich das erwünschte Verhalten hin, trotz des unerwarteten Verhaltens des 19000153 für mich, um den ich bei meiner Umsetzung nicht drumherum komme, da nur dieser die Zeitausgabe für den Vergleich passend modifiziert.

LBS_19000152.JPG
Der 15000040 ist in dem Fall tatsächlich nicht zielführend.

Danke!

[jonofe]

Mit dem 19000151 verschiebe ich nur die Umschaltung zwischen Tag und Nacht, das ist in dem Fall wenig hilfreich denn die Aktion soll nur einmal zur einen bestimmten Zeit ausgeführt werden und nicht andauern nach Sonnenuntergang.

Wenn ich dich richtig verstanden habe, willst du bei Sonnenuntergang eine einmalig Aktion durchführen.
EDOMI an sich ist ja Ereignisorientiert. Daher hat der 151 ja einen Triggereingang. An den entsprechenden Ausgang hängst du dann einfach einen Flankendetektor, von dem du dann die fallende Flanke als Trigger nimmst. Zwei LBS ohne Modifikation des Quellcodes.

[JimBeamJD]

Bei Sonnenuntergang wird bereits eine Aktion durchgeführt da soll diese auch bleiben, es soll nur eben eine Minute zuvor ein akustischer Signal erfolgen, als eine Art Vorwarnung/Info.

Mit dem Flankendetektor, komme ich von Anbeginn an nicht klar, habe eine Funktions-/Verständnisproblem, ich hab es eben ausprobiert und am Ende ist dieser bei sowohl E1 als auch bei E2 auf 1 bei einem simulierten Tag-->Nacht-->Tag Zyklus stehen geblieben. bzw die Ausgänge E1 und E2 werden zu 1 aber sie fallen nie zurück auf 0...

Wie zuvor geschrieben mit dem 19000152 komme ich ohne jegliche Modifikation der LBS zum Ziel, alles anderes ist, denke ich, ein ganz anderes Thema.

[vento66]

Warum sollen sie auch auf 0 fallen? EDOMI arbeitet, wie KNX Ereignissorientiert. Auch wenn die 1 da steht. löst sie keine Berechnungen mehr aus. Erst wenn die nächste 1 kommt....

[JimBeamJD]

Da hast Du recht, ich habe hier zu sehr auf das gewohnte Verhalten von Vergleichoperatoren gesetzt und nur am Flankendetektor direkt die Zustände kontroliert... An dem darauf folgenden LBS wurde aber nur dann eine Aktion/Berechnung durchgeführt wenn vor dem Flankendetektor sich etwas änderte und nicht wenn der Wert dort kontinurlich gleich blieb.

[Ing-Dom]

ich hab ein unerwartetes Verhalten des LBS.

Ich gebe als E1 an: 1969-12-31T22:00Z (Z = Zulu also UTC)


als E2: %d.%m.%Y %T

sonst nix.

da im edomi-system:

[root@SYS-VMEdomi3 ~]# date
So 26. Jul 10:56:26 CEST 2020
[root@SYS-VMEdomi3 ~]# date -u
So 26. Jul 08:56:28 UTC 2020
[root@SYS-VMEdomi3 ~]#

auch +2 als Zeitzone (MESZ) korrekt hinterlegt zu sein scheint, hätte ich als Ausgabe nicht

31.12.1969 23:00:00

erwartet, sondern 01.01.1970 00:00:00

Setzte ich E4 = 1 (UTC Modus) bekomme ich 31.12.1969 22:00:00 (wie erwartet).

Ist der Grund vielleicht, das am 01.01 keine Sommerzeit gilt?

[wintermute]

Ist der Grund vielleicht, das am 01.01 keine Sommerzeit gilt?

Ohne jetzt ganz tief in die PHP-internen Datumsberechnungen einzutauchen: ja, ich taete vermuten genau das ist der Grund.