[ESP32] keine Kommunikation mit Wechselrichter mit 0.5.79

[MiniOh]

Platform

ESP32

Model name

No response

nRF24L01+ Module

nRF24L01+ plus

Antenna

circuit board

Power Stabilization

nothing

Connection diagram

-

Connection picture

• [ ] I will attach/upload an Image of my wiring

Version

0.5.79

Github Hash

xxxxxx

Build & Flash Method

Platform IO (build & flash)

Desktop

Windows

Setup

ESP32

Debug Serial Log output

08:33:47 I: enqueued cmd failed/timeout
08:33:47 I: (#1) I: no Payload received! (retransmits: 0)
08:33:47 I: resetPayload: id: 1
08:33:47 I: (#1) Requesting Inv SN xxxxxx
08:33:47 I: (#1) sendTimePacket

Error description

Hallo,

seit der 0.5.79 funktioniert bei mit die Kommunikation mit den Wechselricher nicht mehr.

Output ist: 08:33:47 I: enqueued cmd failed/timeout 08:33:47 I: (#1) I: no Payload received! (retransmits: 0) 08:33:47 I: resetPayload: id: 1 08:33:47 I: (#1) Requesting Inv SN xxxxxx 08:33:47 I: (#1) sendTimePacket

System Infos: Inverter #0: HM-1500-01 (v0) is not yet available

[soelli22]

Kann ich bestätigen. Tritt bei mir auch so auf.

[Ollipop030]

Bei mir das gleiche, beide Wechselrichter sind "not available". Hab ein Downgrade auf 0.5.78 gemacht, dann ging es wieder.

[Argafal]

Kann ich auch bestätigen. Ich hab versucht, das Problem noch weiter einzugrenzen. 94fe61b54432fa4de85c2a538b851ff6d6a019e7 funktioniert.

[beegee3]

Das neuste commit https://github.com/lumapu/ahoy/commit/edefcf1c830b5ea7cd202a9d27395811a6f5a03b bezieht sich auf #655 Leider fehlt eine notwendige Anpassung, weshalb die Kommunikation nicht funktioniert. @lumapu mit den Anpassungen des commit muss die globale statische Variable mIrqRcvd zu einer lokalen nicht-statischen Variable geändert werden, d.h. in Radio.h die Zeile static volatile bool mIrqRcvd; löschen und stattdessen volatile bool mIrqRcvd; ganz am Ende eintragen. Dann funktioniert die Kommunikation wieder! 😃

[beegee3]

mich wundert nur, wie es zu dem Fehler 'ISR not in IRAM' kommt. Ist es ein ESP8266 Problem? Die Anpassung für attachInterrupt mit einer lambda function und einer globalen statischen Variable hatte ich irgendwo in einem ESP8266 sketch gefunden. Aber egal, mit der Korrektur geht's ja auch!

[lumapu]

@beegee3 danke für den Hinweis. Funktioniert prima, werde ich heute Abend als 0.5.80 veröffentlichen. Warum geht das mit der statischen variable nicht?

[beegee3]

Warum geht das mit der statischen variable nicht?

Ganz ehrlich: weiß ich auch nicht. Als globale Variable existiert mIrqRcvd bereits bevor Radio als Teil von mSys erzeugt wird und die lambda function sorgt dafür, dass Radio den aktuellen Zustand abfragen kann. Ohne lamda function ist es evtl. nur der Zustand vom Init. Ist nur eine Vermutung 🤔. Schade, dass das ISR Problem aufgetreten ist. Frag mich, ob das vielleicht am Flashen lag. Mir war aufgefallen, dass im log auch W: failed to load json, using default config angegeben war, was auf noch andere Probleme hinweist. Hattest du das ISR Problem auch? Dein Update kam ja so schnell, dass kaum ein anderer das bestätigen konnte.

[lumapu]

ja, das Problem war sofort da auch bei erneutem flashen. Ich habe sogar zwischendrin mit dem online Flashtool die 0.5.66 aufgespielt mit erase.

Ahoy hat eher einer blink Demo geglichen. Auf der Seriellen Konsole stand ISR not in IRAM!. Es war auf einem ESP8266

[beegee3]

hab' per Google die Antworten gefunden:

1. je nach Version ignoriert der GCC Compiler das IRAM_ATTR bei lambda functions, was zu ISR not in IRAM führt
2. ESP32 kommt auch ohne das Attribut zurecht, d.h. es ist ein ESP8266 Problem
3. globale statische Variablen und Instanzen sind voneinander unabhängig und müssen erst miteinander 'verknüpft' werden, sonst hat man ein 'unpredicted behavior'

Für 1. und 3. gibt es Lösungen. Die sind aber nicht einfacher als die oben in 0.5.80 vorgesehene Korrektur.

(off topic) Apropos Korrektur: in payload.h, setup ist die Zeile mCbAlarm = NULL; zweimal direkt untereinander vorhanden .

[MiniOh]

@beegee3 Ich nutze ein ESP32 und habe beschriebene Problem mit der 0.5.79

[lumapu]

dann liegt es an der GCC Version, wenn ich @beegee3 richtig verstehe

[sstidl]

Ich habe das gleiche Problem auf dem esp8266 230206_ahoy_0.5.81_75539c5_esp8266.bin geflashed und dann Dauerlicht auf der blauen LED und keine Antwort vom Inverter. Bei der .78 leuchtet die LED nur beim Senden des NRF Serielles Fenster im web schreibt keine Fehlermeldung, nur dass er keine Response bekommt. Senden findet statt. Downgrade auf .78 und alles geht wieder.

[Ollipop030]

ESP32 und 0.5.81, auch kein Empfang.

[lumapu]

ESP32 und 0.5.81, auch kein Empfang.

ja beim ESP8266 auch nicht, daher die 0.5.80 erst mal verwenden - die funktioniert tadellos 😃 https://github.com/lumapu/ahoy/suites/10813443261/artifacts/544087301

[sstidl]

ESP32 und 0.5.81, auch kein Empfang.

ja beim ESP8266 auch nicht, daher die 0.5.80 erst mal verwenden - die funktioniert tadellos 😃 https://github.com/lumapu/ahoy/suites/10813443261/artifacts/544087301

Stimmt, die funktioniert. Leider stört mich die Dauerbeleuchtung der blauen LED... Kann ich da was machen?

[beegee3]

Dauerbeleuchtung der blauen LED

ist mir gerade erst eingefallen: mit der überarbeiteten hmRadio ist der NRF jetzt standardmäßig im Sendemodus, schließlich muss erst gesendet werden, bevor man etwas empfangen kann. Früher war der Standard allerdings der Empfangsmodus. Also entweder die LED so ändern, dass sie nur beim Empfang angeht, oder Empfangsmodus wieder als Standard setzen. @lumapu, falls du den Empfangsmodus in hmRadio wieder als Standard setzen willst: in setup mNrf24.startListening(); einfügen, in loop die beiden mNrf24.stopListening(); löschen, dafür in sendPacket vor dem Senden mNrf24.stopListening(); eintragen. Das sollte eigentlich alles sein.

[lumapu]

@beegee3 ich denke das sollten wir einbauen. Die User merken aber auch alle Änderungen 😉

[killamilla0815]

Hallo zusammen Bin neu in dem Thema und bräuchte eure Hilfe: hab mir auf kleinanzeigen ein Board auf ESP32 Basis incl. Display geholt, vorbespielt mit der 0.5.79. Bei der Inbetriebnahme bin ich dann auf diesen Fehler hier gestossen, keine Kommunikation mit dem HM1500. Der Verkäufer bietet keinen Support an, daher bin ich über ein wenig Suchen auf diesen Thread gestossen. Erste Massnahme war, das Board auf die offizielle version 0.5.66 downzugraden. Danach ging das Display nicht mehr, vermutlich enthält die keine passenden Treiber dafür. Kommunikation kam immer noch nicht zustande. Danach bin ich auf die 0.5.80 gegangen, die hier verlinkt wurde. Ob er damit kommuniziert, kann ich erst morgen testen, wenn der HM1500 wieder aufwacht. Display geht aber immer noch nicht. Hat jemand ne Idee, was ich tun muss, um das wieder ans Laufen zu bringen ? Ist eins mit knapp 4cm Diagonale, gehe mal davon aus, dass es da nicht viel Auswahl gibt, was man für dieses Projekt verwendet ?

Danke schonmal im voraus.

[lumapu]

Der Verkäufer bietet keinen Support an, daher bin ich über ein wenig Suchen auf diesen Thread gestossen.

Ich denke den Support hast du bezahlt, alles über 15€ war Verdienst des Verkäufers.

Genau diesen Fall hasse ich: hier sind sehr viele Freiwillige unterwegs um jeden zu helfen. Was und aber widerstrebt sind Fremde die über EbayKA nur Profit machen. Sorry dass es dich erwischt hat, danke für deine Ehrlichkeit. Der Verkäufer hat gegen unsere Lizenz (non-commercial) verstoßen!

Kurz: 0.5.66 hat noch extra binaries (im zip hier über release herunterladen). Es gibt zwei OLEDs, Sh1106 ist das große und ein Nokia LCD.

Bei neuen Versionen (development) kann man das Display nachträglich konfigurieren über die Einstellungen in Ahoy.

[killamilla0815]

Hab jetzt eine 0.5.73 vom Verkäufer aufgespielt, das 1,3" Zoll Display geht jetzt wieder. Allerdings kommuniziert er nach wie vor nicht mit meinem HM1500, soll das mit der 73er Version gehn oder wo kann man hier weiter ansetzen ?

Hier mal ein Auszug der seriellen Logs (SN hab ich ausgeixxxxt. die stimmt aber, mehrfach überprüft):

... ... 11:21:18 I: TX 27B Ch40 | 15 73 40 89 22 82 59 53 52 80 01 00 63 e7 6c 1d 00 00 00 00 00 00 00 00 22 34 35 11:21:20 W: nothing received: Request Complete Retransmit 11:21:20 I: (#0) sendTimePacket 0x1 11:21:20 I: TX 27B Ch61 | 15 73 40 89 22 82 59 53 52 80 01 00 63 e7 6c 1d 00 00 00 00 00 00 00 00 22 34 35 11:21:22 I: enqueued cmd failed/timeout 11:21:22 I: (#0) I: no Payload received! (retransmits: 2) 11:21:22 I: resetPayload: id: 0 11:21:22 I: (#0) Requesting Inv SN 1161xxxxxxxx 11:21:22 I: (#0) sendTimePacket 11:21:22 I: TX 27B Ch75 | 15 73 40 89 22 82 59 53 52 80 0b 00 63 e7 6c 22 00 00 00 00 00 00 00 00 d9 2b e4 11:21:23 W: nothing received: Request Complete Retransmit 11:21:23 I: (#0) sendTimePacket 0xb 11:21:23 I: TX 27B Ch3 | 15 73 40 89 22 82 59 53 52 80 0b 00 63 e7 6c 22 00 00 00 00 00 00 00 00 d9 2b e4 11:21:25 W: nothing received: Request Complete Retransmit 11:21:25 I: (#0) sendTimePacket 0xb 11:21:25 I: TX 27B Ch23 | 15 73 40 89 22 82 59 53 52 80 0b 00 63 e7 6c 22 00 00 00 00 00 00 00 00 d9 2b e4 ... ...

[killamilla0815]

Und dann noch eine generelle Frage, da ich mit github bisher kaum was zu tun hatte: fall es mit der Version 73 nicht gehn soll, wo gibt es die fertigen Binaries der Developer Versionen ? Oder muss sich die jeder selbst kompilieren ? Das wäre schade, weil so weit reichen meine Kenntnisse nicht aus. Würde es gern mal mit einer Developer Version versuchen, die diesen Fehler bestätigtermaßen beheben soll, auch wenn das Display dort noch nicht integriert ist. Wäre einfach schön zu sehen, dass das Teil das tut, wofür ichs angeschafft habe...

Danke.

[lumapu]

https://ahoydtu.de/web_install

[killamilla0815]

Danke für den Link. Hab nun die neuste 0.5.85 aufgespielt (Display geht damit nicht) und auch damit keine Kommunikation mit meinem HM1500: Logs sehn noch genauso aus wie oben, "No payload received"...

Wenn ich das richtig interpretiere, dann sendet die Ahoy ständig (Tx) auf allen mögichen Kanälen, aber es kommt nichts zurück (Rx) vom HM1500 ? Hatte darum beide in nem halben Meter Abstand platziert, damit den Empfang als Ursache ausschliessen kann, aber hat nichts gebracht.

Gibts überhaupt noch was, was ich tun kann, ausser das Teil dem Verkäufer zurückschicken und mein Geld zurück verlangen ?

Gibt es möglicherweise Chargen vom HM1500, die sich mit der AHOY Selbstbaulösung nicht ansprechen lassen, ggf. abhängig vom Firmwarestand des HM, ist da was bekannt ?

[lumapu]

nein bis jetzt gehen alle inverter. Evtl. die Verkabelung prüfen, oft empfehlen wir die IRQ und CE Pins zu tauschen, sowohl Hardware als auch Software. Das Display musst du mit dem Verkäufer klären, kp was da gemacht wurde.

[killamilla0815]

Da ich das Ganze nicht selbst aufgebaut habe (nicht weil ichs nicht könnte, sondern weil mir die Zeit dafür zu schade war), hab ich was Fertiges gekauft, in der Hoffnung eine plug&play Lösung zu bekommen. Nun hab ich schon viel mehr Zeit in die Fehlersuche gesteckt als wenn ich alles selbst gemacht hätte. Würd das gern versuchen, die besagten Leitungen zu tauschen, allerdings hab ich mir das Board jetzt mal genauer angeschaut: meins hat nur 30 statt 38 Pins wie hier beschrieben: https://github.com/lumapu/ahoy/blob/main/doc/Wiring_ESP32_Schematic.png

Hier mal ein Bild meines ESP32 Boards: https://ibb.co/r0ByFmr

Welche Pins kann ich dazu verwenden und welchen GPIO settings entspricht das in der System Config der AhoyDTU ?

Danke.

[Ollipop030]

So ein Board habe ich auch, könnte aber mit der 0.5.85 Probleme geben, siehe #674 Bei mir läuft die 0.5.83 fehlerfrei. Pinout ist wie folgt:

Antenne ESP GND GND VCC 3V3 CE D4 CNS D5 SCK D18 MOSI D23 MISO D19 IRQ RX2

Pinout der Antenne: https://howtomechatronics.com/wp-content/uploads/2017/02/NRF24L01-Pinout-NRF24L01-PA-LNA-.png

Aber aufpassen, bei den Antennen sind die Pins manchmal auf der anderen Seite, da muss man umdenken. Der Pin für Masse hat aber immer ein aufgdrucktes Quadrat auf der Platine.

[killamilla0815]

Danke @Ollipop030. Ich hab bisher mit KEINER Softwareversion eine Verdindung zustande bekommen, weder alle möglichen Devs bis hinaus zur letzten 0.5.85 noch mit der offiziellen. Kann es gern mit der 0.5.83 versuchen, die war bisher noch nicht dabei, aber bin mittleerweile skeptisch. Aber schneller als neu verkabeln isses sicher, also probier ich das auch noch.

Kann es sein, dass mein Board so ne Art ESP32 China Klon ist und es möglw. deswegen Probleme gibt ?

[Ollipop030]

Lt. dem Foto sieht das erstmal gut aus, die ESP gibt es ja offiziell mit 30 Pins. Probier es mal aus und berichte.

[killamilla0815]

@Ollipop030 Auf D4(GPIO4) und RX2(GPIO16) sind ChipEnable und Interrupt aktuell gesteckt, auf welchen Pins soll ichs denn noch prrobieren, weil @lumapu oben geschrieben hatte, dass man das versuchen könnte und welchen GPIOs entsprechen die dann ?

[Ollipop030]

Bei mir läuft es mit der Verkabelung wie beschrieben, in den Settings dann CS/GPIO5, CE/GPIO4, IRQ/GPIO16. Wobei du dann CE und IRQ tauschen kannst. Wird denn die Antenne überhaupt erkannt?

[killamilla0815]

Nach meinem Dafürhalten ja: https://ibb.co/YWVFPtS falls du mit "Antenne" das nrf24l01+ Modul meinst. Es funkt ja auch fleissig wie man in den Logs sehn kann (Tx Pakete), aber vom HM1500 kommt einfach nichts zurück (Rx success 0), so als ob er tot wäre. Natürlich ist er das nicht, LED blinkt grün und er speist auch ein, während ich meine Tests mache.

Weiss nicht mehr wo ich ansetzen soll, morgen kann ich das nochmal mit vertauschen von CE und IRQ Leitung versuchen und das Board mal direkt an den HM1500 dranstellen. In den FAQs steht noch, dass es bis zu einer halben Stunde dauern kann, bis der HM antwortet, ist diese Info noch aktuell ? So lang hab ich bislang nämloch nicht gewartet in direkter Nähe zum HM. Aktuell ist das Board in etwa 5m Abstand mit einer Aussenwand dazwischen.

[Ollipop030]

Du hast dir ja aber jetzt das Wissen angeeignet eine DTU selbst zusammenzustecken. Ich würde an der Stelle einen 8266 und das NRF Modul kaufen und von vorne anfangen. Ist ja schnell gemacht. Dem Ebay Heini würde ich seinen überteuerten Elektroschrott wieder zuschicken.

[killamilla0815]

Wo krieg ich eigentlich ein passenden OpenDTU build für mein Setup her, falls es mit Ahoy weiterhin nicht klappen will ? Dann würd ichs morgen mal mit OpenDTU probieren.

[MaxDaNr1]

Hi Ich habe interessiert mitgelesen. Ich komme eigtl von OpenDTU und weil ich mit OpenDTU keine Daten von meinem HM-1500 empfangen kann, wollte ich es mal mit Ahoy probieren. @killamilla0815 du musst oben in der Suche einfach nach OpenDTU von tbnobody suchen. Die Dokumentation ist echt gut und es gibt sogar Videos auf Youtube. Das Compilen ist etwas komplizierter als hier mit Ahoy über die Homepage von Ahoy, aber auch ich als totaler Noob habe es hinbekommen. Zumindest "hinbekommen" mit der Verbindung zu meinem eigenen WLan, aber Kommunikation zum WR klappt weder über OpenDTU noch mit Ahoy. Hier mal ein Auszug von Putty:

[ 3837][E][WiFiGeneric.cpp:1476] hostByName(): DNS Failed for I: MQTT disconnected, reason: TCP disconnect I: [NTP]: 2023-02-15 08:43:07 UTC I: resetPayload: id: 0 I: (#0) enqueuedCmd: 1 I: (#0) enqueuedCmd: 11 I: (#0) enqueuedCmd: 5 I: (#0) sendTimePacket I: sendTimePacket 1 I: TX 27B Ch40 | 15 74 40 40 70 82 07 13 04 80 01 00 63 EC 9B 32 00 00 00 00 00 00 00 00 2E 7D 77 W: while retrieving data: last frame missing: Request Retransmit I: (#0) sendTimePacket I: sendTimePacket 1 I: TX 27B Ch61 | 15 74 40 40 70 82 07 13 04 80 01 00 63 EC 9B 32 00 00 00 00 00 00 00 00 2E 7D 77 W: while retrieving data: last frame missing: Request Retransmit I: (#0) sendTimePacket I: sendTimePacket 1 I: TX 27B Ch75 | 15 74 40 40 70 82 07 13 04 80 01 00 63 EC 9B 32 00 00 00 00 00 00 00 00 2E 7D 77 W: while retrieving data: last frame missing: Request Retransmit

Irgendwie glaube ich mittlerweile, dass vielleicht die angegebene Seriennummer meines HM-1500 nicht stimmt. Also wenn ich einfach ein paar Zahlen in der Seriennummer ändere, passiert in der Console immer das gleiche. Ich habe alle möglichen Entfernungen ausprobiert. Ich habe verschiedene Versionen (seit November) ausprobiert. Ich habe in OpenDTU verschiedene Sendeleistungen eingestellt und ich habe verschiedene nRF-Module probiert. Bislang alles ohne Erfolg.

[killamilla0815]

Hallo @MaxDaNr1 Sehr intressant, erspart es mir doch den Umweg, es nochmal mit OpenDTU zu probieren. Sourcen kompilieren, damit möcht ich mich absolut nicht rumschlagen, wenn es fertige .bins schon gibt. Aber dann kann ich mir auch das sparen. Meine logs sehn ein wenig anders aus, wie du an dem screenshot oben sehn kann, hab ich nach Stunden im Betrieb unter System --> Radio die Info, dass einige tasuend Pakete gesendet wurden (Tx) aber der HM1500 antwortet einfach nicht, unter Rx steht null. Dabei hab ich auch alles mögliche ausprobiert, alle möglichen SW Versionen etc.

Bisher hatte ich auf es auf die HW geschoben, habe meinen ESP32 "fertig aufgebaut" mit Display auf kleinanzeigen geholt, aber wenn du schreibst, dass du es auch mit anderer HW ohne Erfolg probiert hast, geht mein Verdacht mittlerweile eher auf den Hoymiles, Möglw. gibt es Modelle bzw. FW Versionen, die nicht zurückfunken, weil sie ggf. mit einem anderen Funkmodul arbeiten ? Ist sowas denkbar ? Den Hoymlies offnen, möchte ich ungern, weil man das Garantiesigel entfernen muss.

Eine Möglichkeit wäre noch, die DTU (Lite) zu Testzwecken zu ordern um wenigstens die FW Version des Hoymiles auszulesen. Aber selbst wenn man die dann wüsste, was würde es helfen ?

Darf ich fragen von welchem Händler du deinen HM1500 hast ?

[MiniOh]

@MaxDaNr1

Ich denke hier lohnt es sich nicht OpenDTU bzw. unterschiedliche Versionen von Ahoy zu testen. Beide sollten Problemlos mit dem Inverter kommunizieren können.

Bzgl. SN hat dir der Händler die SN auf der Rechnung oder so übermittelt, oder hast du selbst die eingetragen, die auf dem Wechselrichter steht?

[killamilla0815]

@MiniOh Soweit die Theorie. Sollten. Aber wie man sieht, tun sies nicht, offenbar nicht nur bei mir, das lässt wenigstens einen Fehler auf meiner Seite unwahrscheinlicher erscheinen. Und bisher konnte mir noch keiner verraten, warum ?

[MaxDaNr1]

Ich habe die SN genommen, die auf der Rückseite meines HM-1500 stehen. Die SN ist dort zweimal mit Aufkleber angebracht. Der Händler hat mir keine SN genannt. Ich habe meinen WR bei offgridtec im Juni2022 bestellt. Der lief seitdem auch durch. Ich habe aber erst im November mit OpenDTU rumprobiert. Ich dachte vielleicht liegt es daran, dass der WR seit Juni durchläuft, aber auch ein "Neustart" des WR hilft nicht weiter. Ich glaube ich habe mittlerweile echt alles probiert. Ich würde es gerne mal mit einem anderen WR probieren. Die original DTU zu testen wäre eigtl auch noch eine gute Idee.

Achso meine Ausgabe stammt von Putty. Hier die Ausgabe aus der Console: 12:43:17 I: (#0) sendTimePacket 12:43:17 I: sendTimePacket 5 12:43:17 I: TX 27B Ch75 | 15 74 40 40 71 82 07 13 04 80 05 00 63 ec c5 52 00 00 00 00 00 00 00 00 5c b2 f1 12:43:19 W: while retrieving data: last frame missing: Request Retransmit 12:43:19 I: (#0) sendTimePacket 12:43:19 I: sendTimePacket 5 12:43:19 I: TX 27B Ch3 | 15 74 40 40 71 82 07 13 04 80 05 00 63 ec c5 52 00 00 00 00 00 00 00 00 5c b2 f1 12:43:21 W: while retrieving data: last frame missing: Request Retransmit 12:43:21 I: (#0) sendTimePacket 12:43:21 I: sendTimePacket 5 12:43:21 I: TX 27B Ch23 | 15 74 40 40 71 82 07 13 04 80 05 00 63 ec c5 52 00 00 00 00 00 00 00 00 5c b2 f1 12:43:24 W: while retrieving data: last frame missing: Request Retransmit 12:43:24 I: (#0) sendTimePacket 12:43:24 I: sendTimePacket 5 12:43:24 I: TX 27B Ch40 | 15 74 40 40 71 82 07 13 04 80 05 00 63 ec c5 52 00 00 00 00 00 00 00 00 5c b2 f1

@killamilla0815 du hast recht, bei dir steht immer "nothing received" bei mir scheint doch irgendetwas anzukommen. Ich glaube aber, dass es vielleicht vom Shelly Plug S kommt. Weil die Console das gleiche ausspuckt, wenn ich die Seriennummer beliebig ändere.

[Argafal]

So war es bei mir am Anfang auch, da hab ich echt lange gesucht. Genau wie du erst alles andere vermutet, WR, Seriennummer, Software.

Bei mir war am Ende die Lösung andere Pins für die Kommunikation mit dem NRF24 Modul zu benutzen. Konkret bin ich von D4 -> D1 und D3 -> D2 gegangen. Dann hat alles magisch direkt funktioniert. Vielleicht einen Versuch wert?

[MaxDaNr1]

Achso, ich verwende ein ESP32 devkit von Berrybase und das nRF+ Modul mit Antenna auf der Platine. Ich würde es hinbekommen die Pin Belegung anzupassen, wenn man mir sagt welche Pin-Belegung ich beim ESP32 noch ausprobieren kann.

[killamilla0815]

Also ich hab jetzt mal ganz banal CE(D4) und IRG(Rx) auf meinem Board einfach gegeneinander getauscht, ebenso die GPIO settings im Menü (was vorher GPIO4 war ist jetzt GPIO16 und umgekehrt), Ergebnis: NÜSCHT. Nach wie vor keine Antwort.

[killamilla0815]

Gibt es irgendwo ne Doku, welche GPIO Pins aus dem Menü der Pinout Beschriftung auf meinen ESP32 Board entsprechen ?

--> https://ibb.co/3Fm87ND

Dann würde ich sie alle nacheinander ausprobieren, momentan ist das irgendwie Fischen im Trüben...

[Ollipop030]

Das hier?: https://circuits4you.com/2018/12/31/esp32-devkit-esp32-wroom-gpio-pinout/

[killamilla0815]

Ja, das wäre dann das pinout. Allerdings hab ich auf Basis dessen nun versch. GPIOs für CE und IRQ ausprobiert und auch im Menü jeweils geändert, alles ohne Erfolg.

Denke ich werde die Hardware tauschen müssen und falls es dann mit neuer HW geht, ist das Mindestes was es für den Verkäufer gibt, eine Meldung bei kleinanzeigen wegen schwunghaftem Handel mit den Dingern als privater Verkäufer, mal sehn ob sich das Finanzamt für den intressiert. Nicht falsch verstehn, vielleicht kann er ja nichts dafür und hat schon etliche von den Dingern ohne Probleme verkauft, bloss wenn ich nun mittlerweile Stunden an Arbeit erfolglos da reingesteckt habe, ist das Mindeste, was ich erwarte, dass er das Ding zurücknimmt und mir mein Geld erstattet, zumal ich vermutlich eh zu viel dafür bezahlt habe (knapp 50,- mit 1,3" Display und ein bisschen 3D Druck drumherum, innen ein Heisskleberverhau).

[MaxDaNr1]

Also ich habe jetzt mal im Internet ein fertiges OpenDTU gekauft. Angeschlossen, konfiguriert und ZACK ich hatte Daten vom WR. Ich kann also ausschließen, dass es am WR, Netzteil oder USB kabel liegt. Dann habe ich das gekaufte OpenDTU-Set auseinander gebastelt und nach und nach die Komponenten gegen meine ausgetauscht. Ich habe sogar die Jumper-Kabel getauscht. Ich kann jetzt sagen, dass es bei mir definitiv am nRF+ modul lag. Mein Aufbau und der gekaufte Aufbau funktionieren nur mit dem nRF-Modul vom gekauften Set. Sowohl OpenDTU und Ahoy laufen jetzt!

Hier mal ein Foto beider nRF Module. Beide haben ein Plus und einen Punkt (kein Viereck) auf dem Chip. Das Linke auf dem Foto ist das NICHT funktionierende Modul und das rechte das nachträglich gekaufte funktionierende Modul. Einzelne Bauteile sind unterschiedlich. Leider schafft mein Handy es nicht eine besser fokussierte Aufnahme zu machen. Ich hoffe, dass meine Erkenntnisse hier vielleicht weiterhelfen. Bei mir war es jetzt das dritte nRF+ Modul das ich probiert hatte. Scheinbar gibt es wirklich sehr viel Mist im Internet zu kaufen.

[lumapu]

danke fürs teilen deiner Erfahrung. Schade dass der Weg so lange war, aber immerhin mit gutem Ausgang.

[killamilla0815]

Wollte schon hinschmeissen nach zig Stunden weiterer Fehlersuche heute, aber nun bin tatsächlich noch am Ziel angekommen: hab exakt dasselbe NRF+ Modul wie du oben verwendet und direkt an den ESP32 gesteckt mit Standardsettings, lief weiterhin nicht, obwohl man zT schon Rx Pakete in Logs sehn konnte, aber es kam keine Kommunikation zustande. Alle Tests heute liefen noch auf der alten 0.5.85 und als letzte Maßnahme bin ich eben auf die letzte 0.5.90 developer gegangen und siehe da: läuft auf Anhieb !
Hätte es nicht mehr für möglich gehalten. Jetzt werd ichs nochmal mit dem NRF Modul versuchen, das anfangs dabei war und wenn das nach wie vor nicht tut, kriegt der Verkäufer es direkt an den Kopf geworfen zusammen mit ner Rechnung in Höhe eines kompletten Arbeitstags, den ich bislang in die Fehlersuche gesteckt hab ,-)
Passenderweise hat er seine Anzeige mittlerweile gelöscht, vielleicht gabs ja noch mehr Beschwerden...

[MaxDaNr1]

Super, freut mich für dich! Ich kann das voll nachvollziehen, da ich auch soviele Stunden in die Fehlersuche gesteckt habe. Mich würde mal interessieren ob es mit dem anfangs NRF-Modul auch funktioniert oder nicht. Kannst ja auch mal deine beiden Module nebeneinander abfotografieren. Ich denke das könnte vielen nach uns die Fehlersuche einfachen machen.

[Huefti]

Ich habe das gleiche Problem auf dem esp8266 230206_ahoy_0.5.81_75539c5_esp8266.bin geflashed und dann Dauerlicht auf der blauen LED und keine Antwort vom Inverter. Bei der .78 leuchtet die LED nur beim Senden des NRF- Serienfensters im Web schreibt keine Fehlermeldung, nur dass er keine Antwort bekommt. Senden findet statt. Downgrade auf .78 und alles geht wieder.

Hi, ich bin völlig neu auf dem Gebiet und habe das gleiche Problem mit der Kommunikation mit dem We bin im Internet auf Spurensuche gegangen. Ich konnte nur das

Bei mir ist das Gleiche, beide Wechselrichter sind „nicht verfügbar“. Hab ein Downgrade auf 0.5.78 gemacht, dann geht es wieder.

Hallo, ich bin völlig neu hier und alles andere als ein Programmierer. Ich habe das gleiche Problem mit dem nicht erreichen des Wechselrichters. Wie und wo bekomme ich denn die Version 0.5.78 (als .bin zum update???). Sorry, wie gesagt, ich kenne mich damit nicht aus.