Nach Update auf 0.7.25 keine Verbindung zu den WR mehr

[keinprofi]

Hardware

• ESP8266
• ESP32
• Raspberry Pi

Modelname: ______
Retailer URL: ______

nRF24L01+ Module

• nRF24L01+ you verified this is a Plus model capable of the required 256kBit/s mode
• square dot indicates original Nordic Semicon chip
• round dot indicates copy-cat / counterfeit SI labs chip

Antenna:

• circuit board
• external antenna (SMA)

Power Stabilization:

• 100uF Electrolytic Capacitor
  connected between +3.3V and GND (Pin 1 & 2) of the NRF Module
• Voltage stabilizing motherboard

Version / Git SHA:

Version: 0.7.25
Github Hash: _______

Build & Flash Method:

• AhoyDTU Webinstaller
• VSCode - Platform IO
• Arduino
• ESP Tools

Debugging:

• USB Serial Log (attached)
• Setup settings (use our templates ... to be added)

Mit der 0.6.9 lief alles soweit gut. Lediglich der P_AC total wird in letzter Zeit nicht mehr regelmäßig ausgelesen.
Deswegen habe ich heute ein Update auf die 0.7.25 gewagt und bekam danach keine Verbindung zu den WR mehr.
Nach einem Downgrade auf die 0.6.9 lief es wieder.

Woran kann das liegen?

[ra-ma]

Hallo, bei mir war es ein vergessener Haken bei "NRF24 Enable" im Bereich /Settings/System Config/Radio

[DejanBukovec]

Did you check "System Config"? There is new settings and probably migration is not done and do not enable NRF24 option:

[knickohr]

Und bei der Gelegenheit auch gleich die Settings für die beiden LEDs überprüfen, müssen auf off stehen !

… und mach den Elko rein 😇

[MetaChuh]

meine bisherigen erfahrungen, alles problemlos.

hab' grad 2 dtu's upgedated, und eine neu installiert, alle funzen.
eine von 0.6.9 und eine von 0.7.24. und bei beiden war nrf24 enable bereits aktiviert.

ich glaube anscheinend ist nur bei der neuinstallation das nrf häkchen deaktiviert, wie bei den anderen 0.7.x versionen mit cmt unterstützung.

funkmodule hab' ich sowohl die mit, als auch ohne externe antenne erfolgreich getestet.
(die ohne antenne mit geringer reichweite, aber nicht schlechter als mit v0.6.9)

@keinprofi

ich schätze du machst eh grad ein downgrade flash auf 0.6.9 zum probieren.
bin schon gespannt, was bei dir das ergebnis ist.

[keinprofi]

Kleine Ursache, große Wirkung.

Das war's tatsächlich.
Danke euch!!

[guergen1]

Hier das selbe wie beim TE: Verbindung ist OK, aber keine Daten vom WR; NRF24 ist ein Plus und incl Elko und Display.
Das Display bleibt auf dem Startbildschirm hängen.
Meine letzte getestete funtionsfähige VErsion ist die 0.6.12

[keinprofi]

Grundsätzlich funktioniert es, aber es wechselt immer zwischen Daten und keine Daten bei bestehender Verbindung:

Muss da noch mehr angepasst werden?

So sieht das dann in Grafana aus:

Edit:
Wie es aussieht bekomme ich mit der 0.7.25 auch wieder "total" Daten.
Da ich nun aber weit ab von "Nulleinspeisung" bin, da immer wieder keine Daten empfangen werden, bin ich erstmal zurück auf der 0.6.9, die seit April soweit stabil läuft (mit Ausnahme das ich seit kurzem keine "total" Daten mehr bekomme).

[lumapu]

in 0.7.25 wurde ein schwerwiegender MqTT Fehler gefunden, siehe #1073
In wenigen Minuten ist eine neue Version bereit und verhält sich dann hoffentlich wesentlich stabiler

[keinprofi]

@lumapu - @#1073

Danke für den schnellen Support den Du in Deiner Freizeit für uns alle machst!!!!!!!!

[lumapu]

gerne - aber nicht vergessen ich bin auch der, der die Fehler einbaut 😅
Das ganze lebt von der Zusammenarbeit und damit seid ihr alle genauso wichtig in dem Projekt 🎉

[keinprofi]

0.7.26: Fehler ist bei mir noch da:

sieht dann immer wieder so aus:

[MetaChuh]

@keinprofi
ändert sich was nach einem downgrade auf 0.6.9 ?

[keinprofi]

In 0.6.9 läuft nach wie vor alles bis auf "total".

Hab meine vorige Antwort mal in #1073 gepostet, gehört dann ab jetzt doch da hin.

[knickohr]

Dieses Bild zeigt mir das Du kein Problem mit MQTT hast, sondern mit der Verbindung zu den WRs. Wie das in den #1073 zu tun hat, da ging es um MQTT.

Sorry, ich blicke nicht mehr wirklich durch.

Hast Du mal getestet ob die Verbindung zu den WRs wirklich gut ist und nicht doch aus irgendwelchen Gründen (Entfernung, Power-Einstellung, kaputte Antenne, Abschirmungen …) abbricht ?

Elko dran ? 🫣

[keinprofi]

MIt der 0.6.9. ist die Verbindung dauerhaft stabil. Die Wechselrichter sind etwa 5m entfernt, MIt der 0.6.9 läuft die Ahoy seit April stabil.
im Juni z.B. wurden auch noch Daten für "total" übertragen. Hier ein Beispiel vom 23.06.:

Wie es aussieht wurden hier allerdings zwischen kurz nach 8 und etwa 17.30 Uhr ebenfalls keine Daten übertragen. Dafür ist der Graph zu glatt.

Das eine stabile Verbindung zum WR da ist siehst Du ja z.B. auch hier (live Verbrauch der letzten 24h):

Da der Graph so um die 0 rum ist, werden die WR geregelt, also stabile Verbindung.

Und die Verbindung mit der 0.7.26:

Die Verbindung zu den WR geht regelmäßig verloren. Das kann ich auch in der WebGUI beobachten. Mit der 76 ist regelmößig alles auf 0. Bei der 0.6.9 ist alles wie es soll.

[keinprofi]

Ja, Elko dran.

Im Grunde läuft die 0.6.9 so wie sie soll, ich bin zufrieden, bis auf das "total" nicht übertragen wird. Die Verbindung ist stabil!

[knickohr]

Der Verbrauch hat mit Ahoy nichts zu tun, das kann es nicht messen. Deine Aussagen stützen sich zum größten Teil auf deine Visualisierungsoberfläche.

Und ja, am 23.06. war deine Verbindung (zu der Visualisierungsoberfläche) auch schon weg. Was ist das ? HA, Grafana … ?

Hast Du schon mal direkt in MQTT rein geschnieft ? Also in den Broker ?

[keinprofi]

Ist Grafana.

Ja, Du hast recht das es direkt nichts damit zu tun hat, aber indirekt.

Wenn die Verbindung zur Ahoy unterbrochen ist kann diese die WR nicht mehr steuern und die Erzeugung wäre nicht mehr so konstant um die 0 kWh, sondern hätte deutlich sichtbare Ausbrüche. Da diese nicht da sind muss es sich um eine stabile Verbindung, sprich Steuerung der Ahoy handeln. Dazu muss die Verbindung stabil sein.

Die Anzeige des erzeugten Stroms kann ebenfalls nur erfolgen, wenn die Ahoy eine stabile Verbindung hat. Dass das nicht der Fall ist siehst Du hier mit der 26:

Auf dem Screenshot vom 23.06. siehst Du das nicht. Hier mal ein Ausschnitt von 02.00 - 02.15 Uhr:


Stabil.

Du verstehst?

[keinprofi]

Ich kann auch andere Tage als den 23.06. nehmen, das war ein wahlloses Beispiel...

[keinprofi]

Videos:
069:
https://1drv.ms/v/s!AhDwS_KPMrnmhI96UFk5niSXmZZQiw?e=Fi6faa

0726:
https://1drv.ms/v/s!AhDwS_KPMrnmhI97UWDsMoU0YV4PBg?e=BmDlrA

Wenn Du ein längeres Video der 069 haben möchtest gib bescheid, aber die Verbindung ist stabil!

[knickohr]

Tja, dann komme ich hier mit meinem Latein auch nicht weiter.

Das Problem schon mal im Discord vorgestellt ? Vielleicht weiß da jemand weiter.

[keinprofi]

Nein habe ich nicht.

Kannst Du das MqTT Problem in der 0.6.9 fixen? Das würde mir ja reichen...

[knickohr]

Nein, ich kann’s nicht, nur @lumapu

Frag doch mal im Discord, da gibt’s es öfters solche Verbindungsprobleme.

[keinprofi]

Vielleicht die Tage, heute Abend nicht mehr.

Irgendwie muss es an der 0.7.25 / 26 liegen, denn die Hardware, Entfernung, Leistung, Umgebung usw. sind identisch. Einstellungen wurden ebenfalls nicht geändert, nur die Softwareversion.

[dischi61]

Hallo,
ich bin Trittbrettfahrer und habe keine Programmierahnung aber ein ähnliches Problem.
Vielleicht kann mir jemand einen Tipp geben.
Verbindung zum WR scheint zu funktionieren. Ich bekomme aber keine Daten. Ich habe mal einen Screenshot gemacht

Hat einer eine Idee?
Gruß Ralf

[dischi61]

Achso, ich habe 0.7.21 installiert

[keinprofi]

@keinprofi ich nehme an, du hast HMS Wechselrichter mit einem CMT Funkmodul an einem ESP32. Könntest auch du den Haken für "Serial Debug" setzen und ein Log posten? Mich würde auch interessieren, ob da was von Alarm ID incremented oä. auftaucht. Wenn du falsche Daten empfängst sollte es darüber sichtbar werden. Misst du zufällig auch noch die Leistung mit einem Shelly oä.? Es gibt auch den Fall, dass der Wechselrichter abschaltet wegen Überspannung, eher unwahrscheinlich, sollten wir aber ausschließen.

Ähm, mal ne blöde Frage, den Haken habe ich gesetzt, wo finde ich das Log? Ist das unter "Serial / Control"?

[keinprofi]

Den WR "112555555245" kannst Du ignorieren, das ist der 400er der erst ab 20 Uhr läuft (Batterie).

Wenn die WR angeblich nichts produzieren sieht das so aus:

Mein Stromzähler zeigt allerdings an, dass die Panels sehr wohl weiter produzieren!
Log-726.txt

[lumapu]

@keinprofi warum übertragst du so oft das Power-limit obwohl es sich garnicht geändert hat? Du hast ca. 150 Power-Limits in 15 Minuten geschickt, d.h. im Schnitt alle 6 Sekunden. Ab und zu musst du der DTU noch zeit geben auch die Live-Daten zu holen. Ich denke deine Lücken kommen evtl. von falsch interpretierten (auf DTU Seite) Dev-Control Commands (also die Power-Limits). Das blöde an den Wechselrichtern und ihrem Protokoll ist, dass man nicht herausfinden kann auf welche Anfrage eine Antwort gekommen ist. Daher gibt es nur wenige Plausibilitätstests, zB. wird die länge der erwarteten Antwort geprüft. Durch dein Timing kann ich mir gut vorstellen, dass hier was durcheinanderkommt.

@MiBa365 Power-Level nicht auf MAX, besser auf LOW oder MIN stellen

@guergen1 ich kenne den HM750 nicht, ist das ein 2-kanaliger HM-Wechselrichter, wie sind die ersten 4 Stellen der Seriennummer?

