Limit 0 eingestellt

[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	ESP8266 GPIO
Pin 1 GND [*]	GND
Pin 2 +3.3V	+3.3V
Pin 3 CE	GPIO2 CE D4
Pin 4 CSN	GPIO15 CS D8
Pin 5 SCK	GPIO14 SCLK D5
Pin 6 MOSI	GPIO13 MOSI D7
Pin 7 MISO	GPIO12 MISO D6
Pin 8 IRQ	GPIO0 IRQ D3

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.88/0.5.89

Github Hash

b6a4150

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

No response

Error description

Seit Version 0.5.88 ist mein HM-1500 und der meiner Eltern in unregelmäßigen Abständen Offline weil ohne jegliche Regelung das Limit im Ahoy auf einmal auf 0 steht und dieser nicht mehr produziert. Man muss dann manuell das Limit wieder hoch setzen und er fängt sofort wieder mit der Produktion an. Auch verabschiedet sich die Website von Ahoy, ständig kein Zugriff mehr. Nur nach trennen vom Strom ist er wieder für einige Zeit erreichbar. Das passiert mit Ahoy auf 8266 und ESP32 an verschiedenen Standorten. Bin jetzt wieder auf 0.5.78 zurück.... alles was danach kam war irgendwie vermurkst. Schade

[beegee3]

mit den Versionen nach 0.5.78 wurde einiges hinzugefügt (z.B. MI Inverter, noch in der Testphase), was den Speicheranspruch deutlich erhöht hat. Gleichzeitig wurde der Speicher stark fragmentiert, was insbesondere bei den ESP8266 sehr schnell zu Fehlern mit Reboots führte und wohl auch zu den Website Hängern. Wie du ja sicher weißt, gibt es dazu eine Reihe Issues. Mit der Version 0.5.89 sollte das Fragmentierungsproblem aber behoben sein. In keiner Version wird das Limit ohne aktive Anforderung von AHOY verändert. Daran hat sich seit 0.5.78 nichts geändert. An alle Mitlesenden: hat jemand auch unaufgeforderte Limit Änderungen? Dann bitte hier posten. Es wäre dann zu prüfen, ob da etwas unbeabsichtigt falsch programmiert wurde.

Und bitte nenne die Versionen nicht 'vermurkst'. Alles nach der letzten Release (0.5.66) sind Testversionen, die nicht nur Verbesserungen, sondern auch neue Features enthalten. Da muss noch nicht alles 'rund' laufen.

[MiniOh]

Ich hab 3 PV Installationen, mit 4 DTUs im Einsatz und noch keine Limitänderung feststellen können.

ESP32 alle 3 auf 0.5.89 ESP8266 noch auf 0.5.88

[blueline13]

Kann das Verhalten bestätigen und auch etwas genauer beschreiben.

Das setzen auf "0" erfolgt bei mir nach dem Starten am Morgen und bei einem Reset. Nicht im Betrieb. Den Reset kann ich provozieren wenn ich den ESP mit WEB Interface beschäftige und er einen RESET ausführt.

Bei mir läuft ein TSUN M1600 Wechselrichter mit 4 Modulen und MQTT ohne Limit Regelungen, ein ESP8266 ohne Display der bis jetzt immer ohne Problem lief. Daher kann ich die Hardware auch ausschließen, den wenn die 78er drauf ist passiert das nicht. Es muss irgendetwas mit der Version sein. Bei mir ist es das erste mal am 11.2 aufgetreten und meine es müsste seit 86er oder 87er Versionen so sein. Sorry das ich da etwas raten muss.

Ich hoffe ich kann da etwas zur besseren Lokalisierung mit dem Zeitpunkt des Auftreten beitragen.

Wenn ihr jemanden zum testen braucht, nur zu 😉

[HFarryranz]

Bei mir ähnlich (ESP8266) wie bei blueline13. Auch das Datum könnte passen. Gedanke eins war WR defekt, weill er mitten am Tag auf 0 ging. Dann kam der Gedanke, dass es mit den Topics

inverter/ctrl/limit_nonpersistent_absolute inverter/ctrl/limit_persistent_absolute inverter/ctrl/limit_persistent_relative inverter/ctrl/limit_nonpersistent_relative

im IoBroker zu tun haben kann. Ich experimentiere gerade mittels Javascripte bezügl Nulleinspeisung. Bin mir nicht sicher ob es auch passiert wenn ich den MQTT weg nehme.

Ich habe dann immer über WEBIF bei IP/serial "relative persistent %" mit 100.0 gesetzt (geht aber nicht immer)

Meine Vermutung: Im IoBroker werden diese og Topics mit (null) angezeigt. Evlt wird da eine 0 daraus gemacht?

[MiniOh]

Ich hab 3 PV Installationen, mit 4 DTUs im Einsatz und noch keine Limitänderung feststellen können.

ESP32 alle 3 auf 0.5.89 ESP8266 noch auf 0.5.88

OK, ich muss meine Aussage revidieren ...

Auch hier mit der 0.5.89 produziert ein WR nicht mehr nach Reboot der DTU.

[HarrysRun]

Bei mir auch mit 5.88 und 5.89, (ESP32 mit einem HM1500) Limit morgens immer wieder 0% auch, wenn man zuvor 100% persistent an den Inverster sendet. Gestern abend fiel mir auf, dass der ESP32 / Ahoy selbst einen Neustart gemacht hat, nachdem der HM1500 offline ging).

