dpt19 zeigt bei Set Fehler im eigenen State.

[JoeALLb]

Wenn ich mit diesem Device

Code: [Auswählen]

defmod knxZeit 0/0/252:dpt19:datetime:nosuffix
setstate knxZeit 2018-10-01 13:11:03 datetime 10.06.1900_01:45:11
ein

Code: [Auswählen]

set knxZeit datetime now absetze,
erscheint im eigenen Reading folgender Wert:

Code: [Auswählen]

inform on knxZeit
set knxZeit datetime now
fhem> KNX knxZeit  datetime: 10.06.1900_01:45:11
Die Uhrzeit stimmt, die Jahreszahl jedoch nicht.

Die ETS zeigt folgende Meldung an:

Code: [Auswählen]

5808,"01.10.2018Â 13:11:02,637",15.15.255,-,0/0/252,DatumZeit,GroupValueWrite,19.* Datum/Zeit,"76 0A 01 2D 0B 03 00 00 | Montag, 01.10.2018, 13:11:03 (---------) = (Fault: Normal (no fault), Working Day: Bank Holiday (No working day), No WD: WD field valid, No Year: Year field valid, No Date: Month and Day of Month fields valid, No Day of Week: Day of week field valid, No Time: Hour of day, Minutes and Seconds field valid, Standard Summer Time: Time = UT+X, Qualitiy of clock: clock without ext. sync signal)"
Die Uhrzeit scheint also am KNX-Bus korrekt anzukommen, jedoch falsch im Modul "decodert" zu werden.

Das Verbose5 dazu sieht so aus:

Code: [Auswählen]

2018.10.01 13:11:03 5: enter set knxZeit: hash: HASH(0x55b3d0ff4200), attributes: knxZeit, datetime, now
2018.10.01 13:11:03 5: set knxZeit: desired target is gad datetime, command: now, args:
2018.10.01 13:11:03 5: check value: now, gadName: datetime
2018.10.01 13:11:03 5: check value: now, gadName: datetime, model: dpt19, pattern: (?^i:(((3[01]|[0-2]?[0-9]).(1[0-2]|0?[0-9]).(19[0-9][0-9]|2[01][0-9][0-9]))_((2[0-4]|[0?1][0-9]):(60|[0?1-5]?[0-9]):(60|[0?1-5]?[0-9])))|(now))
2018.10.01 13:11:03 5: encode value: now, gadName: datetime
2018.10.01 13:11:03 5: encode model: dpt19, code: dpt19, value: now
2018.10.01 13:11:03 5: encode Datetime 1, 10, 118, 13, 11, 3
2018.10.01 13:11:03 5: encode model: dpt19, code: dpt19, value: now, numval: 0, hexval: 00760a012d0b030000
2018.10.01 13:11:03 5: set knxZeit: cmd: now, value: now, translated: 00760a012d0b030000
2018.10.01 13:11:03 5: decode value: 00760a012d0b030000, gadName: datetime
2018.10.01 13:11:03 5: decode model: dpt19, code: dpt19, value: 00760a012d0b030000
2018.10.01 13:11:03 5: decode Datetime 10, 6, 1900, 1, 45, 11
2018.10.01 13:11:03 5: decode model: dpt19, code: dpt19, value: 00760a012d0b030000, numval: 00760a012d0b030000, state: 10.06.1900_01:45:11
sG
Joe

[JoeALLb]

Nachtrag:
Wenn ich aber genau diesen Wert

Code: [Auswählen]

$76 $0A $01 $2D $0B $03 $00 $00  oder 118 010 001 045 011 003 000 000 als Dezimalper ETS auf FHEM schicke, wird das Reading korrekt aktualisiert!
Der Fehler sollte also innerhalb des Moduls passieren irgendwo zwischen dem senden des Wertes und dem Aktualisieren des Readings..

[JoeALLb]

Danke für das Update. Der "senden" Weg geht nun, jedoch das Empfangen nicht mehr.

Wenn ich per ETS "$76 $0A $08 $2F $1B $38 $00 $00" an FHEM schicke,