[keinprofi]

Ich habe keine Anhnung, das gibt das Script her... Vielleicht liest @reserve85 ja mit und kann da was zu sagen? Ich nutze sein Script für die Steuerung.

Funktioniert ja auch grundsätzlich. Von den Details, was wann warum gesendet wird habe ich keine Ahnung........

[guergen1]

@lumapu sorry hm-700, 2 MPPT, Die Serial beginnt mit 1141

[keinprofi]

Wie es allerdings scheint funktioniert alles, also auch das "total" ausgelesen wird, wenn alle 3 WR laufen, also ab 20 Uhr.
Wenn der 400er tagsüber also Offline ist wird total nicht ausgelesen (in der 0.6.9). Das nur nebenbei, hat ja mit der 726 nix zu tun.

Die 6 Sekunden sind übrigens auch bei der 069 so eingestellt. Dennoch funzt das mit der 726 nicht. Kann es wirklich damit zu tun haben?

[reserve85]

Ich habe keine Anhnung, das gibt das Script her... Vielleicht liest @reserve85 ja mit und kann da was zu sagen? Ich nutze sein Script für die Steuerung.

Funktioniert ja auch grundsätzlich. Von den Details, was wann warum gesendet wird habe ich keine Ahnung........

Hi, bin im Urlaub und habe nicht viel Zeit: Du kannst in der config die Anzahl der Wiederholungen einstellen:

# defines how often a identical limit will be set, set it to "-1" for disabled (infinite repeat)
SET_LIMIT_RETRY = 10

Ggf. hast du auch ein zu kurzes Regelintervall. 6s Intervall schaffe ich mit einem WR nicht. 10s klappt einwandfrei, auch mit der 7.26
Edit: glaube das hab ich falsch verstanden, ich meine das Regelintervall von dem Zero export Script:

# interval time for setting limit to Hoymiles
LOOP_INTERVAL_IN_SECONDS = 20

In Ahoy habe ich auch 6s und klappt hervorragend mit einem inverter.

[knickohr]

@keinprofi

Wie ? Du ballerst alle 6s ein Setting für ein Power-Limit raus ? sorry, habe das Log nicht gelesen, war mir ehrlich gesagt zu anstrengend. Ich habe auch schon Versuche mit Power-Limits gemacht und kann nur sagen, man muß mindestens solange warten bis er das Limit akzeptiert (/ack_pwr_limit), erst dann funktioniert er damit auch. Und noch eine Erfahrung, wenn man immer wieder das gleiche Limit in sehr kurzen Abständen sendet, dann kann sich sogar der Inverter aufhängen. Les mal im Discord, da gibt es Fälle das die Inverter dann überhaupt nicht mehr wollen, sich sogar fest auf das letzte Limit „einbrennen“. Besser ist es, das Limit nur zu senden, wenn es sich auch wirklich ändert und das letzte Limit akzeptiert wurde.

Viel, hilft nicht immer viel oder geht besser 🤓

[keinprofi]

Ich werde das mal an @reserve85 weiter geben, evtl. sollte er sein Sript anpassen. Aber das wird ja dann vermutlich nicht das Problem sein(?).

Edit:
Habe gerade erst seine Antwort oben gesehen...

[keinprofi]

Ich habe keine Anhnung, das gibt das Script her... Vielleicht liest @reserve85 ja mit und kann da was zu sagen? Ich nutze sein Script für die Steuerung.
Funktioniert ja auch grundsätzlich. Von den Details, was wann warum gesendet wird habe ich keine Ahnung........

Hi, bin im Urlaub und habe nicht viel Zeit: Du kannst in der config die Anzahl der Wiederholungen einstellen:

# defines how often a identical limit will be set, set it to "-1" for disabled (infinite repeat)
SET_LIMIT_RETRY = 10

Ggf. hast du auch ein zu kurzes Regelintervall. 6s Intervall schaffe ich mit einem WR nicht. 10s klappt einwandfrei, auch mit der 7.26 Edit: glaube das hab ich falsch verstanden, ich meine das Regelintervall von dem Zero export Script:

# interval time for setting limit to Hoymiles
LOOP_INTERVAL_IN_SECONDS = 20

In Ahoy habe ich auch 6s und klappt hervorragend mit einem inverter.

Ich meine das ich den SET_LIMIT_RETRY auch auf 10 habe. LOOP_INTERVAL_IN_SECONDS muss ich heute Abend mal schauen, hab ich so nicht auf dem Schirm.

@reserve85
PS: Ich wünsche Dir einen schönen und vor allem erholsamen Urlaub :-)

[knickohr]

Nochmal : Warten auf das ack, und dann erst neue, veränderte Werte senden 😉

[reserve85]

man muß mindestens solange warten bis er das Limit akzeptiert (/ack_pwr_limit), erst dann funktioniert er damit auch.

@knickohr: Geht das überhaupt über die webAPI? Finde das nur via MQTT.

[knickohr]

Ich habe die API nicht angeschaut. Wenn es da nicht drin ist, wäre die nächste Alternative das Warten auf den gesetzten Power-Limir Wert :

/ch0/active_PowerLimit

Keine Ahnung ob das auch in der API drin ist. Der Wert kommt aber verzögert, da war das ack schon da. Vielleicht bei der API anders ?

[MetaChuh]

@knickohr & @reserve85

in der api ist es im endpoint http://<dtu_ip>/api/inverter/id/<0-8>
in der variable power_limit_read
beispiel:
http://192.168.0.200/api/inverter/id/0

das liefert dann ein array mit folgenden werten zurück:

    (
                [id] => 0
                [enabled] => 1
                [name] => HM-800
                [serial] => 123412341234
                [version] => 10010
                [power_limit_read] => 100
                [ts_last_success] => 1691590772
                [ch] => Array
                    (
                        [0] => Array
                            (
                                [0] => 231.2
                                [1] => 0.72
                                [2] => 165.4
                                [3] => 49.96
                                [4] => 1
                                [5] => 32.3
                                [6] => 197.626
                                [7] => 1041
                                [8] => 173.7
                                [9] => 95.222
                                [10] => 0.1
                            )

                        [1] => Array
                            (
                                [0] => 30
                                [1] => 2.97
                                [2] => 88.9
                                [3] => 536
                                [4] => 105.775
                                [5] => 21.683
                            )

                        [2] => Array
                            (
                                [0] => 30.3
                                [1] => 2.8
                                [2] => 84.8
                                [3] => 505
                                [4] => 91.851
                                [5] => 20.683
                            )

                    )

                [ch_name] => Array
                    (
                        [0] => AC
                        [1] => JKM410M Bottom
                        [2] => JKM410M Top
                    )

                [ch_max_pwr] => Array
                    (
                        [0] => 
                        [1] => 410
                        [2] => 410
                    )

            )

greetings
metachuh

[reserve85]

@MetaChuh: power_limit_read ändert sich allerdings erst nachdem die neuen Werte vom Inverter zurückgelesen werden. Das kann u.U. ziemlich lange dauern, je nach Intervall.

Für die RestAPI Kommunikation ohne MQTT wäre eine Acknowledge-Möglichkeit für die Limit-Änderung (ähnlich MQTT) gut.
Ggf. könnte man bei dem Limit setzen eine (optionale) ID mitsenden und über REST ein ACK-Field mit der letzten erfolgreichen ID zur Verfügung stellen.

[knickohr]

Jetzt haben wir diesen Issue total vergewohlwurstelt 😱 Das hat doch überhaupt nichts mehr mit dem Thema zu tun. Kann man das irgendwie absplittern und in einen neuen Issue rein pappen ?