[jimknopf63]

mit den Versionen nach 0.5.78 wurde einiges hinzugefügt (z.B. MI Inverter, noch in der Testphase), was den Speicheranspruch deutlich erhöht hat. Gleichzeitig wurde der Speicher stark fragmentiert, was insbesondere bei den ESP8266 sehr schnell zu Fehlern mit Reboots führte und wohl auch zu den Website Hängern. Wie du ja sicher weißt, gibt es dazu eine Reihe Issues. Mit der Version 0.5.89 sollte das Fragmentierungsproblem aber behoben sein. In keiner Version wird das Limit ohne aktive Anforderung von AHOY verändert. Daran hat sich seit 0.5.78 nichts geändert. An alle Mitlesenden: hat jemand auch unaufgeforderte Limit Änderungen? Dann bitte hier posten. Es wäre dann zu prüfen, ob da etwas unbeabsichtigt falsch programmiert wurde.

Und bitte nenne die Versionen nicht 'vermurkst'. Alles nach der letzten Release (0.5.66) sind Testversionen, die nicht nur Verbesserungen, sondern auch neue Features enthalten. Da muss noch nicht alles 'rund' laufen.

Da hast Du Recht vermurkst ist etwas daneben gegriffen. Ist ja eine tolle Arbeit die hier geleistet wird. Neue Features sind ja grundsätzlich gut und zu befürworten. Das da nicht immer alles rund läuft ist verständlich. Mich hat halt nur geärgert das die Ursprungsfunktionen, die ich nutze (Ahoy ohne Display per MQTT am IOBroker verbunden um die Daten auszulesen, auf einmal nicht mehr gehen. Vor allem das der WR auf einmal nicht mehr produziert weil irgdwie ein Limit von 0 gesetzt wurde ohne mein zutun. Habe ja auch schon komplett neu geflasht, also vorher alles gelöscht und der Fehler tritt wieder auf. 8266 und ESP32 im Einsatz

[jimknopf63]

Bei mir auch mit 5.88 und 5.89, (ESP32 mit einem HM1500) Limit morgens immer wieder 0% auch, wenn man zuvor 100% persistent an den Inverster sendet. Gestern abend fiel mir auf, dass der ESP32 / Ahoy selbst einen Neustart gemacht hat, nachdem der HM1500 offline ging).

genau, das kann ich auch bestätigen. Habe erst vermutet das es mit dem 0 stellen der MQTT Yield Werte um Mitternacht zusammenhängen könnte. Aber die habe ich gar nicht aktiviert.

[Tiezy]

Auch bei meiner DTU (ESP8266+HM600) zeigen sich derartige Problem was dazu führt das derzeit kein automatischer Start des Umrichters mehr klappt. Ich bin dann von 5.89 ganz zurück auf 5.66 und auch hier klappt das persistive Speichern z.B. 100% nicht. Ein Neustart erfolgt immer mit Inverterlimit 0%. Ich muss dann unter Serial Control händisch das Limitändern und den Inverter mit turn-on starten. Habe mittlerweile MQTT mit im Verdacht und habe zunächst dies deaktiviert. Da leider das Wetter sehr schlecht ist und somit sehr wenig Licht vorhanden ist, ist aber weiteres testen notwendig da ich mir nicht immer sicher bin ob die Lichtbedingungen ausreichend sind. Ich bleibe da dran.

