Closed tobi0171 closed 3 months ago
Solarteur
commented
4 months ago Ich kann die Anmerkungen von tobi0171 bei vergleichbarer Konfiguration der PV-Anlage (2x HM-600, einer davon wird über DPL geregelt, keine Batterie), weitgehend bestätigen (Firmware 2024.01.26), in einem Punkt aber nicht:
Unter "DTU-Einstellungen" --> "NRF24 Sendeleistung" kann ich vier Stufen für die Sendeleistung auswählen.
tobi0171
commented
4 months ago Firmwareversion / git Hash | 2024.01.26 Konfigurationsversion | 0.1.27
schlimmchen
commented
4 months ago Auf welches Problem soll denn in diesem Issue eingegangen werden? Es sind ja mindestens zwei schon angesprochen, gefühlt eher fünf.
tobi0171
commented
4 months ago Hallo @schlimmchen. Danke für die Antwort und Erklärung. Sorry, ich hab mich etwas schwer getan hier einen Eintrag an passender Stelle zu platzieren/finden, "Bug" ist vermutlich auch nicht ganz korrekt. Ich bin noch recht ungeübt im Thema Github. Der Punkt darf gerne an die passende Stelle verschoben werden.
Hauptproblem ist das der DPL scheinbar den Wechselrichter komplett abschaltet... ca 2-4 Minuten lang und er sich manchmal schwer tut von selbst wieder seine Arbeit aufzunehmen.
DPL hatte eigenlich zu dem Zeitpunkt der Abschaltung nichts groß zu regeln (Auslastung permanent 1800-3000W Bautrocknung) und wäre WR Seitig nicht mal an die benötigte Leistung gekommen... eher "Volllast" statt Abschaltung. Der Fehkler tritt meistens nur bei hoher Sonneneinstrahlung zwischen 10-15 Uhr auf... Ich versuch es mal zu loggen.
JA, es ist nur das NRF montiert. Sobald ich auf speichern klicke kommt die Meldung. Ich hab schon mehrere DTUs in verscheidenen Varianten gebaut und getestet (Interesse & Neugier an dem Thema) ... diese Meldung hatte ich bislang noch nie gesehen... daher die Frage zum möglichen Ursprung. Bei den anderen (Fusion use... hatte ich die Meldung auch noch nie)... diesmal wurde ein ESP32-S (der schmale) eingesetzt, den ich bislang noch nie verwendet hatte. Das PCB ist ein Prototyp aus dem AkkuDr Forum...der mit einem aufgesteckten ESP32-S betrieben wird.... Liegt es ggf u.A am PinMap oder am Model?
Time Calibration .... ich hab mal eine Tag den "pool.ntp.org" im 5 sek Takt angepingt, dort gab es mehrere Fehler... kann das ggf die Ursache oder ein Ansatz sein? Ja, die Time Calibration hat scheinbar keinen weiteren Einfluss.
Danke für den Hinweis.... das Teste ich mal aus. (die Verwendeten Antenne aus dem Beitrag #392 habe ich nun auch verbaut.
schlimmchen
commented
4 months ago Zu 2. schau bitte einmal hier: https://github.com/tbnobody/OpenDTU/issues/1707 Hast du das Web-Interface neu geladen mit Strg+F5?
tobi0171
commented
4 months ago Danke.
Zu 1. DPL - konnte ich bislang mangels fehlender PV Leistung keine Auswertung machen, da der Fehler heute nicht aufgetreten ist, bzw nur einmal, jedoch scheinbar ohne längere Auswirkung.
(Was ich jedoch gestern vorgenommen und heute getestet habe, sind die Zeiten zu ändern. (Eigentlich ggf. nun sehr sportlich eingestellt) Wechselrichter "Erreichbarkeit Schwellwert" von 3 auf 4, DTU-Abfrageintrvall von 5 auf 4, Power-Meter>Timeout von 1000 auf 500 ms.
NPT..Ping... heute wenige Fehler.
Zu 2. Strg+F5 hab ich gerade versucht. Meldung kommt beim Klick auf speichern, leider noch immer. Neustart und Stromlos schalten der DTU hatte ebenfalls keinen Erfolg.
Ich habe aber auch die beiden unteren Schieberegler, wie in tbnobody#1707 abgebildet. nicht. Bei mir endet die Einstellmöglichkeiten unter der NRF24 Sendeleistung (wie oben im Bild). Es ist auch nur ein NRF Modul konfiguriert. Die beiden Balken zum einstellen der Frequenz bekomme ich nicht angezeigt.
schlimmchen
commented
4 months ago Hast du https://github.com/helgeerbe/OpenDTU-OnBattery/releases/tag/2024.01.26 installiert und Strg+F5 verwendet? Kann mir nicht so recht vorstellen, dass dein Problem ein anderes sein soll als in tbnobody#1707. Also ich kann es nicht reproduzieren. Ein generic_esp32 mit NRF modul aber ohne CMT modul, ich kann die Einstellungen problemlos speichern.
War an deinem Gerät einmal ein CMT Modul konfiguriert und du hast Einstellungen dazu gespeichert?
tobi0171
commented
4 months ago Zu 2. Ohh... Danke, das ist ggf ein Ansatz. Ich hatte tatsächlich mal vor einiger Zeit das blinky-CMT2300-Modul-auf-NRF-Adapter-Modul mit angepasster Pinmap vergeblich versucht, jedoch wieder verworfen und die "alte" Pinmap wieder aufgespielt.
Falls ich hier nicht noch etwas zur Fehlersuche auslesen sollte, würde ich den ESP morgen mal ausbauen und komplett neu aufsetzen, um wirklich alles zu eliminieren und bei 0 zu starten.
Joe6899
commented
4 months ago I also see the same issues in the DTU settings when using NRF24 module. I cannot change attenuation setting because of CMT frequency error message - no CMT in use.
schlimmchen
commented
4 months ago @Joe6899 Have you tried refreshing the browser cache by using Ctrl+F5 on your keyboard while browsing the OpenDTU web application?
tobi0171
commented
4 months ago Zu 2 - NRF Meldung
DTU auf ESP32-S neu aufgesetzt "Factory-bin". Ohne angeschlossen Komponente und Pinmap logischerweise nichts aufrufbar bei den NRF Einstellungen.
Nach wiederherstellen der Pinmap und config... gleiches Verhalten wieder.
Benutze aber ein angepasste pinmap wie folgt (Prototyp-PCB) ... hab ich hier einen Fehler eingebaut, den ich selbst nicht sehe, der das NRF-Verhalten ggf auslöst ?
{ "name": "DTUonBattery Test", "nrf24": { "miso": 19, "mosi": 23, "clk": 18, "irq": 16, "en": 4, "cs": 5 }, "victron": { "rx": 22, "tx": -1 }, "battery": { "rx": 27, "rxen": 33, "tx": 14, "txen": 32 }, "led": { "led0": 17, "led1": 1 }, "eth": { "enabled": false, "phy_addr": -1, "power": -1, "mdc": -1, "mdio": -1, "type": -1, "clk_mode": -1 }, "huawei": { "miso": 12, "mosi": 13, "clk": 26, "irq": 25, "power": 21, "cs": 15 } } ]
Falls mehr Infos zur Ursachenforschung benötigt werden, bitte Bescheid geben.
schlimmchen
commented
4 months ago Naja, in der config stecken ja auch Einstellungen fürs CMT drin, die ggf. das Problem verursachen. Lösch dir mal aus deiner config.json und spiel diese config.json dann wieder ein. Außerdem solltest du esptool ... flash_erase nutzen, um wirklich sicher zu sein, dass keine Einstellungen oder Daten noch im Flash sind, wenn der ESP32 mit der neuen Firmware startet.
Joe6899
commented
4 months ago yes I tried refreshing the browser on the DTU settings page
isn't #1725 related to this problem - i.e fixed at next build ?
DaBaBW
commented
4 months ago Ich kann Problem Nr. 1 voll bestätigen. Wollte gerade deswegen selbst eine Anfrage stellen. Ich verwende die DTU erst seit 2 Wochen, kann also nicht sagen ob es vorher anders war. Aber der DPL ist für mich nicht benutzbar. Der WR wird manchmal nur 2-3x am Tag, dann aber auch wieder alle paar Minuten abgeschaltet mit der Meldung "124 durch Fernsteuerung ausgeschaltet" Bei mir ein HMS-1600 mit 4 PV-Modulen, also keine Batterie.
Edit: Ich habe gerade gelernt dass das "untere Leistungslimit" nicht das ist was er immer produzieren soll sondern mehr eine Einschaltschwelle. Somit könnte manches Abschalten gewollt sein wenn keine Leistung benötigt wird (2. PV vorhanden). Es ist aber tatsächlich so dass der WR nach Abschalten auch öfter mal aus bleibt auch wenn gerade volle Leistung benötigt wird.
schlimmchen
commented
4 months ago Hm, @DaBaBW du hast auch einen HMS inverter, wie in #651. Kannst du einen Auszug aus der Konsolen-Log teilen, wo der Inverter von "produziert" auf "produziert nicht" umspringt? Ich frag mich, ob wirklich der DPL den Inverter ausschaltet und dann durcheinander kommt, oder ob der Inverter aus irgendeinem anderen Grund abschaltet.
tobi0171
commented
4 months ago @schlimmchen > zu 1. "DPL" > ich bin noch einen Konsolen log schuldig... leider ist der Fehler 124 bislang nich nochmal aufgetreten. Er kam jedoch nur zustande bei höherer Leistung/Sonneneinstrahlung. Sobald das Wetter mitspielt und der Fehler wieder auftaucht ... Versuch ich einen log zu erstellen.
Zu den restlichen aufgeführten Punkten 2,3,4... ✔️
Ich hab meine Zeiten wie oben bereits genannt etwas optimiert und Anpassungen vorgenommen. Ebenfalls die Entfernungen der Komponente zueinander optimiert entsprechend den Vorschlägen (danke) und ein anderes NRF verwendet.
Time Calibration - trat nicht mehr auf.✔️
Skurrile NRF-Meldung > lag vermutlich am selbst zerschossenen Pinmap (selbstverschuldet)✔️
(Zum flashen nutze ich immer das ESP tool inkl "Erase" vor dem flashen)
DaBaBW
commented
4 months ago @schlimmchen Wollte gerade ein paar Logs zum Abschaltzeitpunkt posten, aber immer ca. eine halbe Minute bevor die Meldung in der Ereignisanzeige kommt stoppt die Ausgabe im Log. Ich muss dann die Seite aktualisieren damit es weiter geht. Ok, war vorher wohl Zufall dass es immer kurz vor dem Abschalten war. Aber der Log stürzt immer in unregelmäßigen Abständen ab so dass ich nie den Zeitpunkt erwische an dem die Abschaltung stattfand.
schlimmchen
commented
4 months ago Hast du "ausführliche Protokollierung" schon ausgeschaltet bei allem außer dem DPL? Damit das Log nicht zu schnell zu groß wird.
Was besser wäre: Einen Rechner an den ESP hängen und dann die serielle Ausgabe direkt mitschreiben. Möglicherweise geht das aber nicht, dafür muss ja erstmal ein Rechner oder Raspi oder sowas zur Verfügung stehen dort, wo der ESP installiert ist...
DaBaBW
commented
4 months ago Habe eine schwierige Situation. Die PV ist bei meiner Mutter. Ich greife über ein VPN drauf zu. Und jetzt unter der Woche arbeite ich zu der Zeit wenn produziert wird. Mir ist nur heute aufgefallen dass es evtl. an fehlenden Werten vom Stromzähler liegt und er deshalb abschaltet. Momentan greife ich per HTTP auf einen ESP mit Tasmota zu. Evtl. gefällt dem die Häufigkeit des Abrufes nicht. Heute ist er schon seit einer Stunde nicht erreichbar. Schön wäre für solche Situationen ein einstellbarer Fallback-Wert und eine einstellbare Zeit wie alt ein Wert sein darf. Dann eben dauerhaft auf einen fixen Wert begrenzen.
spcqike
commented
4 months ago An tasmota an sich wird es nicht liegen. Ich frage meinen esp teils sekündlich ab und es läuft ohne Auffälligkeiten.
Eventuell haben deine esp schlechtes wlan und die Anfragen laufen ins timeout?
der Vorschlag mit einem festen fallback gab es bereits. Fänd ich auch nicht verkehrt. Im Moment sind es feste 30s. Das sollte eigentlich aber auch ausreichen.
DaBaBW
commented
4 months ago Ja die WLAN Verbindung ist nicht die Beste, aber ich habe über MQTT keine Probleme alle 10 Sekunden Werte zu bekommen. Jetzt seitdem die DTU läuft habe ich eben schon 3x beobachtet wie der ganze ESP am Stromzähler für eine Weile tot ist. Macht dann irgendwann selbständig einen Neustart und dann geht es wieder. MQTT würde keinen zusätzlichen Traffic beim Stromzähler verursachen, ist aber wohl bei mir nicht so ideal da mein Broker eine FHEM Instanz bei mir im Netz ist das ja nur per VPN über die Fritzboxen am Netz meiner Mutter hängt. Oder geht das irgendwie direkt abzufangen?
tobi0171
commented
4 months ago @schlimmchen >
Zu 2. >Danke für den Eintrag in "DTU Abfrageintervall BUG #674" mit dem Hinweis ! _"cmt_frequency" auf "865000000" und "cmt_countrymode" auf "0". " somit konnte schon mal Fehler Nr 2 dauerhaft bei mir gelöst werden. Einstellungen sind wieder möglich. Merci
Zu 1. "124 Abschaltung..." besteht weiterhin sporadisch, aber nicht mehr so oft. Bin aber scheinbar kein Einzelfall mehr. Log konnte noch nicht erstellt werden. Entweder trat der Fehler nicht auf als ich am Rechner war oder er trat auf und ich hatte den Log nicht laufen.
DaBaBW
commented
4 months ago Ich habe gerade festgestellt dass evtl. der Inverter auch zu oft abgeschaltet wird weil der DPL nicht richtig rechnen kann. Ich habe noch eine 2. PV mit 200Wp ungeregelt laufen, deshalb habe ich jetzt einfach mal den angestrebten Netzbezug auf -250W mit 25W Hysterese und 10W unteres Leistungslimit gestellt. Also sollte der WR eigentlich nie abgeschaltet werden müssen. Trotzdem geht er bei Aktivierung des DPL sofort aus und es werden Anforderung berechnet.
10:45:07.277 > [DPL::loop] StartTH reached: no, StopTH reached: no, inverter is NOT producing 10:45:07.384 > [DPL::loop] SolarPT disabled, Drain Strategy: 1, canUseDirectSolarPower: no 10:45:07.464 > [DPL::loop] battery discharging prevented, PowerMeter: -110 W, target consumption: -250 W 10:45:07.583 > [DPL::loop] ******************* Leaving PL, calculated limit: 0 W, requested limit: 10 W (kept last requested)
Selbst wenn der Netzbezug wieder positiv wird bleibt der Inverter aus:
10:52:39.055 > [DPL::loop] battery discharging prevented, PowerMeter: 84 W, target consumption: -250 W 10:52:39.156 > [DPL::loop] ******************* Leaving PL, calculated limit: 0 W, requested limit: 10 W (kept last requested)
spcqike
commented
4 months ago @DaBaBW
StartTH reached: no, StopTH reached: no,
du hast keinen gültigen "Einspeisezustand". wie sieht deine Config aus? bzw. die Zeile davor wäre noch interessant, und nicht nur der halbe Loop aus der Konsole :)
in meinem Fall
[DPL::loop] ******************* ENTER **********************
11:01:56.174 > [DPL::loop] battery interface disabled, SoC: 0 %, StartTH: 0 %, StopTH: 0 %, SoC age: 421917 s
11:01:56.185 > [DPL::loop] dcVoltage: 39.50 V, loadCorrectedVoltage: 39.50 V, StartTH: 10.00 V, StopTH: 5.00 V
11:01:56.202 > [DPL::loop] StartTH reached: yes, StopTH reached: no, inverter is producing
11:01:56.208 > [DPL::loop] SolarPT disabled, Drain Strategy: 1, canUseDirectSolarPower: no
11:01:56.217 > [DPL::loop] battery discharging allowed, PowerMeter: 193 W, target consumption: -20 W
11:01:56.222 > [DPL::setNewPowerLimit] requested: 258 W, last limit: 262 W, diff: 4 W, hysteresis: 10 W, age: 41589 ms
11:01:56.228 > [DPL::loop] ******************* Leaving PL, calculated limit: 258 W, requested limit: 262 W (kept last requested)Ah ok, ich hatte als DC Spannung Start und Stop 0V drin stehen. Hatte das kürzlich geändert weil ich das als Tip gelesen hatte und nicht mehr dran gedacht. Jetzt steht mal Start 2V und Stop 1V drin und es läuft wieder soweit.
tobi0171
commented
4 months ago ZU 1 DPL:
Hallo, ich habs heute mal geschafft einen Log mitzuschreiben, da nun nichts mehr ging. Ich hoffe es hilf ggf bei der Fehlersuche.
EIn Fehler hierbei war, das der Lesekopf am Zähler nicht mehr erreichbar war, was zum kompletten Abschalten geführt hatte. Wäre es nicht irgendwie möglich für diesen Fall ein "Fallback - Grundlast XXW (z.B 65W)" als fiktiven Wert einzustellen, das der WR nicht abgeschaltet wird?
08:59:35.558 > Fetch inverter: 116183666666 08:59:35.616 > TX RealTimeRunData Channel: 23 --> 15 83 05 69 59 80 19 95 56 80 0B 00 65 D6 FE 16 00 00 00 00 00 00 00 00 5B 19 6B 08:59:35.676 > Interrupt received 08:59:35.736 > RX Channel: 75 --> 95 83 05 69 59 83 05 69 59 01 00 01 01 B8 00 02 00 01 00 0A 00 06 00 02 AF AB 25 | -80 dBm 08:59:35.794 > Interrupt received 08:59:35.901 > RX Channel: 61 --> 95 83 05 69 59 83 05 69 59 03 00 0C 00 01 64 F1 00 02 EE C9 00 00 00 00 09 45 67 | -80 dBm 08:59:36.128 > RX Period End 08:59:36.194 > Last missing 08:59:36.256 > Request retransmit: 4 08:59:36.328 > TX RequestFrame Channel: 40 --> 15 83 05 69 59 80 19 95 56 84 7D 08:59:36.376 > Interrupt received 08:59:36.430 > RX Channel: 3 --> 95 83 05 69 59 83 05 69 59 84 13 8A 00 00 00 DB 00 00 00 00 00 74 00 02 4E 4E 25 | -80 dBm 08:59:37.373 > [HttpPowerMeter] Couldn't find a value with Json query "power" 08:59:37.427 > [HttpPowerMeter] Couldn't find a value with Json query "power" 08:59:37.477 > PowerMeterClass: TotalPower: 159.10 08:59:37.544 > [HttpPowerMeter] Couldn't find a value with Json query "power" 08:59:37.610 > [ 162146.911] DPL: power meter readings are outdated 08:59:37.681 > RX Period End 08:59:37.740 > Middle missing 08:59:37.799 > Request retransmit: 2 08:59:37.961 > TX RequestFrame Channel: 61 --> 15 83 05 69 59 80 19 95 56 82 7B 08:59:38.023 > Interrupt received 08:59:38.088 > RX Channel: 75 --> 95 83 05 69 59 83 05 69 59 02 00 02 BF C5 00 00 00 00 01 B8 00 01 00 03 00 06 52 | -80 dBm 08:59:38.144 > RX Period End 08:59:38.203 > Success 08:59:38.558 > Fetch inverter: 116183666666 08:59:38.610 > TX RealTimeRunData Channel: 75 --> 15 83 05 69 59 80 19 95 56 80 0B 00 65 D6 FE 19 00 00 00 00 00 00 00 00 AB 58 D5 08:59:38.664 > Interrupt received 08:59:38.732 > RX Channel: 23 --> 95 83 05 69 59 83 05 69 59 01 00 01 01 B8 00 02 00 01 00 0A 00 06 00 02 AF AB 25 | -80 dBm 08:59:38.788 > Interrupt received 08:59:38.848 > RX Channel: 40 --> 95 83 05 69 59 83 05 69 59 03 00 0C 00 01 64 F1 00 02 EE C9 00 00 00 00 09 41 63 | -80 dBm 08:59:39.131 > RX Period End
09:00:05.396 > Interrupt received 09:00:05.457 > RX Channel: 75 --> D1 83 05 69 59 83 05 69 59 81 00 00 01 00 B4 01 E4 | -80 dBm 09:00:06.284 > RX Period End 09:00:06.366 > Success 09:00:06.424 > TX ActivePowerControl Channel: 61 --> 51 83 05 69 59 80 19 95 56 81 0B 00 00 C8 00 00 9E 80 E1 09:00:06.503 > Interrupt received 09:00:06.556 > RX Channel: 23 --> D1 83 05 69 59 83 05 69 59 81 00 00 0B 00 14 07 48 | -80 dBm 09:00:08.354 > RX Period End 09:00:08.418 > Success 09:00:08.485 > Fetch inverter: 116183666666 09:00:08.556 > [DPL::commitPowerLimit] Stopping inverter... 09:00:08.640 > TX RealTimeRunData Channel: 75 --> 15 83 05 69 59 80 19 95 56 80 0B 00 65 D6 FE 37 00 00 00 00 00 00 00 00 0A 8D 8F 09:00:08.698 > Interrupt received 09:00:08.760 > RX Channel: 23 --> 95 83 05 69 59 83 05 69 59 02 00 02 BF C5 00 00 00 00 01 B8 00 01 00 03 00 06 52 | -80 dBm 09:00:08.901 > Interrupt received 09:00:08.954 > RX Channel: 40 --> 95 83 05 69 59 83 05 69 59 03 00 0C 00 01 64 F1 00 02 EE C9 00 00 00 00 09 46 64 | -80 dBm 09:00:09.179 > RX Period End 09:00:09.242 > Last missing 09:00:09.292 > Request retransmit: 4 09:00:09.352 > TX RequestFrame Channel: 3 --> 15 83 05 69 59 80 19 95 56 84 7D 09:00:09.415 > RX Period End 09:00:09.465 > Last missing 09:00:09.549 > Request retransmit: 4 09:00:09.686 > TX RequestFrame Channel: 23 --> 15 83 05 69 59 80 19 95 56 84 7D 09:00:09.752 > Interrupt received 09:00:10.373 > RX Channel: 75 --> 95 83 05 69 59 83 05 69 59 84 13 89 00 00 00 DC 00 00 00 00 00 75 00 04 7E FF A7 | -80 dBm 09:00:10.435 > RX Period End 09:00:10.499 > Middle missing 09:00:10.552 > Request retransmit: 1 09:00:10.721 > TX RequestFrame Channel: 40 --> 15 83 05 69 59 80 19 95 56 81 78 09:00:10.776 > Interrupt received 09:00:10.864 > RX Channel: 61 --> 95 83 05 69 59 83 05 69 59 01 00 01 01 B8 00 02 00 01 00 0A 00 06 00 02 AF AB 25 | -80 dBm 09:00:10.928 > RX Period End 09:00:10.976 > Success 09:00:11.031 > TX AlarmData Channel: 61 --> 15 83 05 69 59 80 19 95 56 80 11 00 65 D6 FE 37 00 00 00 00 00 00 00 00 D0 96 54 09:00:11.089 > [ 162179.178] DPL: waiting for a power limit command to complete 09:00:11.136 > Interrupt received 09:00:11.188 > RX Channel: 3 --> 95 83 05 69 59 83 05 69 59 02 00 03 5E CD 6F A7 00 00 00 00 00 7C 00 04 6F AF 77 | -80 dBm 09:00:11.240 > Interrupt received 09:00:11.309 > RX Channel: 75 --> 95 83 05 69 59 83 05 69 59 83 00 00 00 00 00 00 B7 BC 1D | -80 dBm 09:00:11.367 > RX Period End 09:00:11.463 > Middle missing 09:00:11.538 > Request retransmit: 1
_**NACH FEHLERBEHEBUNG > Lesekopf neu gestartet, openDTU neu gestartet und Wechselrichter von Hand neu gestartet... läuft es wieder**_
09:30:03.295 > Success 09:30:03.941 > [ 60.075] DPL: waiting for sufficiently recent inverter data 09:30:04.006 > Fetch inverter: 116186666666 09:30:04.056 > TX RealTimeRunData Channel: 61 --> 15 83 05 69 59 80 19 95 56 80 0B 00 65 D7 06 0B 00 00 00 00 00 00 00 00 DE 0C 1F 09:30:04.112 > Interrupt received 09:30:04.172 > RX Channel: 23 --> 95 83 05 69 59 83 05 69 59 01 00 01 01 80 00 1B 00 1A 00 69 00 64 00 02 AF AC 19 | -80 dBm 09:30:04.237 > Interrupt received 09:30:04.301 > RX Channel: 3 --> 95 83 05 69 59 83 05 69 59 03 00 69 00 01 64 F2 00 02 EE CA 00 00 00 00 09 48 0F | -80 dBm 09:30:04.362 > Interrupt received 09:30:04.421 > RX Channel: 61 --> 95 83 05 69 59 83 05 69 59 84 13 8B 01 87 00 DC 00 10 03 67 00 7E 00 01 8F B5 E2 | -80 dBm 09:30:04.546 > RX Period End 09:30:04.611 > Middle missing 09:30:04.657 > Request retransmit: 2 09:30:04.710 > TX RequestFrame Channel: 75 --> 15 83 05 69 59 80 19 95 56 82 7B 09:30:04.774 > RX Period End 09:30:04.848 > Middle missing 09:30:05.082 > Request retransmit: 2 09:30:05.147 > TX RequestFrame Channel: 3 --> 15 83 05 69 59 80 19 95 56 82 7B 09:30:05.199 > RX Period End 09:30:05.254 > Middle missing 09:30:05.316 > Request retransmit: 2 09:30:05.374 > TX RequestFrame Channel: 23 --> 15 83 05 69 59 80 19 95 56 82 7B 09:30:05.443 > RX Period End 09:30:05.604 > Middle missing 09:30:05.671 > Request retransmit: 2 09:30:05.785 > TX RequestFrame Channel: 40 --> 15 83 05 69 59 80 19 95 56 82 7B 09:30:05.848 > Interrupt received 09:30:05.980 > RX Channel: 75 --> 95 83 05 69 59 83 05 69 59 02 00 02 BF C6 00 00 00 00 01 82 00 1A 00 1B 00 65 0B | -80 dBm 09:30:06.051 > RX Period End 09:30:06.102 > Success 09:30:06.156 > [ 61.206] DPL: waiting for sufficiently recent power meter reading 09:30:06.459 > PowerMeterClass: TotalPower: 361.80 09:30:06.517 > [DPL::loop] * ENTER ** 09:30:06.571 > [DPL::loop] battery interface disabled, SoC: 0 %, StartTH: 10 %, StopTH: 1 %, SoC age: 62 s 09:30:06.634 > [DPL::loop] dcVoltage: 38.40 V, loadCorrectedVoltage: 38.44 V, StartTH: 10.00 V, StopTH: 1.00 V 09:30:06.692 > [DPL::loop] StartTH reached: yes, StopTH reached: no, inverter is producing 09:30:06.762 > [DPL::loop] SolarPT disabled, Drain Strategy: 0, canUseDirectSolarPower: no 09:30:06.811 > [DPL::loop] battery discharging allowed, PowerMeter: 362 W, target consumption: -65 W 09:30:06.862 > [DPL::setNewPowerLimit] requested: 466 W, (re-)sending limit: 466 W 09:30:06.926 > [DPL::loop] * Leaving PL, calculated limit: 466 W, requested limit: 466 W (updated from calculated) 09:30:06.983 > Admin AP remaining seconds: 60 / 180 09:30:07.041 > TX ActivePowerControl Channel: 61 --> 51 83 05 69 59 80 19 95 56 81 0B 00 12 34 00 00 D6 45 82 09:30:07.091 > [ 62.673] DPL: waiting for a power limit command to complete
spcqike
commented
4 months ago @tobi0171 dein Problem ist, wie du richtig erkannt hast, dass dein PowerMeter nicht mehr ausgewertet werden konnte. aktuell stoppt der DPL den Inverter, da er nicht weiß, welche Leistung nun gefordert ist.
Wäre es nicht irgendwie möglich für diesen Fall ein "Fallback - Grundlast XXW (z.B 65W)" als fiktiven Wert einzustellen, das der WR nicht abgeschaltet wird?
Das wurde auch schon mehrfach angesprochen und gewünscht, ist aktuell so aber nicht hinterlegt.
tobi0171
commented
4 months ago @spcqike Zu 1. DPL
Danke dir, für die Bestätigung. Ich werd mal beobachten, ob sich das häuft. Der Lesekopf ist nun jedoch wissentlich das erste mal komplett ausgefallen, daher wars hier relativ einfach diesen Ausfall zu erklären. Sonst läuft er sehr stabil. (Lag am Steckernetzteil). Ich hab sonst keiner Ausfälle oder Signalverluste feststellen können, die App dazu dokumentiert auch Lückenlos ohne Schwankungen oder Einbrüche. Ich sehe dor aber das sich der Wechselrichter teilweise 2,5,10 durch "124" ganz abgeschaltet hat. Teilweise so "verbissen" ,das er nicht von alleine startet und entweder über die DTU gestartet werden muss oder per "LS".
Ob sich diese 124-Abschaltung ggf duch fehlende Singale mehr und mehr (auch bei anderen) häufen? Wurde hier irgendwann die letzen Monate mal was im DPL angepasst? (Hab von der Programmierung nahezu keine Ahnung).
Ein Fallback auf XX Watt, wäre hier ggf. eine feine Sache als "Notbetrieb", das der WR nicht komplett abschaltet, bis er wieder Befehle erhält. (z.B. 2% oder 50W).
Mir ist auch aufgefallen das der npt.pool-Server in letzter Zeit relativ viele Fehler hat. Ich hab ihn mal den ganzen Tag im 5 Sek Takt angepingt und hatte teilweise mehrere hundert Fehler am Tag, manchmal keinen einzigen. Was ggf die "Time Calibration" erklärt, die aber scheibbar wenig/keinen(?) Einfluss hat, außer das sie in der Ereignissanzeige angezeigt wird.
tobi0171
commented
3 months ago Ich denke der Fall kann geschlossen werden, scheinbar waren einige Punkte bei den letzen Updates mit dabei, die zur Stabilitär und Verbesserung beigetragen haben. Danke euch für den unermüdlichen Einsatz in diesem Projekt.
schlimmchen
commented
3 months ago scheinbar waren einige Punkte bei den letzen Updates mit dabei, die zur Stabilitär und Verbesserung beigetragen haben.
Du hast keine Batterie und "Inverter wird an Solarmodulen betrieben" eingeschaltet? Dann sicherlich, denn dann wird bei einem "Ausfall" des PowerMeter nicht mehr abgeschaltet, sondern lediglich das untere Leistungslimit eingestellt.
Danke euch für den unermüdlichen Einsatz in diesem Projekt.
:heart:
tobi0171
commented
3 months ago @schlimmchen
ja, genau so ist es. Danke dir 👍🏻
github-actions[bot]
commented
2 months ago This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.
What happened?
Hallo, nochmal danke allen Betreiligten für das tolle Projekt.
Bin mir nicht sicher ob es ein Bug ist... Bitte mal jmd anschauen
Ich nutze es seit ca 8 Monaten, meist problemlos. Seit einger Zeit erhalte ich (meist zwischen 10 - 16 Uhr) mehrere Fehler - "124 durch Fernsteuerung ausgeschaltet" und time calibration. Dies tritt jedoch nur auf wenn der Dynamic-Power-Limiter aktiv ist. Wurde hier in den letzen Versionen etwas gravierend geändert? Der WR muss teilweise von hand neu gestartet werden oder ist für mehrere Minuten nicht erreichbar. (das sehe ich aus in der Stromzähler-App). Wird der WR ohne den DPL verwendet läuft er komplett durch.
Ich hab bereits die Entfernungen zu den Geräten untereinader geändert (Wifi DTU WR, sind max 3m auseinander, die Hardware habe ich neu aufgesetzt/ersetzt und komplett getauscht. Hilf alles nicht. Laut Facebook haben scheinbar noch weitere Nutzer das Problem. Könnte hier bitte mal jmd schauen, ob es ein Bug in der Firmware gibt?
Beim durchschauen ist mir auch aufgefallen, das man beim NRF Modul keine "Signalstärke" mehr verändern kann. Die 4 Auswahlmöglichkeiten lassen sich nicht mehr anwählen. Es kommt nur eine Fehlermedlung mit Frequenzen, die ja für das NRF nicht eingestellt werden können. Zudem verlieft der WR sporadisch die Verbinung zur DTU.
Ich verdende immer die aktuelle Firmware, das Problem tritt jedoch bereist seit Ende 2023/Anfang 2024 auf und auch nur, wenn der DPL versucht im unteren Bereich zu regeln. Meine Konfiguration lief jedoch zuvor ca 6 Monate prblemlos. Gelegentlich kommt noch "NTP- Fehler - 2 Time Calibration" hinzu. Ich verwende den normalen pool.ntp.org
Hello, thanks again to everyone involved for the great project.
Not sure if it's a bug... Please have someone take a look
I've been using it for about 8 months, mostly without any problems. For some time now (usually between 10 a.m. and 4 p.m.) I've been receiving several errors - "124 switched off by remote control" and time calibration. However, this only occurs when the dynamic power limiter is active. Has anything been changed significantly in the last few versions? The WR sometimes has to be restarted manually or is not accessible for several minutes. (that's what I see in the electricity meter app). If the WR is used without the DPL, it runs completely. I have already changed the distances to the devices (Wifi DTU WR, they are a maximum of 3m apart, I have reinstalled/replaced the hardware and swapped it completely. None of this helps. According to Facebook, others seem to have the problem. Could someone please take a look here and see if there is a bug in the firmware? While looking through it, I also noticed that you can no longer change the "signal strength" of the NRF module. The 4 options can no longer be selected. There is only an error message with frequencies that cannot be set for the NRF. In addition, the WR's connection to the DTU was sporadic. I always use the latest firmware, but the problem has been occurring since the end of 2023/beginning of 2024 and only when the DPL tries to regulate in the lower range. However, my configuration ran problem-free for about 6 months. Occasionally “NTP error - 2 time calibration” is added. I use the normal pool.ntp.org
To Reproduce Bug
Wenn DPL aktiv auftritt, tritt ein Problem auf, sobald die Regelung eingreift
Setup: Hoymiles HM1500 openDTU on battery mit ESP32-V4 38 pin, NRF24+ Antenne 1100m Modul), aufgesteckt auf fertige Platine von Allianc...... Entfernungen zueinader max 3-4m. Stabile verbindung. Kein Akku angeschlossen. 4 Module - alle Anschlüsse belegt, Standardwerte, Bezug -30W, Hysterese 10s, Start/Stopp 10V/1V, Minimalleisting 30W (2% beim HM1500)
If DPL is active, a problem occurs as soon as the control intervenes
Set up: Hoymile's HM1500 openDTU on battery with ESP32-V4 38 pin, NRF24+ antenna 1100m module), plugged onto finished circuit board from Allianc...... Distances from each other max 3-4m. Stable connection. No battery connected. 4 PV modules, all inputs occupied, Standard values, reference -30W, hysteresis 10s, start/stop 10V/1V, minimum power 30W (2% for HM1500)
Expected Behavior
Please check
Install Method
Pre-Compiled binary from GitHub
What git-hash/version of OpenDTU?
ffd189c and newer
Relevant log/trace output
No response
Anything else?
I have already deleted the old DTU from the Fritzbox, IoBroker, etc., as incorrect data could possibly be taken over from there.
No response