search

lumapu / ahoy

Various tools, examples, and documentation for communicating with Hoymiles microinverters
https://ahoydtu.de
Other
951 stars 224 forks source link

Feature Request: 0.6.0 Power Limiting MI-Inverter #835

Open AsZork opened 1 year ago

AsZork commented 1 year ago

Bei der Verwendung von Powerlimit relative non persistent [%]

grafik

10:45:53 I: resetPayload: id: 0 10:45:53 I: (#0) Requesting Inv SN 106160906102 10:45:53 I: (#0) Devcontrol request 0xb power limit 100 10:45:53 I: sendControlPacket cmd: 0x0b 10:45:53 I: TX 19B Ch40 | 51 60 90 61 02 81 14 42 73 81 0b 00 03 e8 00 01 d0 40 96 10:45:53 I: RX 12B Ch61 | d1 60 90 61 02 60 90 61 02 81 0b 5b 10:45:53 0) Response from devcontrol request received

Sende ich die gleiche Abfrage innerhalb einer Abfrage Queue, unterbricht er die Queue sendet den richtigen Befehl ,und dann den anderen Befehl.

08:09:52 I: (#0) resetPayload 08:09:52 I: (#0) Requesting Inv SN 106160906102 08:09:52 I: (#0) prepareDevInformCmd 0x05 08:09:52 I: (#0) enqueCommand: 0x36 08:09:52 I: (#0) enqueCommand: 0x05 08:09:52 I: TX 27B Ch40 | 36 60 90 61 02 81 14 42 73 80 05 00 64 25 27 b0 00 00 00 00 00 00 00 00 30 e0 82 08:09:52 I: RX 27B Ch75 | b6 60 90 61 02 60 90 61 02 01 15 00 02 08 f7 13 87 00 3c 00 02 00 71 03 00 10 97 08:09:52 I: (#0) next request is 0x37 08:09:52 I: TX 27B Ch61 | 37 60 90 61 02 81 14 42 73 80 37 00 64 25 27 b0 00 00 00 00 00 00 00 00 c2 d3 70 08:09:52 I: (#0) retransmit power limit 08:09:52 I: sendControlPacket cmd: 0x0b 08:09:52 I: TX 15B Ch75 | 51 60 90 61 02 81 14 42 73 5a 5a 14 1f 3b 56 08:09:52 I: resetPayload: id: 0 08:09:52 I: (#0) Requesting Inv SN 106160906102 08:09:52 I: (#0) Devcontrol request 0xb power limit 20 08:09:52 I: sendControlPacket cmd: 0x0b 08:09:52 I: TX 19B Ch3 | 51 60 90 61 02 81 14 42 73 81 0b 00 00 c8 00 01 5e 41 3a 08:09:53 I: RX 12B Ch23 | d1 60 90 61 02 60 90 61 02 5a 5a d1 08:09:53 0) Response from devcontrol request received 08:09:53 I: (#0) has accepted power limit set point 20 with PowerLimitControl 1 08:09:53 I: clearCmdQueue 08:09:53 I: (#0) enqueCommand: 0x05 08:09:53 I: (#0) sth. missing: Request Retransmit 0x37 08:09:53 I: TX 27B Ch23 | 37 60 90 61 02 81 14 42 73 80 37 00 64 25 27 b0 00 00 00 00 00 00 00 00 c2 d3 70 08:09:53 I: RX 27B Ch40 | b7 60 90 61 02 60 90 61 02 01 15 00 02 08 f8 13 87 00 39 00 02 00 71 03 00 10 9c 08:09:53 I: (#0) next request is 0x38 08:09:53 I: TX 27B Ch40 | 38 60 90 61 02 81 14 42 73 80 38 00 64 25 27 b0 00 00 00 00 00 00 00 00 cd dc 70 08:09:53 I: RX 27B Ch61 | b8 60 90 61 02 60 90 61 02 01 14 00 02 08 f8 13 87 00 3a 00 02 00 71 03 00 0b 8a 08:09:53 I: (#0) sth. missing: Request Retransmit 0x39 08:09:53 I: TX 27B Ch61 | 39 60 90 61 02 81 14 42 73 80 39 00 64 25 27 b0 00 00 00 00 00 00 00 00 0c dc b1 08:09:53 I: (#0) sth. missing: Request Retransmit 0x39 08:09:53 I: TX 27B Ch75 | 39 60 90 61 02 81 14 42 73 80 39 00 64 25 27 b0 00 00 00 00 00 00 00 00 0c dc b1 08:09:54 I: RX 27B Ch40 | b9 60 90 61 02 60 90 61 02 01 14 00 02 08 f9 13 87 00 3b 00 02 00 71 03 00 0b 8b 08:09:54 I: (#0) got all msgs

oder 2. ter Test

10:50:59 I: (#0) sth. missing: Request Retransmit 0x39 10:50:59 I: TX 27B Ch40 | 39 60 90 61 02 81 14 42 73 80 39 00 64 25 4d 72 00 00 00 00 00 00 00 00 f7 b6 88 10:50:59 I: RX 27B Ch75 | b9 60 90 61 02 60 90 61 02 01 26 00 0c 08 e9 13 8c 01 54 00 46 00 c1 03 00 0b 36 10:50:59 I: (#0) got all msgs 10:51:00 I: resetPayload: id: 0 10:51:00 I: (#0) Requesting Inv SN 106160906102 10:51:00 I: (#0) Devcontrol request 0xb power limit 100 10:51:00 I: sendControlPacket cmd: 0x0b 10:51:00 I: TX 19B Ch61 | 51 60 90 61 02 81 14 42 73 81 0b 00 03 e8 00 01 d0 40 96 10:51:28 I: (#0) resetPayload 10:51:28 I: (#0) Requesting Inv SN 106160906102 10:51:28 I: (#0) Devcontrol request 0x0b power limit 100 10:51:28 I: sendControlPacket cmd: 0x0b 10:51:28 I: TX 15B Ch75 | 51 60 90 61 02 81 14 42 73 5a 5a 64 fb 3a c3 10:51:28 I: clearCmdQueue 10:51:28 I: (#0) enqueCommand: 0x05 10:51:28 I: RX 12B Ch3 | d1 60 90 61 02 60 90 61 02 5a 5a d1 10:51:28 0) Response from devcontrol request received 10:51:28 I: (#0) has accepted power limit set point 100 with PowerLimitControl 1 10:51:28 I: clearCmdQueue 10:51:28 I: (#0) enqueCommand: 0x05

Das Verhalten ist reproduzierbar. Man muss nur versuchen sobald die Queue startet, den Befehl zu senden.

beegee3 commented 1 year ago

die TX 19B ... sind 3rd Gen. Befehle. Die sollte es hier gar nicht geben. In dieser Art wird das nur von hmPayload erzeugt. 🤔 ... 💡 @lumapu @rejoe2 power limit ist ein HighPrio request, der in app.h ivSendHighPrio nur an mPayload (also hmPayload) geleitet wird. In app::loopStandard wird dieser durch mPayload.loop(); verarbeitet. Die loop trägt beim Inverter einen "power limit control request" ein und gibt zusätzlich den 3rd Gen. Befehl aus, s. 10:45:53 I: TX 19B .... Läuft gerade eine Abfrage Queue für den MI, so wird auf "power limit control request" reagiert, d.h. miPayload sendet seinen 2nd Gen. power limit Befehl, s. 08:09:52 I: TX 15B ... bzw. 10:51:28 I: TX 15B ... Keine Ahnung, warum im 1. Fall der 3rd Gen. Befehl beantwortet wird, in den beiden anderen Fällen aber nur der 2nd Gen. Befehl. @AsZork mich würde interessieren, ob in den beiden letzten Fällen das power limit funktioniert hat. Das RX ist ist nur die Quittung, dass der Befehl angekommen ist. Lange Erklärung, kurzer Vorschlag zur Fehlerbehebung: in app.h:

        void ivSendHighPrio(Inverter<> *iv) {
            if(mIVCommunicationOn) { // only send commands if communcation is enabled
                if (IV_HM == iv->ivGen)
                    mPayload.ivSendHighPrio(iv);
                else
                    mMiPayload.ivSendHighPrio(iv);
            }
        }
rejoe2 commented 1 year ago

Vielen lieben Dank euch beiden (AsZork hatte mich via discord auch an diese Stelle verwiesen).

Habe jetzt den aktuellen Stand der Dinge in https://github.com/rejoe2/ahoy/commit/88f5120fc0d2cd2b1f7c40ca56bc49c52af7e79d kosolidiert. Leider mag mein MI immer noch nicht limitieren, aber immerhin bekommt auch er jetzt "immer" die "kürzeren" Kommandos.

@AsZork:

rejoe2 commented 1 year ago

Ist hier zwar eteas OT, aber wegen des MQTT-Themas von @AsZork.

Du schreibst:

Bei der Suche warum ich keine MQTT-Werte bei dem MI-1200 nicht funktionieren, bin ich auf die Notify-funktion gestossen. Du musst vermutlich 2 Zeilen in app.c einbauen. mPayload.addPayloadListener(std::bind(&app::payloadEventListener, this, std::placeholders::_1)); mPayload.addAlarmListener(std::bind(&PubMqttType::alarmEventListener, &mMqtt, std::placeholders::_1, std::placeholders::_2, std::placeholders::_3)); genauer zusätlich die mMIPayLoad-zeilen.

Ich habe ehrlich gesagt noch nicht verstanden, wo genau das Problem liegt. Meine Vermutung wäre: Du bekommst gar keine Werte via MQTT gepublisht? Oder geht es um die Entgegennahme von Befehlen via MQTT?

Was mir grade dämmert: Kann es daran liegen, dass ich auch normale HM habe, dass bei mir alle Werte (auch vom MI) ankommen? @beegee3 : Dann gäbe es ggf. auch einen Sachzusammenhang mit #826 und es wäre klasse, wenn wir in dem Zusammenhang das ganze so umstellen könnten, dass jeweils nur der gerade aktualisierte Inverter via MQTT versendet wird?

beegee3 commented 1 year ago

@rejoe2 ich glaube, du hast Recht. Payload und Alarm Listener werden nur für die HM gesetzt, die EventListener der MI werden nicht gesetzt. Damit gibt es bei reinem MI Betrieb kein MQTT publish, bei gemischtem HM und MI Betrieb schon. da pubMQTT nicht zwischen HM und MI unterscheidet (warum auch?), wird bei @AsZork nichts, bei dir alles gepublished. Abhilfe (wie oben beschrieben): in app::setup() mMiPayload.addPayloadListener(std::bind(&app::payloadEventListener, this, std::placeholders::_1)); und mMiPayload.addAlarmListener(std::bind(&PubMqttType::alarmEventListener, &mMqtt, std::placeholders::_1, std::placeholders::_2, std::placeholders::_3)); an entsprechender Stelle einfügen. Vermute allerdings, dass im gemischten Betrieb dadurch doppeltes MQTT publish entsteht. Spricht auch dafür, jeweils nur den gerade aktualisierten Inverter via MQTT zu versenden. Mal sehen ob man das nicht mit dem Daten Timestamp regeln kann, d.h. nur publish, wenn aktueller ts vom vorherigen verschieden ist. Ein ähnliches Doppelmeldung-Problem könnte auch beim Display entstehen, was auch über app::payloadEventListener bedient wird. 🤔

rejoe2 commented 1 year ago

Die zwei zusätzlichen Zeilen sind jetzt in app.cpp drin. Auf die Schnelle habe ich aber zumindest keine Doppelpublishes gesehen, vermutlich deswegen, weil ja nur ein "Alarm" bzw. "listen" gemeldet wird, wenn sich was verändert hat (EDIT: bzw. eben aktuellere Daten reingekommen sind)?

Trotzdem wäre es super, wenn wir das andere Thema auch gelöst bekämen. Unnötig aktualisierte Daten sind imo eigentlich falsche Daten...

beegee3 commented 1 year ago

Vorschlag mit Timestamp s. hier

pade1984 commented 1 year ago

Hallo zusammen,

ich habe mit meinem MI-600 dasselbe Problem bei der Leistungsreduzierung. Der Befehl wird gesendet und auch bestätigt, aber eine Limitierung wird nicht umgesetzt (über Commands der AHOYDTU Oberfläche).

12:48:26 I: (#0) resetPayload 12:48:26 I: (#0) Requesting Inv SN 104161000897 12:48:26 I: (#0) Devcontrol request 0x0b power limit 15 12:48:26 I: sendControlPacket cmd: 0x0b 12:48:26 I: TX 15B Ch75 | 51 61 00 08 97 86 58 80 07 5a 5a 0f 14 7b 96 12:48:26 I: clearCmdQueue 12:48:26 I: (#0) enqueCommand: 0x05 12:48:26 I: RX 12B Ch23 | d1 61 00 08 97 61 00 08 97 5a 5a d1 12:48:26 0) Response from devcontrol request received 12:48:26 I: (#0) has accepted power limit set point 15 with PowerLimitControl 1 12:48:26 I: clearCmdQueue

Ich habe es über MQTT noch nicht versucht, da ich erst mal über die Oberfläche schauen möchte ob es funktioniert und dann im nächsten Schritt über MQTT gehen werde.

VG

Philipp

rejoe2 commented 1 year ago

Wie bereits hier geschrieben https://github.com/lumapu/ahoy/issues/796#issuecomment-1483882537 - vermutlich akzeptieren die "kleinen MI" keine Limitierungsanweisungen. Man bekommt zwar die Quittung, dass das Päckchen angekommen ist, aber umgesetzt wird es nicht.

Würde vorschlagen, dass wir mit den kleinen MI weitermachen, wenn es mit den 4ch-Geräten klappt.

Ansonsten kann ich dir (@pade1984) auch ein paar Schnippsel zuwerfen, mit denen ich bei Gelegenheit mal testen wollte, was der MI-600 überhaupt an Reaktion zeigt. Hatte nur heute nicht auch noch Lust auf's Dach zu steigen...

pade1984 commented 1 year ago

@rejoe2 gerne. Schick mal rüber. Ich werde vermutlich erst am Wochenende dazukommen, aber teste es gerne mal.

rejoe2 commented 1 year ago

@rejoe2 gerne. Schick mal rüber. Ich werde vermutlich erst am Wochenende dazukommen, aber teste es gerne mal.

Mit "Schnippsel" war kein fertiger Code gemeint, sondern eher ein paar Ideen, wie man weitermachen kann:

Was wie wirkt, und ob der Inverter z.B. auch was optisch (an der LED) zurückgibt, ob/wann er rebootet, usw. usf., wäre dann der Teil gewesen, den wir rausfinden wollen.

Eine Warnung noch am Rande: Ich hatte gestern mal versucht, einen MI-1500/3rd gen. auf "1%" zu limitieren. Vorgesehen sind ab 2%. Der war danach eine Zeitlang auf 0% Produktion und erst nach vielen Fehlversuchen wieder dazu zu bewegen, die Sonne auszunutzen...

Enjoy!

pade1984 commented 1 year ago

Da fehlt mir leider die Expertise, um das vernünftig zu testen :-(

dtuuser commented 1 year ago

Eine Warnung noch am Rande: Ich hatte gestern mal versucht, einen MI-1500/3rd gen. auf "1%" zu limitieren. Vorgesehen sind ab 2%. Der war danach eine Zeitlang auf 0% Produktion und erst nach vielen Fehlversuchen wieder dazu zu bewegen, die Sonne auszunutzen...

Mein HM600 läuft nur mit mindestens 2,8% =20W. Alles <20W lässt die Spannung von den Zellen auf über 50V ansteigen. Ich denke, dass die Eingangsspannung den WR irritiert und man aus dieser 0W Schleife schlecht raus kommt. Ich musste immer den WR vom Netz trennen.

beegee3 commented 1 year ago

hab's heute auch probiert: HM auf 2% limitiert -> prompt in der 0W Schleife gefangen, Zellen Spannung von 32V hoch auf 40V, musste auch den WR vom Netz trennen. Sollte man vielleicht in der Doku darauf hinweisen? Oder sogar im Programm ein Mindestlimit > 2% einbauen?

Etwas anderes: habe mir sowohl DTUSimMI, wie auch usart_nrf.c wegen der Limitierungskommandos angesehen. Beide kommen ohne CRC16 aus. Das prozentuale Limit ist genauso, wie in hmRadio.h programmiert.

Beim absoluten Limit wird aus diesem zunächst das prozentuale Limit berechnet. Das geschieht nach der Formel Limit*100/MAXPOWER DTUSimMI nutzt die Angaben zu den Inverterpanels um MAXPOWER zu bestimmen. usart_nrf.c rechnet MAXPOWER = 300 Anzahl Panels, wobei Anzahl Panels (1, 2 oder 4) aus dem Invertertyp abgeleitet wird. Im Kommando wird dann ein Byte mit dem prozentualen Limit geschrieben, gefolgt von zwei Bytes mit dem Wert 10absolutes Limit. Im Prinzip also absolutes Limit mit einer Nachkommastelle. Danach nur noch CRC8. Hab folgenden Vorschlag für die Umsetzung in Ahoy: MAXPOWER wie bei DTUSimMI rechnen. Dazu das Inverter Array powerLimit auf drei Einträge erweitern und in den dritten Eintrag den MAXPOWER Wert schreiben. Der ist die Summe der in den Settings eingegebenen Max Module Power Werte und kann im Setup oder vor dem ersten power limit request berechnet werden (letzteres hier im Vorschlag). Dazu die passende Erweiterung in hmRadio. Alles zusammen also:

in hmInverter.h:

class Inverter {
    public:
        ...
        uint16_t      powerLimit[3];     // limit power output
        ...

        Inverter() {
            ...
            powerLimit[0]      = 0xffff;               // 65535 W Limit -> unlimited
            powerLimit[1]      = AbsolutNonPersistent; // default power limit setting
            powerLimit[2]      = 0;                    // max. power (MI 2.Gen only)
            ...

in miPayload.h

        void ivSend(Inverter<> *iv, bool highPrio = false) {
            ...
                if (iv->powerLimit[2] == 0) { // calc inverter max. power
                    for (uint8_t i = 0; i < 4; i++) {
                        iv->powerLimit[2] += iv->config->chMaxPwr[i];
                    }
                }
                mSys->Radio.sendControlPacket(iv->radioId.u64, iv->devControlCmd, iv->powerLimit, false, false);
            ...

in hmRadio.h (habe das cnt++; vor die switch (cmd) Anweisung gezogen, dann kann man mit mTxBuf[cnt++] arbeiten)

        void sendControlPacket(uint64_t invId, uint8_t cmd, uint16_t *data, bool isRetransmit, bool isNoMI = true) {
            ...
            } else { //MI 2nd gen. specific
                cnt++;
                switch (cmd) {
                    case TurnOn:
                        //mTxBuf[0] = 0x50;
                        mTxBuf[9] = 0x55;
                        mTxBuf[10] = 0xaa;
                        break;
                    case TurnOff:
                        mTxBuf[9] = 0xaa;
                        mTxBuf[10] = 0x55;
                        break;
                    case ActivePowerContr:
                        mTxBuf[9] = 0x5a;
                        mTxBuf[10] = 0x5a;
                        if (data[1] == 0) {             // non persistent absolute
                            mTxBuf[cnt++] = (uint8_t)(data[0] * 100 / data[2]); // calc relative power limit (data[2] = max. power)
                            mTxBuf[cnt++] = ((data[0] * 10) >> 8) & 0xff;       // power limit
                            mTxBuf[cnt++] = ((data[0] * 10)     ) & 0xff;       // power limit
                        }
                        else if (data[1] == 1) {        // non persistent relative
                            mTxBuf[cnt++] = data[0];    // power limit in percent (0-100)
                        }
                        else
                            return;
                        break;
                    default:
                        return;
                }
            }
            sendPacket(invId, cnt, isRetransmit, isNoMI);
        }

Hat natürlich keine Fehlerabfangroutinen, wenn z.B. keine Max Module Power Werte eingetragen sind. Aber braucht man das? Unsinnige relative limits werden auch nicht abgefangen (z.B. 1000% kann man bei einem Byte gar nicht eintragen). Evtl. ist die Berechnung des prozentualen Limits aber auch nicht notwendig. Zumindest bei DTUSimMI steht der Kommentar "... doesn't matter what???" Zum Test könnte man sich auch den ersten Teil sparen (Erweiterung hmInverter.h und miPayload.h) und stattdessen in hmRadio.h einfach einen festen Wert für das prozentuale Limit eintragen:

                        ...
                        if (data[1] == 0) {             // non persistent absolute
                            mTxBuf[cnt++] = 0x32; // relative power limit doesn't matter; here set to 50%
                            mTxBuf[cnt++] = ((data[0] * 10) >> 8) & 0xff;       // power limit
                            mTxBuf[cnt++] = ((data[0] * 10)     ) & 0xff;       // power limit
                        }
                        ...
AsZork commented 1 year ago

Habe deine Anpassungen mal eingebaut. Leider funktioniert es bei mir nicht. Die aktuelle Wetterlage ist sehr instabil. Aber man kann an den z:Zt. Werten sehen das die Begrenzung nicht funktioniert.

Absolut non persistent 120 W

11:31:44 I: (#0) resetPayload 11:31:44 I: (#0) Requesting Inv SN 106160906102 11:31:44 I: (#0) Devcontrol request 0x0b power limit 120 11:31:44 I: sendControlPacket cmd: 0x0b 11:31:44 51 pid: 81 11:31:44 I: TX 15B Ch75 | 51 60 90 61 02 81 14 42 73 5a 5a 0a 04 b0 d8 11:31:44 I: clearCmdQueue 11:31:44 I: (#0) enqueCommand: 0x05 11:31:44 I: RX 12B Ch23 | d1 60 90 61 02 60 90 61 02 5a 5a d1 11:31:44 0) Response from devcontrol request received 11:31:44 I: (#0) has accepted power limit set point 120 with PowerLimitControl 0 11:31:44 I: clearCmdQueue 11:31:44 I: (#0) enqueCommand: 0x05

Absolut non persistent 120 W 11:32:24 I: (#0) resetPayload 11:32:24 I: (#0) Requesting Inv SN 106160906102 11:32:24 I: (#0) Devcontrol request 0x0b power limit 160 11:32:24 I: sendControlPacket cmd: 0x0b 11:32:24 51 pid: 81 11:32:24 I: TX 15B Ch3 | 51 60 90 61 02 81 14 42 73 5a 5a 0d 06 40 2d 11:32:24 I: clearCmdQueue 11:32:24 I: (#0) enqueCommand: 0x05 11:32:24 I: RX 12B Ch23 | d1 60 90 61 02 60 90 61 02 5a 5a d1 11:32:24 0) Response from devcontrol request received 11:32:24 I: (#0) has accepted power limit set point 160 with PowerLimitControl 0 11:32:24 I: clearCmdQueue 11:32:24 I: (#0) enqueCommand: 0x05

z.Zt 730 W z.Zt 182 W

100% 11:34:16 I: (#0) resetPayload 11:34:16 I: (#0) Requesting Inv SN 106160906102 11:34:16 I: (#0) Devcontrol request 0x0b power limit 100 11:34:16 I: sendControlPacket cmd: 0x0b 11:34:16 51 pid: 81 11:34:16 I: TX 13B Ch40 | 51 60 90 61 02 81 14 42 73 5a 5a 64 02 11:34:16 I: clearCmdQueue 11:34:16 I: (#0) enqueCommand: 0x05 11:34:16 I: RX 12B Ch75 | d1 60 90 61 02 60 90 61 02 5a 5a d1 11:34:16 0) Response from devcontrol request received 11:34:16 I: (#0) has accepted power limit set point 100 with PowerLimitControl 1 11:34:16 I: clearCmdQueue 11:34:16 I: (#0) enqueCommand: 0x05 z.Zt 182 W

12% 1:35:28 I: (#0) resetPayload 11:35:28 I: (#0) Requesting Inv SN 106160906102 11:35:28 I: (#0) Devcontrol request 0x0b power limit 12 11:35:28 I: sendControlPacket cmd: 0x0b 11:35:28 51 pid: 81 11:35:28 I: TX 13B Ch75 | 51 60 90 61 02 81 14 42 73 5a 5a 0c 6a 11:35:28 I: clearCmdQueue 11:35:28 I: (#0) enqueCommand: 0x05 11:35:28 I: RX 12B Ch3 | d1 60 90 61 02 60 90 61 02 5a 5a d1 11:35:28 0) Response from devcontrol request received 11:35:28 I: (#0) has accepted power limit set point 12 with PowerLimitControl 1 11:35:28 I: clearCmdQueue

z.Zt 812 W

beegee3 commented 1 year ago

Mist, die TX sind wie sie sein sollen und werden auch mit den passenden RX quittiert. @rejoe2 hat ja schon mal vermutet, dass die "kleinen" MI sich nicht limitieren lassen, aber deinen MI-1200 würde ich nicht dazu zählen. Seine andere Vermutung ist, dass auf Grund von DRM restrictions Limitierungen nicht möglich sind. Die DRED Anweisung für "Boot without DRM restrictions" ist ja schon im Code-Bereich case TurnOn vorbereitet. Die Zeile mTxBuf[0] = 0x50; für das DRED cmd ist z.Zt. nur auskommentiert. Meine aber, das hat bei @rejoe2 nichts gebracht. Auch weiß ich nicht, ob er schon die zweite vielversprechende DRED Anweisung "DRM8 unlimited power operation" ausprobiert hat. Auch dafür könnte man TurnOn testweise zweckentfremden:

                    case TurnOn:
                        mTxBuf[0] = 0x50; // = DRED cmd
                        mTxBuf[9] = 0x5a; // 0x5a55 = DRM8 unlimited power operation
                        mTxBuf[10] = 0x55;
                        break;

Vielleicht funktionierts danach mit den limits. Da ich keinen MI habe, kann ich nicht selber testen, nur (gut gemeinte) Vorschläge machen.

Und letztlich gibt es in usart_nrf noch ominöse Definitionen (inkl. Tippfehler), die sonst nirgendwo dokumentiert sind:

#define RE_FISRT__CONFIRM_SET_ENERGY        0x52
#define RE_FISRT_SET_ENERGY_SUB             0xa5                        //Set the power generation quantum command for the first time
#define RE_CONFIRM_SET_ENERGY_SUB           0x5a                        //Reset power generation quantum command
#define ANSWER_SET__CONFIRM_ENERGY          (RE_FISRT_SET_ENERGY_SUB | 0x80)

Im Code werden sie so benutzt (RE_CONFIRM_SET_ENERGY_SUB erfüllt dabei offensichtlich keinen Zweck):

            case NET_SET_ENERGY://Set the power generation capacity
            case NET_ELE_ENERGY:
                MainCmd = RE_FISRT__CONFIRM_SET_ENERGY;
                SubCmd = RE_CONFIRM_SET_ENERGY_SUB;
                SubCmd = RE_FISRT_SET_ENERGY_SUB;//
                break;
            ...
            UsartNrf_Send_PackBaseCommand((u8 *)MIMajor[PortNO].Property.Id, (u8 *)MIMajor[PortNO].Property.Id, MainCmd, (u8)SubCmd);

Keine Ahnung, ob man damit etwas anfangen oder auch kaputtmachen kann. Ist das irgendwo schon mal diskutiert worden? Wer sich traut (AUF EIGENES RISIKO), kann das ebenfalls mittels TurnOn testen:

                    case TurnOn:
                        mTxBuf[0] = 0x52; // = RE_FIRST_CONFIRM_SET_ENERGY cmd
                        mTxBuf[9] = 0xa5; // = RE_FIRST_SET_ENERGY_SUB
                        cnt = 10;
                        break;
rejoe2 commented 1 year ago

Hmm, mir wäre jedenfalls nicht bewußt, dass irgendwo mal die Voraussetzungen für die Limitierungen diskutiert worden wären.

Mein Kenntnisstand zum Thema Limitierung ist: