Ankündigung

**klaus_kraemer** · 16.05.2014, 10:29

Liebe Enertexler,

an obigem Beispiel seht Ihr vielleicht, wie unkomfortabel es ist, dass man eine lokale Variable nicht gleich bei der Deklaration auch initialisieren kann.

Das ist unnötige Tipperei mit ihren Fehlerquellen und verbraucht viel Platz am Bildschirm...

Klaus

**enertegus** · 17.05.2014, 15:49

Zitat von klaus_kraemer Beitrag anzeigen

Liebe Enertexler,
an obigem Beispiel seht Ihr vielleicht, wie unkomfortabel es ist, dass man eine lokale Variable nicht gleich bei der Deklaration auch initialisieren kann.

Ich hab das Beispiel nicht im einzelnen nachvollzogen, aber ich vermute hier keinen Bug.
Die Sache mit dem "unkomfortabl" liegt daran, dass der Compiler erst mal nicht so gebaut war, lokale Variablen zu erlauben. Am Ende wurde es so implementiert, dass der Tradeoff zwischen Kosten und Umsetzung optimiert wurde.

Dein Problem sollte erst gar nicht entstehen:
[highlight=epc]
utcZeitNow=utcconvert(utctime())
[/highlight]
Nun ist der String akutell mit der UTC Zeit geladen.

**klaus_kraemer** · 17.05.2014, 17:46

Das war jetzt nett daran vorbei:

Um die Nummer des aktuellen Tages im Jahr zu bestimmen, brauche ich einmal den 1. Januar des laufenden Jahres, also mein Konstrukt:

[highlight=epc]
:var strAnfangJahr@
strAnfangJahr@ = convert(Year,$$) + $-01-01-00-00-00$
:var anfangJahr@
anfangJahr@ = utc(strAnfangJahr@)
[/highlight]

(Wie oben schon bemerkt, habe ich den String nur um des Debuggens willen)

Und diese Umwandlung funktioniert leider nicht, bitte schau den Screenshot des Debuggers nochmal an. Für mich ist der als Parameter übergebene String "strAnfangJahr" exakt wie im Handbuch aufgebaut, also sollte utc(strAnfangJahr) auch kein 0u64 an "anfangJahr" übergeben, sondern den u64-Wert für Neujahr.

Das solltet Ihr dann bitte doch einmal nachvollziehen - den Quellcode habt Ihr ja gleich oben im Thread.

Dein Vorschlag ginge dann natürlich für den aktuellen Tag, aber der hilft nix, wenn Neujahr nicht gesetzt werden kann...

**enertegus** · 19.05.2014, 09:01

Zitat von klaus_kraemer Beitrag anzeigen

Dein Vorschlag ginge dann natürlich für den aktuellen Tag, aber der hilft nix, wenn Neujahr nicht gesetzt werden kann...

Sorry, der Fehler ist in der Doku: Die Uhrzeit ist mit Doppeltpunkt getrennt anzugeben, also etwa so :

Code:

z2=$2014-01-01 00:00:00$

**klaus_kraemer** · 19.05.2014, 13:48

utc(): Immer noch keine Funktion

[highlight=epc]
/*-------------- DayOfYear ---------------------------------------------------------------*/
:begin GetDayOfYear()
:info $Arbeitet mit den globalen Variablen Year, Month und Day!!!$
:var result@
:var test@
test@ = utcconvert(utctime())
//------------- Umformung 1.1. des Jahres in UTC
:var strAnfangJahr@
strAnfangJahr@ = stringformat(Year,0,3,4,4) + $-01-01 00:00:00$
:var anfangJahr@
anfangJahr@ = utc(strAnfangJahr@)
//------------- Umformung aktuelles Datum in UTC
:var strToday@
strToday@ = stringformat(Year,0,3,4,4) + $-$ + stringformat(Month,0,3,2,2) + $-$ + stringformat(Day,0,3,2,2) + $ 00:00:00$
:var today@
today@ = utc(strToday@)
//------------ Zeitdifferenz berechnen [ms als u64]
:var delta@
delta@ = today@ - anfangJahr@
///------------ Tage berechnen
:var days@
days@ = delta@ / 86400000u64 + 1u64;
///------------ Ergebnis als u16
result@ = convert(days@,0u16);
:return result@
:end
[/highlight]

Debugfenster hierzu im anhängenden Screenshot

Hallo Enertegus,

leider kommt mit geändertem Stringparameter nichts besseres raus. Ich habe den aktuellen Code oben nochmal angefügt. Die globalen Variablen, die in ":info" angesprochen werden sind vom Typ 0u8 für Day und Month, sowie 0u16 für Year.