mit dem Power-Limit über MQTT bin ich auch noch nicht so glücklich. Hier sollte man QoS=2 machen, sowohl für das Set-Limit als auch für das ACK. Ansonsten kann das schon mal im Nirvana verschwinden und man wartet ewig auf ein ACK 😲

[MetaChuh]

@MetaChuh: power_limit_read ändert sich allerdings erst nachdem die neuen Werte vom Inverter zurückgelesen werden. Das kann u.U. ziemlich lange dauern, je nach Intervall.

ja, gibt latenz, dauert bei mir aber nur ca 10 sek. bis zum ack.
deine latenz kannst du leicht in der dtu austesten, einfach manuell power limit setzen und bei live nachschauen wann er die änderung anzeigt.
am shelly power meter siehst du dann auch gleich den anspeise anstieg oder abfall.

ich zb. warte auf das ack bevor ich eine weitere änderung sende, und sende kein limit wenn bei mir $current_power_limit == $power_limit_read der dtu ist.

Für die RestAPI Kommunikation ohne MQTT wäre eine Acknowledge-Möglichkeit für die Limit-Änderung (ähnlich MQTT) gut. Ggf. könnte man bei dem Limit setzen eine (optionale) ID mitsenden und über REST ein ACK-Field mit der letzten erfolgreichen ID zur Verfügung stellen.

ich verwende auch nur pure php und dtu, ohne middleware.
php statt python, wegen der einfachen web gui aufbereitung, ohne eine weitere code instanz zu benötigen.
muss mir bei zeiten mal deinen code anschauen, habe bis jetzt nur gutes gehört 👍

ich teste mal den letzten turbo commit von @lumapu (thx, by the way) 👍
edit: power_limit_ack getestet (v0.7.29 & v0.7.30)
funzt perfekt, vielen dank 👍

greetings
metachuh

[knickohr]

Die 30 ist OK, Schwuppdizität hat nicht gelitten 😂, 29 habe ich gar nicht angeschaut 😇

Das mit der Alarm-Message schaue ich mir mal an, war schon lange ein Punkt, was aufgestoßen ist. Sind da jetzt alle Meldungen drin oder nur die letzte ? Klar, es wird immer nur eine gesendet.

Wurde nochwas an MQTT gemacht ? QoS für die Piwer-Limit Messages ?

wir sollten den Issue hier zu bekommen, ansonsten wird das der Feld-Wald-Wiesen-Durchrinander-Issue 😱

[lumapu]

ich versuche jeder Version, die ich veröffentliche eine neue Nummer zu geben zwecks Nachvollziehbarkeit. Daher so schnell 29 und 30 😊

Nein bzgl. QoS haben ich noch nichts gemacht, evtl heute Abend.

Die Alarm Messages:

• es werden die letzten 10 von Ahoy vorgehalten /api/inverter/alarm/[ID]
• über MqTT werden ebenfalls die letzten 10 ausgegeben, aber nur wenn sie verschieden von 0 sind, standardmäßig sollte der Invertert started drin stehen
• Ahoy arbeitet mit einem Rolling Buffer, immer der älteste Wert wird überschrieben, MqTT published immer Alarm 1-10, also unsortiert

[reserve85]

@lumapu Mega, Danke für die REST Erweiterung ich schaue mir das dann demnächst an.

[knickohr]

@lumapu

QoS=2 aber bitte nur bei den 3 Messages für das Power-Limit, also :

• das Setzen des Limits …/ctrl/limit/
• das Ack des Limits …//ack_pwr_limit
• und den aktuellen Wert des Limits aus dem WR …//ch0/active_PowerLimit

Wobei sich bei der letzten Message streiten läßt ob da wirklich QoS=2 sein muß, da könnte auch 1 reichen, vorausgesetzt das Ack kommt sauber und auch nur einmal.

Alles andere würde sicher nur den Rechenaufwand und den Traffic unnötig erhöhen, bzw. sicherlich wieder die Schwuppdizität leiden lassen 😅