Feature Request: MQTT Erweiterung um Hersteller & Modell

[fila612]

aus #104 sind noch 3 Restthemen übrig geblieben, der besseren Übersichtlichkeit fasse ich die hier zusammen.

1. Für MQTT wäre der Hersteller und das Modell noch eine super Ergänzung. ich habe das bisher als Workaround bei mir so laufen, hier müssen 2 weitere Zeilen eingefügt werden:
   https://github.com/grindylow/ahoy/blob/ed4a99bf7feb9801af7cd02273a1da1a27fff732/tools/esp8266/app.cpp#L901-L903
   deviceDoc["mf"] = "Hoymiles";
deviceDoc["mdl"] = iv->name;
   Wobei man das Modell wohl anhand der SN automatisch ermitteln könnte, meine Variante zeigt im Grunde das Modell aus dem Feld im Setup :)

2. eine Änderung noch in der app.ccp, wie in MQTT HomeAssistant Autodiscover nicht durchgängig / Erweiterung um Info zu Hersteller, Modell möglich? #104 bereits beschrieben: https://github.com/grindylow/ahoy/blob/6dba1d757707426e1c8ff0c4d9d2ce5d22d6f26a/tools/esp8266/app.cpp#L924
   sollte mMqttInterval * 2 draus gemacht werden.

Ich könnte beide Änderungen als PR einsteuern, jedoch finde ich die Lösung von @KG3RK3N bzgl der Ermittlung des Modells anhand der SN ganz gut. Da stoße ich aber an meine Grenzen, falls jemand da einen Code-Schnipsel aus der Hüfte schießen kann, dann einfach hier rein kommentieren ich könnte das bauen und bei mir testen. Falls es gut geht baue ich den ganzen PR zusammen und stell das bereit.

[stefan123t]

Die offizielle Ermittlung des Inverter Modells erfolgt in UsartNrf_GetInvterType()

Für die von uns erstellte Liste mit Modell- / Seriennummern siehe hoymiles-format-description.md

Aktuell gibt es nur diese Implementierung / Unterscheidung der HM-Wechselrichter in hmSystem.h:
https://github.com/grindylow/ahoy/blob/0347a3df44d77952524666794c888e6ef4693e45/tools/esp8266/hmSystem.h#L47-L54

Daniel M. hatte bereits in https://www.mikrocontroller.net/topic/525778#7106192 vorgeschlagen dies wie folgt zu erweitern:

if(p->serial.b[5] == 0x11) {
                switch(p->serial.b[4]) {
                    case 0x21: p->type = INV_TYPE_1CH; break;
                    case 0x41: p->type = INV_TYPE_2CH; DPRINTLN(DBG_INFO, F("HM 2 Channel")); break;
                    case 0x61: p->type = INV_TYPE_4CH; break;
                    default: DPRINTLN(DBG_ERROR, F("unknown inverter type: 11") + String(p->serial.b[4], HEX)); break;
                }
            }
            else if(p->serial.b[5] == 0x10) {
                switch(p->serial.b[4]) {
                    case 0x21: p->type = MI_INV_TYPE_1CH; break;
                    case 0x41: p->type = MI_INV_TYPE_2CH; DPRINTLN(DBG_INFO, F("MI 2 Channel")); break;
                    case 0x61: p->type = MI_INV_TYPE_4CH; break;
                    default: DPRINTLN(DBG_ERROR, F("unknown inverter type: 10") + String(p->serial.b[4], HEX)); break;
                }
            }
            else
                DPRINTLN(DBG_ERROR, F("inverter type can't be detected!"));

Man kann auch noch die weiteren MainCmd = REQ_ARW_DAT_ALL; // 0x15 Device Information Kommandos implementieren.

Die SubCmds sind laut UsartNrf3_Process_DevInform() und DataType in usart_nrf3.c/.h:

        SubCmd = InverterDevInform_Simple; // 0x00
        SubCmd = InverterDevInform_All; // 0x01
        SubCmd = GridOnProFilePara; // 0x02
        SubCmd = HardWareConfig; // 0x03
        SubCmd = SimpleCalibrationPara; // 0x04
        SubCmd = SystemConfigPara; // 0x05
        SubCmd = RealTimeRunData_Reality; // 0x0c
        SubCmd = RealTimeRunData_Debug; // 0x0b
        SubCmd = RealTimeRunData_A_Phase; // 0x0d
        SubCmd = RealTimeRunData_B_Phase; // 0x0e
        SubCmd = RealTimeRunData_C_Phase; // 0x0f
        SubCmd = AlarmData; // 0x11
        SubCmd = AlarmUpdate; // 0x12
        SubCmd = RecordData; // 0x13
        SubCmd = InternalData; // 0x14
        SubCmd = GetLossRate; // 0x15
        SubCmd = GetSelfCheckState; // 0x1e
        SubCmd = InitDataState; // 0xff