Der jeweils gebildete Stringparameter für utc(...) sieht jetzt so aus, wie Du es mir gepostet hast - aber es funktioniert trotzdem nicht.

Mich erschreckt dabei auch, dass utcconvert(utctime()) einen Ausgabestring erzeugt, der wieder dem Format im Handbuch entspricht, siehe die lokale Variable "test@". Den so erhaltenen String könnte man also nicht an utc() weitergeben.

Ihr müsst das doch auch mal getestet haben? Hast Du nicht ein paar Zeilen Code, die bei Euch ein vernünftiges Ergebnis der utc-Funktionen bringen?

Der Vollständigkeit halber: Ich nutze Patch 3.009 / Eibstudio 3.007

Angehängte Dateien

DayOfYear_Debug.jpg (30,6 KB, 111x aufgerufen)

**enertegus** · 19.05.2014, 15:54

Zitat von klaus_kraemer Beitrag anzeigen

Mich erschreckt dabei auch, dass utcconvert(utctime()) einen Ausgabestring erzeugt, der wieder dem Format im Handbuch entspricht, siehe die lokale Variable "test@". Den so erhaltenen String könnte man also nicht an utc() weitergeben.

Also ich hab das nunmal so getestet.
[highlight=epc]
z2=$2014-01-01 00:00:00$
z3=utc(z2)
z4=utcconvert(z3)
[/highlight]
Jetzt habe ich aber bemerkt, dass ich vorhin in einem falschen Dokument geschaut habe

, und das Handbuch stimmt.
Aber: Offenbar ignoriert die FW einfach die Trennzeichen, d.h. egal ob ":" oder "-" oder Leerzeichen, das Ergebnis ist dasselbe.
[highlight=epc]
z2=$2014-01-01 00:00:00$
z3=utc(z2)
z4=utcconvert(z3)
z5=$2014-01-01-00-00-00$
z6=utc(z5)
z7=utcconvert(z6)
[/highlight]
Hier ist z3 im Debugger gleich zu z6 und z7 wie z4:

Code:

% Wert von Objekt 265 (z7) abfragen:
% Typ: erweiterter Text
% Wert: 2014-01-01-00-00-00
% 
% Wert von Objekt 263 (z6) abfragen:
% /home/michi/Test/nconf -q 263 192.168.22.167
% Wert von Objekt 263: 00 00 01 43 4a e2 95 80 {2014-05-19 16:53:25}
% Typ: positive Ganzzahl
% Wert: 1388530800000
% 
% Wert von Objekt 261 (z5) abfragen:
% Typ: erweiterter Text
% Wert: 2014-01-01-00-00-00
% 
% Wert von Objekt 259 (z4) abfragen:
% Typ: erweiterter Text
% Wert: 2014-01-01-00-00-00
% 
% Wert von Objekt 257 (z3) abfragen:
% /home/michi/Test/nconf -q 257 192.168.22.167
% Wert von Objekt 257: 00 00 01 43 4a e2 95 80 {2014-05-19 16:53:25}
% Typ: positive Ganzzahl
% Wert: 1388530800000
% 
% Wert von Objekt 255 (z2) abfragen:
% Typ: erweiterter Text
% Wert: 2014-01-01 00:00:00

Damit sind wir wieder am Anfang und ich seh zumindest bei utc kein Problem.

**klaus_kraemer** · 19.05.2014, 16:23

Hallo Michi,

ich habe einfach Deinen Code - ohne ihn zu ändern - in mein Makro kopiert, Ergebnis:

[highlight=epc]
% Wert von Objekt 915 (z7) abfragen:
% Typ: erweiterter Text
% Wert: 1970-01-01-01-00-00
%
% Wert von Objekt 913 (z6) abfragen:
% D:/EIB_KNX/EibPC/EibstudioData/nconf -q 913 192.168.0.211
% Wert von Objekt 913: 00 00 00 00 00 00 00 00 {2014-05-19 17:09:28}
% Typ: positive Ganzzahl
% Wert: 0
%
% Wert von Objekt 911 (z5) abfragen:
% Typ: erweiterter Text
% Wert: 2014-01-01-00-00-00
%
% Wert von Objekt 909 (z4) abfragen:
% Typ: erweiterter Text
% Wert: 1970-01-01-01-00-00
%
% Wert von Objekt 907 (z3) abfragen:
% D:/EIB_KNX/EibPC/EibstudioData/nconf -q 907 192.168.0.211
% Wert von Objekt 907: 00 00 00 00 00 00 00 00 {2014-05-19 17:09:28}
% Typ: positive Ganzzahl
% Wert: 0
%
% Wert von Objekt 905 (z2) abfragen:
% Typ: erweiterter Text
% Wert: 2014-01-01 00:00:00
[/highlight]

Seltsam dabei ist, dass bei den Objekten z3 und z6 im Gegensatz zu Deinen Meldungen die "Null" steht...

Vielleicht liegts an der FW - ich mach' mal das Update auf Patch 3.010 und meld' mich nochmal.

**klaus_kraemer** · 19.05.2014, 16:36

Auch mit Patch 3.010 hat sich daran nichts geändert....

**klaus_kraemer** · 19.05.2014, 17:10

Neues...

So, ich habe jetzt Dein Codefragment aus meinem Makro rausgenommen und (wieder ohne Änderung) ins Hauptprogramm gestellt und siehe da, es gibt jetzt die richtigen Werte.

Allerdings darf es doch nicht sein, dass ein und derselbe Code in einem Makro nicht funktioniert, außerhalb jedoch schon

???

Es sieht so aus, als würde utc(string) innerhalb eines Makros (als Funktionsmakro) nicht funktionieren.

Ach ja, das Handbuch sollte vielleicht noch einen Hinweis darauf geben, dass utctime() die Sommerzeit nicht berücksichtigt! Es könnte den ein oder anderen Fehler vermeiden...

utcconvert(utctime()) müsste gemäß Definition eigentlich jetzt (Sommerzeit) um 2 Stunden hinter unserer Ortszeit herlaufen, das scheint nicht konsequent umgesetzt.

**enertegus** · 19.05.2014, 20:25

Zitat von klaus_kraemer Beitrag anzeigen

Allerdings darf es doch nicht sein, dass ein und derselbe Code in einem Makro nicht funktioniert, außerhalb jedoch schon

???

Dazu müsste man hier schon wissen, wie die Syntax des Aufrufs sein soll.

**klaus_kraemer** · 20.05.2014, 08:13

Bug bestätigt sich, jetzt seid Ihr mal wirklich am Zug...

...lieber Enertegus.

Für mich ist der Nachweis erbracht, dass utc() in Makros nicht funktioniert:

Ich habe extra ausschließlich mit Deinem Testcode von gestern gearbeitet.
Im Hauptprogramm ist er absolut unverändert abgelegt.
Im Makro habe ich die "z" der Variablennamen durch große "Z" ersetzt, ansonsten ist der Code identisch.

Das betreffende Codefragment im Hauptprogramm ist:
[highlight=epc]
//Testcode Enertegus
z2=$2014-01-01 00:00:00$
z3=utc(z2)
z4=utcconvert(z3)
z5=$2014-01-01-00-00-00$
z6=utc(z5)
z7=utcconvert(z6)
//Aufruf Makro mit Testcode Enertegus
hasEnertegusUTCMakroRun = AUS
if chtime(0,0,0) then {
hasEnertegusUTCMakroRun = EnertegusUTCMakro();
} endif
[/highlight]

Nun das einschlägige Makro aus der Makrodatei:
[highlight=epc]
//--------- EnertegusUTC
:begin EnertegusUTCMakro()
:var result@

// Nur kleines "z" in großes "Z" geändert
Z2=$2014-01-01 00:00:00$
Z3=utc(Z2)
Z4=utcconvert(Z3)
Z5=$2014-01-01-00-00-00$
Z6=utc(Z5)
Z7=utcconvert(Z6)
result@ = EIN
:return result@
:end
[/highlight]

Ich hab' der besseren Übersicht wegen einen Screenshot des Debuggers angehängt, trotzdem die Meldungen der Objektabfrage, auch wenn die nicht anderes zeigen:

