Open ntfrnd opened 2 years ago
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 0x7FAlarmData | 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!
^^---- CRC8Mit 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
Mir fällt auf, dass gelegentlich die Anzahl neuer Events wie folgt angezeigt werden:
Öffne ich dann die Eventlog-Ansicht sehe ich z.B. folgendes:
Allerdings bleibt die Anzahl am Eventlog-Icon selbst nach Schließen der Log-Ansicht weiterhin bestehen:
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.