[beegee3]

das klingt nach dem von @lumapu hier beschriebenen Problem. Bitte prüft, ob euer Broker auch so etwas wie 'States bei subscribe publizieren' eingestellt hat und nehmt das ggfs. raus! @lumapu: schau dir doch bitte nochmal meine Antwort an, ob das nicht eine dauerhafte Lösung sein kann.

[dtuuser]

Bei mir keine Probleme. Ich habe zwei DTUs (ESP8266+HM700) aktiv. Über die 5.66 setze ich automatisch als Nulleinspeisung über CURL Aufrufe das Limit. 30 Minuten vor Sonnenuntergang setze ich das Limit auf 100%. Auf der anderen DTU habe ich aktuell 5.89 drauf. Da wurde bis jetzt kein automatisches Limit gesetzt. Bei beiden ist MQTT deaktiviert. Die 5.66 startet mittlerweile mindestens einmal am Tag durch den Watchdog. neu Die 5.89 läuft jetzt seit 2 Tagen 14Std durch.

[HarrysRun]

das klingt nach dem von @lumapu hier beschriebenen Problem. Bitte prüft, ob euer Broker auch so etwas wie 'States bei subscribe publizieren' eingestellt hat und nehmt das ggfs. raus! @lumapu: schau dir doch bitte nochmal meine Antwort an, ob das nicht eine dauerhafte Lösung sein kann.

Ich scheibe tatsächlich die Daten per MQTT in den IO Broker. Habe dort das Häkchen "status bei..." im mqtt Adapter rausgenommen, ich berichte.

[blueline13]

Hab bei mir nun auch "States bei subscribe publizieren" abgeschaltet und werde morgen berichten.

[Tiezy]

Dito

[Tiezy]

Schade das deaktivieren von "States bei subcribe publizieren" hat nichts daran geändert das das Inverter Limit auf 0% heute morgen wieder gesetzt war.

[Yeah285]

Bei mir das gleiche beim 8266. Auch bei der Version 0.5.66. Es lief Problemlos bis ich den Raspberry getauscht hatte. Vorher lief iobroker auf einem Raspberry 4 mit 1GB RAM, da der schnell an seine Grenzen kam habe ich auf einen Raspberry 4 mit 4 GB RAM gewechselt. Einfach den die SD Karte in den neuen Raspberry getan und alles lief wie vorher. Nur das der HM-600 auf einmal nicht mehr produzierte. Nach einer halben Stunde habe ich gemerkt, dass das Limit auf 0 steht. Nach dem ich das Limit wieder auf 100% gesetzt hatte lief es wieder. Leider wird jeden Morgen das Limit automatisch auf 0% gesetzt. Warum das mit dem neuen Raspberry auf einmal so ist, kann ich leider überhaupt nicht nachvollziehen.

[blueline13]

Ich muss leider auch bestätigen das beim starten heute Morgen der Wechselrichter nicht los gelegt hatte. Erst als ich ihm ein Limit über MQTT gegeben hatte. Bei allen Limits unter "ctrl" waren die Felder leer, kein Wert eingetragen.

Auch bei mir war das "active_PowerLimit" beim starten heute Morgen wieder auf "0". Dann den Wechselrichter mit einem Limit zum starten gebracht. Wird jetzt der Controller neu gestartet ist das "active_PowerLimit" wieder auf "0". Ist das ein verhalten was so gewollt ist?

Weiteres Problem gerade fest gestellt. Ich weiß nicht woher oder welcher Wert als Limit an den Wechselrichter gesendet wird. Jedenfalls bei einem Reset ist der Wechselrichter auf eine Maxwert wert von ca 30 Watt(=2%) festgenagelt. Ursache ist ein folgender Wert im LIMIT "limit_persistent_realtive" von "(null)" ! Das active PowerLimit ist dann auch wieder null. Das Verhalten ist reproduzierbar.

Ein Wert von ""(leeres Feld) oder der default Wert "(null)" im Feld "limit_persistent_realtive" im MQTT(iobroker) lässt nach einem RESET des Controller scheinbar ein Wert an den Wechselrichter senden.

Eins noch, wenn der Controller einmal gestartet wird kann ich unter Serial kein Inverter mehr auswählen um eine Limit zu übertragen.

Ich hoffe das diese Beschreibung etwas weiter hilft bei der Fehlersuche im ESP.

[jimknopf63]

So sehen die entsprechenden Felder bei mir heute morgen wieder aus, keine Werte vorhanden. Ich denke das das Problem auftritt seit dem dieser Pfad ctrl im MQTT eingefügt wurde. Der war ja vorher nie zu sehen, da gab es immer nur CH0-5 und Total in meinem MQTT. V0.5.89

[lumapu]

ich denke hier macht die Lib oder ioBroker einen Fehler. Mit mosquito ist das nicht so. Da ich selbst ioBroker ist bin werde ich auf jeden Fall das Problem lösen. Erste Idee als failsafe: Limit 0 über MQTT nicht zu erlauben

[beegee3]

@jimknopf63 und @blueline13 beschreiben, dass die ctrl und setup Felder keine Werte beinhalten (null). Das ist richtig, da diese Felder von AHOY durch subscribe erst erzeugt aber nicht mit Werten belegt werden. Sie sind nur dafür gedacht, sie durch MQTT mit Werten zu belegen, was (subscribe sei Dank) eine Message in AHOY auslöst. Das hier diskutierte Problem ist, dass offensichtlich diese Messages auch unerwünscht (ohne Werte) ausgelöst werden. Zumindest bei ioBroker ist ein gesetztes 'States bei subscribe publizieren' dafür verantwortlich. @lumapu: in pubMqtt onMessage wird geprüft, ob die Länge von payload größer 0 ist (if(len > 0) {...}) und ggfs. der payload Wert im JSON Objekt als val erzeugt. Bei der Länge 0 wird nichts erzeugt, aber trotzdem das JSON Objekt an den Callback der RestApi weitergeleitet. Dort wird das JSON Objekt wieder zerlegt und interpretiert. Wenn ich das richtig weiterverfolgt habe, liefert der JsonObject Operator [ ] aber bei nicht vorhandenen Feldern 0 zurück. Das würde Limit 0, set_time 0 usw. erklären. Wenn das der Grund ist, sollte ein if(len == 0) return; als erste Zeile von onMessage helfen! Alternativ: ctrl und setup Felder werden vor dem subscribe z.B. mit -1 gepublished und man fängt diesen Wert in onMessage ab.

[beegee3]

P.S.: ich finde, MQTT sollte erst gestartet werden, wenn eine gültige Zeit vorliegt (automatisch durch NTP oder manuell durch SYNC BROWSER), da sonst falsche timestamps übermittelt werden. Aber das ist evtl. ein neues Issue 😉

[HarrysRun]

Noch eine Info, wenn ich die mqtt Instanz am IOBroker neu starte, dann bringt Ahoy im Control "retransmit power limit", dann ist es auf 0 gesetzt.

[beegee3]

vermute, IOBroker arbeitet nach seinem MQTT Neustart alle subscriptions ab und sendet entsprechend an AHOY. In dem Fall hilft es auch ein entfernter Haken bei 'States bei subscribe publizieren' nicht, Noch ein Grund, die Messages zu prüfen.

[guergen1]

Ich sende per MQTT gar kein Limit, dennoch startet der ESP einfach mit 0% am nächsten Morgen. Setze ich dann das persistent Limit auf 100% geht es wieder bis zum neustart am nächsten morgen. War auf 0.5.89, bin wieder zurück zu 0.5.70, da passiert das allerding ebenso!

[jimknopf63]

War auf 0.5.89, bin wieder zurück zu 0.5.70, da passiert das allerding ebenso!

Also bei mir läuft die 5.83 jetzt seit 4 Tagen ohne Probleme auf dem ESP32. Ich habe allerdings im IOBroker in Objekte MQTT den kompletten Pfad mal gelöscht und durch Neustart des Adapters neu erstellen lassen.

[lumapu]

@beegee3 sehr guter Vorschlag, habe gerade folgendes eingebaut:

