MI Type Inverter request causes reboot

rejoe2 commented 1 year ago

Platform

ESP32

Assembly

I did the assebly by myself

nRF24L01+ Module

nRF24L01+ plus

Antenna

external antenna

Power Stabilization

Elko (~100uF)

Connection picture

[ ] I will attach/upload an Image of my wiring

Version

0.7.26

Github Hash

cbdb150

Build & Flash Method

VSCode - Platform IO (build & flash)

Setup

MQTT 6*MI-1500 (3rd Gen), 1 MI600

Debug Serial Log output

No response

Error description

Der MI ist der 7. eingetragene Inverter. Ändert man dessen Nummer auf 1141 (statt 1041), läuft die DTU durch, sonst ist die letzte im seriellen Monitor zu sehende Info, was der vorherige Inverter geantwortet hat (bzw. dessen Anfrage, falls unbeantwortet). Die DTU startet immer wieder neu, sobald der Inverter als MI konfiguriert ist und das erste Mal abgefragt wird.

lumapu commented 1 year ago

das hat bestimmt was mit der HMS Integration zu tun, ich prüfe mal verdächtige Stellen

Jonny13xx commented 1 year ago

Ich musste wieder auf 0.6.9 zurück... Habe ESP8266 und 1 x HM350 und 2 x MI300. Auch bei 0.7.28 reboot.

rejoe2 commented 1 year ago

Der Reboot hängt wohl mit dem Status-Handling der MI zusammen - scheint so, dass wir das endlich "richtig" klären müssen, wie das eigentlich geht...

Hier der betr. Auszug aus screen:

I: (#6) resetPayload
I: (#6) Requesting Inv SN 104160100013
I: (#6) enqueCommand: 0x09
I: (#6) enqueCommand: 0x05
I: (#6) prepareDevInformCmd 0x09
09 pid: 09
I: TX 11B Ch75 | 09 60 10 00 13 86 09 76 68 09 F2 
I: RX 16B Ch23 | 88 60 10 00 13 60 10 00 13 00 03 00 00 00 00 8B 
W: Status change for CH1 (1): Inverter start
Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x400da9d5  PS      : 0x00060430  A0      : 0x800de6b4  A1      : 0x3ffb2060  
A2      : 0x00000000  A3      : 0x3ffc49f0  A4      : 0x000000f0  A5      : 0x3ffc4a14  
A6      : 0x3ffcb53c  A7      : 0x00000001  A8      : 0x800da9c8  A9      : 0x3ffb2040  
A10     : 0x000003fc  A11     : 0x00000018  A12     : 0x3ffc4a14  A13     : 0x3ffcb53c  
A14     : 0x00ff0000  A15     : 0xff000000  SAR     : 0x00000012  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x000003fc  LBEG    : 0x4008a32d  LEND    : 0x4008a33d  LCOUNT  : 0xffffffff  

Backtrace: 0x400da9d2:0x3ffb2060 0x400de6b1:0x3ffb20a0 0x400e0ac5:0x3ffb20d0 0x400e939f:0x3ffb21d0 0x400e9635:0x3ffb2210 0x400d6bd6:0x3ffb2230 0x400ed38a:0x3ffb2250 0x400ed46a:0x3ffb2270 0x40105ce5:0x3ffb2290

Zur Klarstellung: Bei den MI kann man den "last error code" nicht gesondert abfragen, er ergibt sich mAn. direkt aus den 0x88 bzw. 0x92-Messages. Ergo weicht der Code an der Stelle deutlich ab bzw. ggf. wird hier dann auch das Ergebnis an eine unerwartete Stelle geschrieben?

rejoe2 commented 1 year ago

Habe - leider erfolglos - etwas im Code rumgestöbert, bin aber auf kein vernünftiges Ergebnis gekommen.

Ist etwas schwierig zu beschreiben, was da auf der seriellen Konsole so abläuft, hier eine Zusammenfassung:

Einzelne Nachrichten (egal, welcher Typ, ob Status, Produktionsdaten oder HW-Info etc.) scheinen nicht das Problem zu sein, und auch der Status wird eigentlich sauber in die Datenstruktur geschrieben. Kann es sein, dass der ESP aus dem Tritt kommt, sobald die 2. ("unerwartete") Message aus einem Datensatz kommt (also nach der 0x88 die 0x89 bzw. nach 0x92 die 0x91)? Sollte der "Nachrichtenpuffer" zwischendurch geleert werden?!? Ich konnte - soweit ich mich entsinne - sowohl 0x88-er Messages "solo" sehen, wie auch 0x89-er. Erst die Kombination von mehreren scheint (zuverlässig) den Crash zu verursachen

Jonny13xx commented 1 year ago

0.6.9 war ja brauchbar, auch wenn nicht alle Werte des MI beim Auslesen berücksichtigt wurden ! ;-) Auf dem Weg zur Version 0.7.26 muss da etwas Grundlegendes geändert worden sein...

rejoe2 commented 1 year ago

Status "fixed dev" paßt noch nicht.

Kann es sein, dass die Feld-Umbenennung bzw. die fehlende Berechnung des korrigierten Yield-Werts die Probleme verursacht?

rejoe2 commented 1 year ago

0.6.9 war ja brauchbar, auch wenn nicht alle Werte des MI beim Auslesen berücksichtigt wurden ! ;-) Auf dem Weg zur Version 0.7.26 muss da etwas Grundlegendes geändert worden sein...

Brauchbar schon, aber wir wollen ja nicht alle MI-User auf diesem Stand hängen lassen. Und auch an dieser Stelle der Hinweis: die MI liefern einfach nicht alle Daten, die man von 3rd gen. her erwartet... Der Teil wird also nicht mehr "besser"...

rejoe2 commented 1 year ago

OK, das Problem scheint. v.a. gewesen zu sein, dass für die MI keine Status-Felder mehr vorgesehen waren und daher dieser Aufruf gegen "die Wand" ging...

PR ist eingereicht.

rejoe2 commented 1 year ago

fixed dev stimmt nun! THX!

lumapu / ahoy