Ahoy 0.5.70 Limit wird im seriellen Output als nicht akzeptiert angezeigt

[jimknopf63]

Platform

ESP32

Model name

No response

nRF24L01+ Module

nRF24L01+ plus

Antenna

circuit board

Power Stabilization

~100uF Elko

Connection diagram

Connection diagram I used:

nRF24L01+ Pin	ESP32 GPIO
Pin 1 GND [*]	GND
Pin 2 +3.3V	+3.3V
Pin 3 CE	GPIO4 CE D4
Pin 4 CSN	GPIO5 CS D5
Pin 5 SCK	GPIO18 SCLK D18
Pin 6 MOSI	GPIO23 MOSI D23
Pin 7 MISO	GPIO19 MISO D19
Pin 8 IRQ	GPIO0 IRQ D0

Note: [*] GND Pin 1 has a square mark on the nRF24L01+ module

Connection picture

• I will attach/upload an Image of my wiring

Version

0.5.70

Github Hash

d8e255d

Build & Flash Method

ESP Tools (flash)

Desktop

Mac OS

Setup

Device Host Name

- Device Name: AHOY-DTU

WiFi

- SSID: YOUR_WIFI_SSID *don't paste here*
- Password: YOUR_WIFI_PWD *don't paste here*

Inverter

Inverter 0

- Address: 1141752123456
- Name: HM-600
- Active Power Limit: 65535
- Active Power Limit Control Type: no powerlimit
- Max Module Power (Wp): 375, 375
- Module Name: link, rech

General

- Interval [s]: 30
- Max retries per Payload: 5

NTP Server

- NTP Server / IP: pool.ntp.org
- NTP Port: 123

MQTT

- Broker / Server IP: 
- Port: 1883
- Username (optional): 
- Password (optional): 
- Topic: inverter

System Config

Pinout (Wemos)

- CS: D8 (GPIO15)
- CE: D4 (GPIO2)
- IRQ: D3 (GPIO0)

Radio (NRF24L01+)

- Amplifier Power Level: LOW

Serial Console

- print inverter data: [x]
- Serial Debug: [x]
- Interval [s]: 5

• Reboot device after successful save: [x]
• SAVE

Debug Serial Log output

mac
08:B6:1F:28:97:00
sdk
v4.4.2
cpu_freq
240
heap_free
187012
sketch_used
978
version
0.5.70
wifi_rssi
-66
ts_uptime
240
esp_type
ESP32
heap_total
310112
chip_revision
3
chip_model
ESP32-D0WDQ5
chip_cores
2
Radio
nrf24l01+
is connected
Datarate
250 kbps
Power Level
LOW
RX success
40
RX fail
3
RX no answer
2
RX frames received
287
TX count
76
Sun
Sunrise
9.1.2023, 08:34:43
Sunset
9.1.2023, 16:47:54
Communication start
9.1.2023, 08:19:43
Communication stop
9.1.2023, 17:02:54
Night Communication
disabled

Error description

Wenn ich ein Leistungslimit setze, egal ob über Serielle Konsole oder MQTT wirft mir die serielle Konsole aus das das Limit nicht akzeptiert wird ändert aber das Limit trotzdem.

[stefan123t]

Danke fürs ausgefüllte Issue Template. Kannst Du noch ein Stück Logfile anhängen ich sehe den Fehler nicht oben ?

[jimknopf63]

Danke fürs ausgefüllte Issue Template. Kannst Du noch ein Stück Logfile anhängen ich sehe den Fehler nicht oben ?

[Ollipop030]

Habe genau das Gleiche beobachtet mit der 0.5.70. Bei mir mit drei verschiedenen Wechselrichtern, HM300, HM600 und HM1500.

[Ollipop030]

Nachtrag: Kann es sein, dass wenn der Wert bei "non persist" nicht angenommen wird, der Wert dann als "persist" übernommen wird? Ich habe gestern Nachmittag einen Wechselrichter testweise auf 50% "non persist" limitiert, heute morgen war er aber immer noch auf 50%.

[jimknopf63]

Nachtrag: Kann es sein, dass wenn der Wert bei "non persist" nicht angenommen wird, der Wert dann als "persist" übernommen wird? Ich habe gestern Nachmittag einen Wechselrichter testweise auf 50% "non persist" limitiert, heute morgen war er aber immer noch auf 50%.

Jetzt wo Du es schreibst, gut möglich. Ich habe vorgestern ein Script von raspihomegit getestet was damit endete das mein WR auf 0 Watt gesetzt wurde als es Dunkel wurde und gestern morgen stand er auch noch auf 0 und ich musste erst mal wieder einen Wert eintragen damit er produzierte. Obwohl fest 600 W eingestellt sind.

[sstidl]

War bei mir auch so. Hab da schon Panik geschoben weil ich ihn bei schönstem Wetter nicht mehr von 0W weggebracht habe.
Lösung war, dass ich ein submit vom leeren Feld geschickt habe, dann hat er nach ein paar Sekunden wieder produziert. Ich hab aber viel rumprobiert, vielleicht war es auch was anderes...

Schön wäre, wenn dazu jemand der es wirklich weiß etwas ins README oder Doku schrieben würde 😘

[jimknopf63]

Gleiches Verhalten auch schon bei Version 0.5.68

[lumapu]

ich werde in den Code schauen. Danke auch für die Version bei der erst zuerst beobachtet wurde, das macht die Suche leichter.
Ich hatte gehofft, dass nur die Ausgabe auf der Konsole falsch ist

[beegee3]

@lumapu

Ich hatte gehofft, dass nur die Ausgabe auf der Konsole falsch ist

Ist es wohl auch, zumindest wenn man payload.h der Versionen 0.5.66 (main) und 0.5.70 (development03) vergleicht:
v0.5.66

String msg = (p->packet[10] == 0x00 && p->packet[11] == 0x00) ? "" : "NOT ";
DPRINTLN(DBG_INFO, F("Inverter ") + String(iv->id) + F(" has ") + msg + F("accepted power limit set point ") + String(iv->powerLimit[0]) + F(" with PowerLimitControl ") + String(iv->powerLimit[1]));

v0.5.70

String msg = "";
if((p->packet[10] == 0x00) && (p->packet[11] == 0x00)) {
    msg = "NOT ";
    mApp->setMqttPowerLimitAck(iv);
}
DPRINTLN(DBG_INFO, F("Inverter ") + String(iv->id) + F(" has ") + msg + F("accepted power limit set point ") + String(iv->powerLimit[0]) + F(" with PowerLimitControl ") + String(iv->powerLimit[1]));

[beegee3]

P.S.: hab's noch nie geschafft, dass packet[10] und packet[11] etwas anderes als 0x00 liefern, egal wie unsinnig das Limit eingegeben wurde. Zeigt der Inverter vielleicht nur an, dass die Limit Anforderung angekommen ist und nicht, ob das Limit eingestellt wurde?

[lumapu]

Zeigt der Inverter vielleicht nur an, dass die Limit Anforderung angekommen ist und nicht, ob das Limit eingestellt wurde?

Ja genau, es ist ein Aknowledge. In die Queue wird dann gleich das zurücklesen des Limits hinzugefügt um den tatsächlichen Wert zu bekommen.

[lumapu]

@beegee3 Danke für den diff, das wird ein quick fix 👍😊