[highlight=epc]
% Wert von Objekt 915 (z7) abfragen:
% Typ: erweiterter Text
% Wert: 2014-01-01-00-00-00
%
% Wert von Objekt 929 (Z7) abfragen:
% Typ: erweiterter Text
% Wert: 1970-01-01-01-00-00
%
% Wert von Objekt 913 (z6) abfragen:
% D:/EIB_KNX/EibPC/EibstudioData/nconf -q 913 192.168.0.211
% Wert von Objekt 913: 00 00 01 43 4a e2 95 80 {2014-05-20 08:59:34}
% Typ: positive Ganzzahl
% Wert: 1388530800000
%
% Wert von Objekt 927 (Z6) abfragen:
% D:/EIB_KNX/EibPC/EibstudioData/nconf -q 927 192.168.0.211
% Wert von Objekt 927: 00 00 00 00 00 00 00 00 {2014-05-20 08:59:34}
% Typ: positive Ganzzahl
% Wert: 0
%
% Wert von Objekt 911 (z5) abfragen:
% Typ: erweiterter Text
% Wert: 2014-01-01-00-00-00
%
% Wert von Objekt 925 (Z5) abfragen:
% Typ: erweiterter Text
% Wert: 2014-01-01-00-00-00
%
% Wert von Objekt 909 (z4) abfragen:
% Typ: erweiterter Text
% Wert: 2014-01-01-00-00-00
%
% Wert von Objekt 924 (Z4) abfragen:
% Typ: erweiterter Text
% Wert: 1970-01-01-01-00-00
%
% Wert von Objekt 907 (z3) abfragen:
% D:/EIB_KNX/EibPC/EibstudioData/nconf -q 907 192.168.0.211
% Wert von Objekt 907: 00 00 01 43 4a e2 95 80 {2014-05-20 08:59:35}
% Typ: positive Ganzzahl
% Wert: 1388530800000
%
% Wert von Objekt 922 (Z3) abfragen:
% D:/EIB_KNX/EibPC/EibstudioData/nconf -q 922 192.168.0.211
% Wert von Objekt 922: 00 00 00 00 00 00 00 00 {2014-05-20 08:59:35}
% Typ: positive Ganzzahl
% Wert: 0
%
% Wert von Objekt 905 (z2) abfragen:
% Typ: erweiterter Text
% Wert: 2014-01-01 00:00:00
%
% Wert von Objekt 920 (Z2) abfragen:
% Typ: erweiterter Text
% Wert: 2014-01-01 00:00:00
%
% Wert von Objekt 916 (hasEnertegusUTCMakroRun) abfragen:
% D:/EIB_KNX/EibPC/EibstudioData/nconf -q 916 192.168.0.211
% Wert von Objekt 916: 01 00 00 00 {2014-05-20 08:59:35}
% Typ: Binärwert
% Wert: EIN
[/highlight]

Für mich ist völlig klar, dass innerhalb eines Makros mit utc(string) etwas schief läuft.

Nach all dieser Vorarbeit als alphatestender Kunde, seid Ihr am Zug und ich hoffe, Ihr werdet das endlich in Gänze nachvollziehen - das wäre mit den gestrigen Infos auch gegangen. Ich hab' heute etwa 45 Minuten meines Urlaubs deswegen vergeudet - wieviele Stunden ich im Vorfeld schon den Fehler bei mir gesucht habe, kann ich nicht abschätzen, es kommen aber einige zusammen

!

Viel Erfolg und Gruß
Klaus

Angehängte Dateien

eibPcUTC.jpg (43,4 KB, 148x aufgerufen)

**klaus_kraemer** · 20.05.2014, 08:29

utctime() - Rückgabewert entspricht nicht UTC Definition

Und wenn Ihr an den UTC-Funktionen wohl eh schon schrauben müsst, dann liefert doch gleich UTC-Zeit nach ihrer wirklichen Definition:

Quelle: Wikipedia (ihr könnt aber auch bei der PTB nachsehen, s'wird auch nicht anders)

"Die koordinierte Weltzeit (englisch Coordinated Universal Time, französisch Temps universel coordonné), kurz UTC (englisch Universal Time, Coordinated), ist die heute gültige Weltzeit. Eingeführt wurde sie 1972. Aus einer Zeitangabe in UTC ergibt sich die entsprechende, in Deutschland, Österreich und anderen mitteleuropäischen Staaten geltende Mitteleuropäische Zeit (MEZ), indem man eine Stunde, und die im Sommer geltende Mitteleuropäische Sommerzeit (MESZ), indem man zwei Stunden addiert."

Also utctime() müsste sich von settime() aktuell um 2 Stunden unterscheiden - tut's aber nicht, denn utctime() liefert derzeit MESZ zurück.

**klaus_kraemer** · 22.05.2014, 08:08

Zwischenfrage

... konntet Ihr das widersprüchliche Verhalten HP<->Makro schon einmal nachvollziehen? Ich wunder' mich nur, weil Ihr (Fluch der guten Tat) sonst auch immer so schnell eine Rückkopplung gebt.

Danke und Gruß
Klaus

**enertegus** · 22.05.2014, 08:18

Zitat von klaus_kraemer Beitrag anzeigen

... konntet Ihr das widersprüchliche Verhalten HP<->Makro schon einmal nachvollziehen? Ich wunder' mich nur, weil Ihr (Fluch der guten Tat) sonst auch immer so schnell eine Rückkopplung gebt.

Nein sind noch nicht dazugekommen. Aber falls , wirst du es hier sicher erfahren

Ankündigung

Fehler bei utc(string)?

Fehler bei utc(string)?

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar