tbnobody / OpenDTU

Software for ESP32 to talk to Hoymiles/TSUN/Solenso Inverters
GNU General Public License v2.0
1.81k stars 507 forks source link

Eventlog - Anzeige neuer Events #104

Open ntfrnd opened 2 years ago

ntfrnd commented 2 years ago

Mir fällt auf, dass gelegentlich die Anzahl neuer Events wie folgt angezeigt werden:

eventlog1

Öffne ich dann die Eventlog-Ansicht sehe ich z.B. folgendes:

eventlog2

Allerdings bleibt die Anzahl am Eventlog-Icon selbst nach Schließen der Log-Ansicht weiterhin bestehen:

eventlog1

Ich hätte zwei Vorschläge:

Wobei ich die zweite Möglichkeit für überzogen halte, würde ich mir die erste wünschen. Ansonsten bleibt ewig die numerische Anzeige stehen und irgendwann beachtet man diese nicht mehr.

Oder steckt hinter dieser Anzeige eine andere Logik, die ich noch nicht erkannt habe. Dann wäre es schön, wenn man mir diese nennen könnte.

tbnobody commented 2 years ago

Das Eventlog wird 1zu1 aus dem Inverter ausgelesen. Habe hier keinerlei Einfluss darauf was angezeigt wird. Auch ein Bestätigen von Events ist aktuell noch nicht möglich da wohl niemand weiß wie.

ntfrnd commented 2 years ago

Ok, die Events prinzipiell sind ja gut. Mich stört nur die numerische Anzeige, wo sich die Anzahl immer wieder ändert, aber nie verschwindet. Das Icon mit der Anzahl wird doch auf der Weboberfläche befüllt, bzw. wo kommt die Anzahl her?

stefan123t commented 2 years ago

@tbnobody das Bestätigen kann mE mit dem MainCmd DevControl 0x51 SubCmd Type_CleanState_LockAndAlarm 0x14 erledigen bzw zurück setzen. Evtl wird dabei auch YieldDaily resettet. Hier der Link zum Discord von klahus1 https://discord.com/channels/984173303147155506/992022163307638887/1017502538267906129

stefan123t commented 2 years ago

Alternativ kann beim MainCmd 0x15 DevInfo mit SubCmd RealTimeRunData_Debug 0x0B auch die AlarmSerialNumber mitgeben, das sagt dem Wechselrichter welche AlarmId bereits der DTU bekannt ist. Die wurde anfangs gerne als 0x0005 übergeben solange die Bedeutung unbekannt war.

Siehe zB hier https://github.com/stefan123t/ahoy/wiki/FAQ-Frequently-Asked-Questions#realtimerundata_debug--0x0b

stefan123t commented 9 months ago

Die aktuelle Event ID (WarnSerNub) sollte wie in https://github.com/tbnobody/OpenDTU/issues/104 beschrieben auf DTU Seite in den RealTimeRunData_Debug und anderen Nachrichten angepaßt werden.

RealTimeRunData_Debug | 0x0B

7E 15 81101507 81101507 80 0B00 62D806FB 0000 259C 00000000 2C1A 56 7F
^^--------------------------------------------------------------------- SOF Start of Frame 0x7E
   ^^------------------------------------------------------------------ MainCmd 0x15 REQ_ARW_DAT_ALL
      ^^^^^^^^--------------------------------------------------------- WR Serial ID
               ^^^^^^^^------------------------------------------------ DTU Serial ID
               ^^^^^^^^--------------------- DTU Serial ID wird vom NRF24 überschrieben, da initial vom Treiber gesetzt
                        ^^--------------------------------------------- MultiFrameID 0x80 = SingleFrame
                           ^^------------------------------------------ SubCmd bzw. DataType: 0x0B = RealTimeRunData_Debug, 0x0C RealTimeRunData_Reality
                             ^^---------------------------------------- rev Protocol Revision ?
                           ^^^^---------------------------------------- Control Mode ? immer zwei Byte im Gen3 Protokoll
                                ^^^^^^^^------------------------------- UNIX timestamp 62BE1CE0 -> 2022-07-01 00:00:00
                                         ^^^^-------------------------- Gap always 0x0000
                                              ^^^^--------------------- 0x0000, nur bei AlarmData: WarnSerNub (Warning Serial Number)
                                                                         // User data: the latest alarm serial number received on the same day
                                                   ^^^^^^^^------------ Password always 0x00000000
                                                            ^^^^------- CRC16 / CRC-Modbus über die UserData, excl. Frame ID!
                                                            ^^^^------- CRC16 / CRC-Modbus über die Daten, nach und excl. Frame ID!
                                                                 ^^---- CRC8
                                                                    ^^- EOF End of Frame 0x7F

AlarmData | 0x11 / AlarmUpdate | 0x12

15 74403329 78563412 80 1100 62D80183 0000 0000 00000000 0765 FE --- AlarmData 0x11
15 74403329 78563412 80 1200 62D80183 0000 0000 00000000 FFC4 2A --- AlarmUpdate 0x12
^^------------------------------------------------------------------ MainCmd 0x15 REQ_ARW_DAT_ALL
   ^^^^^^^^--------------------------------------------------------- WR Serial ID
            ^^^^^^^^------------------------------------------------ DTU Serial ID
                     ^^--------------------------------------------- MultiFrameID 0x80
                        ^^------------------------------------------ SubCmd bzw. DataType: 0x11 = AlarmData, 0x12 AlarmUpdate
                          ^^---------------------------------------- rev Protocol Revision ?
                             ^^^^^^^^------------------------------- UNIX timestamp 62BE1CE0 -> 2022-07-01 00:00:00
                                      ^^^^-------------------------- Gap always 0x0000
                                           ^^^^--------------------- 0x0000, nur bei AlarmData: WarnSerNub (Warning Serial Number)  
                                                ^^^^^^^^------------ Password always 0x0000
                                                         ^^^^------- CRC16 / CRC-Modbus über die UserData, excl. Frame ID!
                                                              ^^---- CRC8

Mit einem Delta der WarnSerNub kann man prüfen ob es neue Event Einträge auf WR Seite gibt.

    if(DataType == AlarmData)
    {
        //        temp_dat[18] = (u8)((CurRealAlarmNum + 1) / 0xff);
        //        temp_dat[19] = (u8)((CurRealAlarmNum + 1) % 0xff);
        temp_dat[18] = (u8)((WarnSerNub[PortNO]) / 0xff);
        temp_dat[19] = (u8)((WarnSerNub[PortNO]) % 0xff);
    }
    else
    {
        memset((u8 *) & (temp_dat[18]), 0, 2);  // User data: the latest alarm serial number received on the same day
    }

Die alten Events sollte man ggf. mit CleanState_LockAndAlarm zurücksetzen

CleanState_LockAndAlarm | 0x14

7E 51 81101507 81101507 81 14 00 D000 02 7F Type_CleanState_LockAndAlarm 0x14
^^------------------------------------------ SOF Start of Frame 0x7E
   ^^--------------------------------------- MainCmd 0x51 DEVCONTROL_ALL
      ^^^^^^^^------------------------------ WR Serial ID
               ^^^^^^^^--------------------- DTU Serial ID wird vom NRF24 überschrieben, da initial vom Treiber gesetzt
                        ^^------------------ Single Frame ID
                           ^^--------------- SubCmd siehe oben
                           ^^^^^------------ Control Mode ? immer zwei Byte im Gen3 Protokoll
                                 ^^^^------- CRC16 / CRC-Modbus über die Daten, nach und excl. Frame ID!
                                      ^^---- CRC8
                                         ^^- EOF End of Frame 0x7F