wird daraus das hier

Code: [Auswählen]

5: parse: process message, device-name: knx.time, rd-name: datetime, gadCode: 000fc, model: dpt19
 5: decode value: 760a082f1b380000, gadName: datetime
 5: decode model: dpt19, code: dpt19, value: 760a082f1b380000
 5: decode model: dpt19, code: dpt19, value: 760a082f1b380000, numval: 760a082f1b380000, state: 47.08.1910_27:56:00
 5: received hash (wpi): HASH(0x556af2a8bd28) name: knx.time, STATE: 47.08.1910_27:56:00, READING: datetime, SENDER: 011ff
,

anstatt
08.10.2018 15:30:39.


sG
Joe

[Andi291]

Abend!

Kriege ich bei mir nicht nachgestellt...in meinem Setup kommen DPT19 die von der ETS gesendet werden nicht oder nicht sauber über den KNXD drüber.
Mag ggf. an dem langen Telegramm liegen i.V.m. Multicast liegen - nen DPT mit 64 Bit kenne ich sonst nicht.

Davon abgesehen:
Decodiert wird richtig - bitte rechne nach...

76 --> 2018
0a --> Oktober
08 ..> 08.
2f --> 47 Stunden
1b --> 27 Minuten
38 --> 56 Sekunden

08.10.2018 15:30:39 entspricht 760A080F1E270000...

[JoeALLb]

Servus:
Wenn ich im Modul die Logzeile (Log3 ...) ergänze:

Code: [Auswählen]

  elsif ($code eq "dpt19")
        {
                $numval = $value;
                my $time = hex (substr ($numval, 8, 6));
                my $date = hex (substr ($numval, 2, 6));
                my $secs  = ($time & 0x3F) >> 0;
                my $mins  = ($time & 0x3F00) >> 8;
                my $hours = ($time & 0x1F0000) >> 16;
                #my $day   = ($date & 0x1F) >> 0;
                #my $month = ($date & 0x0F00) >> 8;
                #my $year  = ($date & 0xFFFF0000) >> 16;
                my $day   = ($date & 0xFF) >> 0;
                my $month = ($date & 0xFF00) >> 8;
                my $year  = ($date & 0xFF0000) >> 16;

                $year += 1900;
         Log3 ($name, 5, "decode date: $day, $month, $year, $hours, $mins, $secs");
                $state = sprintf("%02d.%02d.%04d_%02d:%02d:%02d", $day, $month, $year, $hours, $mins, $secs);
        }

Decodiert das Modul das Datum falsch. Es dekodiert eindeutig auf 1910. Encoden dagegen funktioniert korrekt.

Siehe das Verbose 5 Log.

Code: [Auswählen]

11:44:53 5: parse: process message, device-name: knx.time, rd-name: datetime, gadCode: 000fc, model: dpt19
11:44:53 5: decode value: 760a082f1b380000, gadName: datetime
11:44:53 5: decode model: dpt19, code: dpt19, value: 760a082f1b380000
11:44:53 5: decode date: 47, 8, 1910, 27, 56, 0
11:44:53 5: decode model: dpt19, code: dpt19, value: 760a082f1b380000, numval: 760a082f1b380000, state: 47.08.1910_27:56:00
Leider kenne ich mich mit dieser Hex-Codierung zuwenig aus...

sG
joe

[Andi291]

Welchen Wert möchtest Du denn senden?

[JoeALLb]

760A080F1E270000, also Zeile 3 im Log oben stimmt noch, erst Zeile 4 zeigt den Fehler.

[Soeren]

Hallo Zusammen,

bin in dasselbe Problem gelaufen.
Mein RasPi ist ein bissel schwach und ich wollte auf die Schnelle heute nicht die große Schleife über SVN fliegen.

Wäre schön, wenn andi291 das einpflegen könnte.
Anbei der korrigierte if-Zweig von dpt19, der bei mir läuft, getestet mit einem vom Bus kommenden Paket.

   elsif ($code eq "dpt19")
   {
      $numval = $value;
      my $time = hex (substr ($numval, 6, 6));
      my $date = hex (substr ($numval, 0, 6));
      my $secs  = ($time & 0x3F) >> 0;
      my $mins  = ($time & 0x3F00) >> 8;
      my $hours = ($time & 0x1F0000) >> 16;
      my $day   = ($date & 0x1F) >> 0;
      my $month = ($date & 0x0F00) >> 8;
      my $year  = ($date & 0xFF0000) >> 16;

      $year += 1900;
      $state = sprintf("%02d.%02d.%04d_%02d:%02d:%02d", $day, $month, $year, $hours, $mins, $secs);   
   }

Da sind noch ein paar Readings mehr möglich wie Wochentag, Sommerzeit usw., aber dazu muss ich noch ein wenig üben und dann doch SVN nehmen.
Aktuell sollte das das Problem erst mal beheben.

VG

[JoeALLb]

Wochentag, Sommerzeit wird von den wenigsten Aktoren unterstützt . daher hat es eigentlich keinen Mehrwert .

Der Rest sieht gut aus. Finde ich im Moment keinen Fehler. Plädiere daher für Aufnahme .

[Soeren]

So, jetzt habe ich endlich mal Zeit gehabt, mir das SVN anzusehen und zu schauen, was in der letzten Version geändert wurde.
Interessanterweise sieht mein Codeschnipsel aus wie der im vorletzten Release der 10_KNX.pm und andi291 hat den dann im Anschluss auf die aktuelle Version geändert, die auch bei mir das Paket nun falsch decodiert.

Das kann ich ja nun nicht einfach wieder zurückpatchen. Andi291, kannst Du bitte bestätigen, dass es bei Dir nach den Änderungen vom 7.10.18 jetzt immer noch richtig läuft? Wenn ja, dann scheint Dein Paketstring um 2 Byte gegenüber meinem verschoben zu sein. Würde mich interessieren, wo der Unterschied zwischen unseren Datenpaketen herkommt.

[NehCoy]

Hallo!

Ich kann ebenfalls bestätigen, dass dpt19 nicht mehr richtig dekodiert wird (siehe Anlage).
Deshalb habe ich meinen Weg auch hierher in diesen Beitrag gefunden ;-)

Viele Grüße
NehCoy

[JoeALLb]

So, jetzt habe ich endlich mal Zeit gehabt, mir das SVN anzusehen und zu schauen, was in der letzten Version geändert wurde.
Interessanterweise sieht mein Codeschnipsel aus wie der im vorletzten Release der 10_KNX.pm und andi291 hat den dann im Anschluss auf die aktuelle Version geändert, die auch bei mir das Paket nun falsch decodiert.

Das kann ich ja nun nicht einfach wieder zurückpatchen. Andi291, kannst Du bitte bestätigen, dass es bei Dir nach den Änderungen vom 7.10.18 jetzt immer noch richtig läuft? Wenn ja, dann scheint Dein Paketstring um 2 Byte gegenüber meinem verschoben zu sein. Würde mich interessieren, wo der Unterschied zwischen unseren Datenpaketen herkommt.

Servus ,

Kannst du vielleicht hier im Thread eine komplette Version des Moduls anhängen? Ich glaube, nicht jeder kann einzelne Zeilen im Modul direkt ändern... das wäre denke ich eine riesen Erleichterung und ein toller Service

[Soeren]

Das kann ich gern tun.

Anbei die Version, die bei mir läuft und den dpt19 wieder "richtig" darstellt.

Achtet drauf, daß Ihr dem File dann die Rechte und Usernamen zuweist, die die anderen PMs auch haben.

[Hauswart]

@Andi291 ist der Patch schon eingebaut? Bei mir ist dpt19 auch falsch dargestellt.


Edit: Ist noch nicht live. Willst du es vlt. implementieren?

[ext23]

Ich hab auch dasselbe Problem mit dem dpt19 und einem MDT SCN-IP000.03. Hat das noch niemand korrigiert?

/Daniel