Die entsprechenden UsartNrf3_Process_DevInform_*() Methoden beschreiben die in den Antworten enthaltenen Daten.
z.B. in UsartNrf3_Process_DevInform_All:

            MIDetail.Property.AppFWBuild_VER = (u16)(((u16)pProBuffer[0] << 8)  | pProBuffer[1]); //Application firmware version
            MIDetail.Property.AppFWBuild_YYYY = (u16)(((u16)pProBuffer[2] << 8)  | pProBuffer[3]); //Application firmware compilation time-year
            MIDetail.Property.AppFWBuild_MMDD = (u16)(((u16)pProBuffer[4] << 8)  | pProBuffer[5]); //Application firmware compilation time-month. day
            MIDetail.Property.AppFWBuild_HHMM = (u16)(((u16)pProBuffer[6] << 8)  | pProBuffer[7]); // Application version
            MIDetail.Property.USFWBuild_VER = (u16)(((u16)pProBuffer[8] << 8)  | pProBuffer[9]); // Hardware part number
            MIDetail.Property.HW_PNH = (u16)(((u16)pProBuffer[10] << 8)  | pProBuffer[11]); // Hardware part number
            MIDetail.Property.AppFW_PNL = (u16)(((u16)pProBuffer[12] << 8)  | pProBuffer[13]); // Hardware part number
            MIDetail.Property.AppFW_PNL = (u16)(((u16)pProBuffer[14] << 8)  | pProBuffer[15]); // Hardware part number
            MIDetail.Property.HWSPECVER = (u16)(((u16)pProBuffer[16] << 8)  | pProBuffer[17]); // Hardware version
            MIDetail.Property.GPFCode = (u16)(((u16)pProBuffer[18] << 8)  | pProBuffer[19]); // Grid-connected protection file code
            MIDetail.Property.GPFVer = (u16)(((u16)pProBuffer[20] << 8)  | pProBuffer[21]); // Grid-connected protection file version

[KG3RK3N]

@fila612 Ich hatte mich auch mal ein wenig im Nachgang mit der Liste der Seriennummern beschäftigt und das ermitteln des Models. Anhand der Seriennummern selbst scheint es wohl nicht möglich zu sein das exakte Model zu ermitteln, konnte zumindest keine Eindeutige Nummer finden welche das exakte Model definiert.

@stefan123t Auf teile davon bin ich auch gestoßen, ich denke die Implementierung der Commands dürfte der richtige Weg sein um an die entsprechenden Informationen zu kommen.

Sollte sich keiner finden, würde ich das ganze mal probieren, auch wenn ich denke das ich da an meine Grenzen kommen werde. Allerdings dann vermutlich eher im Urlaub in 2 Wochen 😄
Wobei ich mich zu aller erst mal mit dem Thema Stabilität beschäftigen will, da ich meinen inzwischen alle <12 Stunden manuell neu starte weil die MQTT Verbindung sich oftmals nicht reconnected. Vorausgesetzt bis dahin ist nicht schon eine neue Version verfügbar welche die Stabilität verbessert.

[stefan123t]

Wir haben auch noch einige Firmware und Hardware Versions strings in InverterDevInform_Simple und InverterDevInform_All gefunden, eventuell ist das eigentlich ein Unterthema von #145 ?

[fila612]

Hi @stefan123t,

ja, das könnte man in einer Abfrage der Daten aus dem WR sicher mit unter diesem Punkt fassen.
Ich finde es auch nicht dringend.
Da es ja nur zwei Werte sind, wovon der Hersteller vermutlich ja mal static sein sollte, könnte man ja bis zu Umsetzung der "schönen" und automatischen Lösung auch die manuelle implementieren.
Sollte eigentlich niemanden stören, wer das Modell sauber in HomeAssistant haben möchte müsste dann eben WR-Namen im Setup entsprechend pflegen.
Ich habe als Vorschlag mal eine PR #153 erstellt, wenn in Ordnung kann dieser ja erstmal gemerged werden. Dann würde ich den Issue hier schließen