RTC mit Raspberrymatic/CCU synchronisieren

[jp112sdl]

Diese wird aber derzeit von der AskSin++ nicht beachtet. Vielleicht ist das ja die Nachricht, welche die CCU versendet, mit der aktuellen Zeit.

Ist es, denn das Flag wird beim AskSinAnalyzer ausgewertet um den Typ "TIMESTAMP" anzuzeigen.
SetInterfaceClock sendet auch immer ein BURST vorweg.

[papa]

Es wird aber bei der Nachrichtenverarbeitung nicht ausgewertet.
https://github.com/pa-pa/AskSinPP/blob/ ... ice.h#L215

[jp112sdl]

Es wird aber bei der Nachrichtenverarbeitung nicht ausgewertet.
https://github.com/pa-pa/AskSinPP/blob/ ... ice.h#L215

Ja, da (noch) nicht.

Müsste man mal versuchen, die 15 Byte Payload zu entschlüsseln:

Code: Alles auswählen

253693;10.08.2020 22:28:52;-77;4AB0F8;BidCoS-RF;000000;0000000000;15;61;TIMESTAMP;BCAST BURST RPTEN;0F 3D 94 3F 4A B0 F8 00 00 00 02 04 26 C4 6A 84;

[papa]

Hilft der FHEM Code hier ?

https://github.com/mhop/fhem-mirror/blo ... M.pm#L5869

[jp112sdl]

Wenn ich ihn verstehen würde, vielleicht
Hab grad mal fix ein paar Tests gemacht und ein bisschen an der Zeit gedreht

Code: Alles auswählen

ab 01.02.1970 00:00:02 innerhalb 2 Minuten hin und wieder gesendet:
0F D6 94 3F 2B E1 4D 00 00 00 02 02 C7 BB 8D 01;
0F 09 94 3F 2B E1 4D 00 00 00 02 02 C7 BB 8D 12;
0F 93 94 3F 2B E1 4D 00 00 00 02 02 C7 BB 8D 28;
0F 41 94 3F 2B E1 4D 00 00 00 02 02 C7 BB 8D 32;
0F 79 94 3F 2B E1 4D 00 00 00 02 02 C7 BB 8D 37;

05.01.1970 00:00:05
0F 6B 94 3F 2B E1 4D 00 00 00 02 02 C7 99 45 F8;

10.08.2020 23:05:26
0F E1 94 3F 2B E1 4D 00 00 00 02 04 26 C4 73 16;

Byte 1 = Länge (wie immer)
Byte 2 = Checksumme?
Byte 3 u. 4 =
Byte 5-7 = phys. Address des Senders (CCU)
Byte 8-10 = immer 00
Byte 11-16 = Datum/Uhrzeit

[jp112sdl]

Code: Alles auswählen

    my $s2000 = sprintf("%02X", CUL_HM_secSince2000());
    CUL_HM_PushCmdStack($hash,"++803F$id${dst}0202$s2000");
  

Hmm, Sekunden seit 2000 ?
Passt irgendwie... fast:

Code: Alles auswählen

10.08.2020 23:05:26
0F E1 94 3F 2B E1 4D 00 00 00 02 04 26 C4 73 16;

Differenz zwischen 01.01.2000 00:00 Uhr und 10.08.2020 23:05:26 sind laut https://www.calculator.net/time-duratio ... 6#twodates
26C3E676 - 26 C4 73 16 = 36000 (dec) macht 10 Stunden Differenz

Oder muss man 01.01.2000 12:00 Uhr nehmen... abzgl die 2h Zeitzone... dann passt das

[TomMajor]

wie wäre es so

Code: Alles auswählen

10.08.2020 23:05:26
0F E1 94 3F 2B E1 4D 00 00 00 02 04 26 C4 73 16;

10.08.2020 23:05:26 = 1597093526
https://time.is/de/Unix_time_converter

1597093526 - 946684800 = 650408726 (hex 26 C4 73 16)
Fertig.

946684800: # seconds between 01.01.2000, 00:00 and THE EPOCH (1970)
https://github.com/mhop/fhem-mirror/blo ... M.pm#L8769

nur im Perl das

Code: Alles auswählen

- 3600; # HM Special

macht für mich keinen Sinn, die Rechnung geht ohne das auf.

[jp112sdl]

Ich hab mich mal der populären TimeLib von PaulStoffregen bedient, die ich auch in anderen Projekten benutze.

Code: Alles auswählen

  virtual bool process(Message& msg) {
    if (getMasterID() == msg.from()) {
      if(msg.type() == AS_MESSAGE_TIMESTAMP) {
        if (msg.command() == AS_ACTION_SET) {
         DPRINTLN("Got TIMESTAMP Message");
         static const uint32_t sec2000 = 946684800;

         int8_t timezone = msg.buffer()[10] / 2;

         uint32_t tPayload =
            (((uint32_t)msg.buffer()[11]) << 24) +
            (((uint32_t)msg.buffer()[12]) << 16) +
            (((uint32_t)msg.buffer()[13]) << 8) +
            (((uint32_t)msg.buffer()[14]))       ;

         uint32_t unixtime = sec2000 + tPayload;

         setTime(unixtime);

         time_t t = now();
         DPRINT("UTC   Time is ");DDEC(day(t));DPRINT(".");DDEC(month(t));DPRINT(".");DDEC(year(t));DPRINT(" ");DDEC(hour(t));DPRINT(":");DDEC(minute(t));DPRINT(":");DDECLN(second(t));

         adjustTime(timezone * 3600);
         t = now();
         DPRINT("local Time is ");DDEC(day(t));DPRINT(".");DDEC(month(t));DPRINT(".");DDEC(year(t));DPRINT(" ");DDEC(hour(t));DPRINT(":");DDEC(minute(t));DPRINT(":");DDECLN(second(t));
        }
      }
    }

    return ChannelDevice::process(msg);
  }
  

Code: Alles auswählen

Got TIMESTAMP Message
UTC   Time is 11.8.2020 5:38:30
local Time is 11.8.2020 7:38:30

Die Prüfung auf negative Zeitverschiebung fehlt noch.
AST/ADT UTC-4/-3 wäre 3A als Zeitzone. Da ist sicher irgendein Bit als Negativkennzeichen? Da fehlt mir das Wissen, wie man von 3A ( auch geteilt durch 2?) auf -4 kommt...

[stan23]

Mal so mit den Bits gespielt:

Code: Alles auswählen

0x3A = 0b0011.1010

Wenn man statt 6 Bit nun 8 Bit betrachtet, muss man vorne mit den gleichen Bitwerten auffüllen:

Code: Alles auswählen

0x3A --> 0xFA = 0b1111.1010

cast to signed integer:

Code: Alles auswählen

(int8_t)0xFA = -6

Division durch 2 (warum eigentlich, sind da halbe Stunden möglich?):

Code: Alles auswählen

-6 / 2 = -3

Insgesamt vielleicht so:

Code: Alles auswählen

/* treat timezone as 6 bit signed integer */
int8_t timezone = msg.buffer()[10];
if ((uint8_t)timezone > 0x1F) {
  timezone = timezone | 0xC0;	/* fill up with sign bit */
}
timezone = timezone / 2;	/* timezone might be encoded in half hours */

Bei Zeile 3 bin ich mir nicht ganz sicher ob der Compiler das ohne den cast so versteht wie ich das meine. Ist eigentlich ein idealer Kandidat für einen kleinen Testcase

[jp112sdl]

Division durch 2 (warum eigentlich, sind da halbe Stunden möglich?):

Jap, sind möglich