void onMessage(const espMqttClientTypes::MessageProperties& properties, const char* topic, const uint8_t* payload, size_t len, size_t index, size_t total) {
    DPRINT(DBG_INFO, mqttStr[MQTT_STR_GOT_TOPIC]);
    DBGPRINTLN(String(topic));
    if(len == 0) {
        DPRINTLN(DBG_INFO, F("len == 0"));
        return;
    }
    if(NULL == mSubscriptionCb)
        return;

das ist der Output:

I: [NTP]: 2023-02-22 21:36:40 UTC
I: MQTT connected
I: MQTT got topic: debug/ctrl/limit_persistent_relative
I: len == 0
I: MQTT got topic: debug/ctrl/limit_persistent_absolute
I: len == 0
I: MQTT got topic: debug/ctrl/limit_nonpersistent_relative
I: len == 0
I: MQTT got topic: debug/ctrl/limit_nonpersistent_absolute
I: len == 0
I: MQTT got topic: debug/setup/set_time
I: len == 0
I: MQTT got topic: debug/setup/sync_ntp
I: len == 0
W: NRF24 not connected!
W: NRF24 not connected!

[blueline13]

@lumapu Gemäß deinem Sourcecode Änderungen alle Inhalte der "Limit" Felder gelöscht. Mit 90er FW getestet.

Ich kann bestätigen das der Wechselrichter heute Morgen ohne Regelung gestartet ist. Für mich wäre das Problem mit den Limits und ioBroker gelöst.

[lumapu]

@blueline13 was meinst du mit gelöscht? Eine Einstellung des Limits ist weiterhin möglich, habe es mit 100% getestet.

[HarrysRun]

@lumapu scheint zu funktionieren, Neustart der mqtt Instanz behält das 100% Limit bei und setzt es nicht mehr auf 0%. Vielen Dank!

[blueline13]

@lumapu Sorry für die unglückliche Formulierung. Ich meinte den Inhalt Limit Werte.

[jimknopf63]

Ich habe heute morgen die 0.5.90 installiert und seitdem immer wieder #Alarm Meldungen gehäuft im Control Center. Der WR läuft und produziert. ESP32

[beegee3]

@jimknopf63 kontrolliere bitte nochmal, ob du jetzt wirklich auf 0.5.90 bist. Vielleicht hat das Update nicht funktioniert. Denn mit 0.5.90 sollte die prepareDevInformCmd Zeile anders aussehen: prepareDevInformCmd 0x und vor dem darauf folgenden I: TX müsste ein Zeilenumbruch sein. Auch die Alarm Meldungen könnten auf einen misslungenes Update hinweisen, wenn du in alten MQTT limit Anweisungen feststeckst. Ggfs. ESP vor neuem Update Versuch rebooten.

[jimknopf63]

@jimknopf63 kontrolliere bitte nochmal, ob du jetzt wirklich auf 0.5.90 bist. Vielleicht hat das Update nicht funktioniert. Denn mit 0.5.90 sollte die prepareDevInformCmd Zeile anders aussehen: prepareDevInformCmd 0x und vor dem darauf folgenden I: TX müsste ein Zeilenumbruch sein. Auch die Alarm Meldungen könnten auf einen misslungenes Update hinweisen, wenn du in alten MQTT limit Anweisungen feststeckst. Ggfs. ESP vor neuem Update Versuch rebooten.

Ich habe kontrolliert, auch Reboot und dann nochmals geflasht (Über die Ahoy WebOberfläche). Ich habe jetzt laut Ahoy diese Version Git SHA: 9ef2df2 :: 0.5.90 installiert. Die gleichen Fehlermeldungen. Dann habe ich das ganze nochmals neu gemacht und des ESP komplett gelöscht und eine saubere Installation drauf gespielt. Nachdem ich ihn dann eingebunden habe und der Ahoy lief war das erste was man im Control Center sah diese Alarm Meldungen.

[beegee3]

das sind keine Alarmmeldungen. Falls du die TX und RX Werte meinst, das ist eine intern geführte Statistik, die ein Bild zur Verbindungsqualität NRF <-> Inverter geben soll. Im einzelnen: TX count: Anzahl aller Anfragen an den Inverter RX success: Anzahl der vollständigen Antworten vom Inverter RX fail: Anzahl der fehlerhaften Antworten vom Inverter (Daten und Prüfsumme passen nicht zusammen). RX no answer: keine Antwort vom Inverter erhalten RX fragments: Anzahl der Antwortteile (Antworten können aus mehreren Teilen bestehen, z.B. bilden die Werte jeden Kastens in der Live Ansicht einen Antwortteil, auch Frames genannt) TX retransmits: Anzahl der Nachfragen, falls Antwortteile fehlen

Lass den ESP mal länger laufen um ein Gefühl für die Statistik zu bekommen. RX fail ist sicher die wichtigste Information. Unter 5% von TX count sehe ich als unbedenklich an, wenn darüber, solltest du probieren, ob ein höherer Power Level das verbessert. Aber erst mehr als 15% stufe ich als kritisch ein, Bis dahin ist Grauzone. RX no answer kann am Tag schon mal 30% von TX count ausmachen, auch hier evtl. am Power Level drehen. Wenn der Inverter sich zum Abend abschaltet, also nicht mehr antwortet, geht der Wert natürlich hoch. Auch TX retransmits kann 30% von TX erreichen, ohne dass man sich Sorgen machen muss. Diese Einschätzungen sind nur meine persönliche Meinung, das kann jeder gerne anders beurteilen. Sie basieren nur auf meinen eigenen Erfahrungen für einen unkritischen Betrieb (ESP32). Ich probiere z.Zt. einiges an der Kommunikation NRF <-> Inverter aus, um die Qualität zu verbessern und hab' dabei leider auch richtig schlechte Werte erzeugt, die u.a. zum 'Einfrieren' der Web Oberfläche führten. Richtige Verbesserungen sind mir allerdings noch nicht gelungen, Wird's irgendwo besser, wird gleichzeitig etwas anderes schlechter. 😞 Exzellente Werte kannst du z.B. hier sehen, die halte ich momentan für das Maß der Dinge 😃

[beegee3]

sorry der Hinweis auf prepareDevInformCmd war falsch. Hab's gerade im Code gesehen, es gibt noch eine unkorrigierte Stelle: @lumapu: in hmPayload am Ende von ivSend sollte stehen:

                DBGPRINT(F(") prepareDevInformCmd 0x"));
                DBGPRINTLN(String(cmd, HEX));

[Yeah285]

@lumapu Sorry für die unglückliche Formulierung. Ich meinte den Inhalt Limit Werte.

Wie genau werden die Werte gelöscht? Habe das (null) jeweils entfernt. Leider wird das Limit immer noch jeden morgen auf 0% gesetzt. Sieht bei mir so aus:

[blueline13]

@Yeah285 Dein kompletter "ctrl" Zweig sieht komisch aus, als ob gelöscht und von Hand wieder angelegt. Wenn ich mich noch richtig erinnere sollte der "ctrl" Zweig wieder neu angelegt werden wenn er gelöscht wurde. Also bitte den "ctrl" Zweig mit Unterordnern im ioBroker löschen und die DTU neu starten. Welche DTU FW Version ist installiert?

Das kein Limit mehr von der DTU gesetzt wird wenn die Felder im iobroker leer sind, funktioniert erst ab der 90er FW.

Wenn die 90er FW auf der DTU drauf ist, zur Not ein "persistentes Limit" setzen über die Weboberfläche setzen und dann mal schauen.

[Yeah285]

Den "ctrl" Zweig hatte ich bisher nicht gelöscht und von Hand angelegt. Habe den Zweig jetzt mal gelöscht und die DTU neu gestartet. Der "ctrl" Zweih hat sich bis jetzt nicht wieder angelegt. Bei Neustart ist das Limit gleich wieder auf 0% gesprungen. Ich benutze noch die 0.5.66. Bei allen darüber liegenden Versionen habe ich das Problem dass das Webinterface irgendwann nicht mehr erreichbar ist und ich die DTU neu starten muss. Kann ich somit das Problem unter der Firmware 0.5.66 nicht lösen?

[blueline13]

@Yeah285 Schau mal Morgen nachdem du den Zweig gelöscht hast. Wenn er nicht starten will dann einmal oder am besten jetzt noch ein persistent Limit über das Menü unter Serial und Commands setzen. Es kann sein das das durch neuere FW Versionen ein persistentes Limit gesetzt wurde.

[jimknopf63]

So meinetwegen kann das jetzt hier geschlossen werden. Die 0.5.90 läuft seit ca. 24 Std. und ich habe bisher keine Limitänderungen die nicht beabsichtigt waren feststellen können. Auch ist der WR heute früh ganz normal gestartet.

[Yeah285]

@Yeah285 Schau mal Morgen nachdem du den Zweig gelöscht hast. Wenn er nicht starten will dann einmal oder am besten jetzt noch ein persistent Limit über das Menü unter Serial und Commands setzen. Es kann sein das das durch neuere FW Versionen ein persistentes Limit gesetzt wurde.

Der Zweig wurde bis jetzt nicht wieder angelegt. Der HM 600 ist aber heute morgen mit dem korrektem Limit von 100% gestartet. Somit scheint es erstmal wieder zu funktionieren und das sogar mit 0.5.66