Closed stefan123t closed 2 years ago
Ich bin da komplett offen, meine Hardware steht und ich bin damit zufrieden. Wahrscheinlich gibt es hier andere, die sich mehr um die Hardware kümmern, ich sehe mich eher in der Software Ecke.
I second this suggestion. I did not receive any communication from the inverter when using D4 and D3. As soon as I changed these two pins to D2 and D1 the communication started to work. I am using a Wemos D1 mini V3.
@Argafal I have 0.4.15 with the improved and optimized IRQ/Interrupt Handler running since almost 2 days without resets. I would therefor prefer to close this issue and leave documentation as it is. Would you kindly double check your cabling with the latest version of the ESP code ?
ich nutze einen wemos d1 mini und einem nrf modul mit externer antenne und habe mit obriger verkablung keinerlei rückmeldungem vom wr bekommen. nach tausch der pinbelegung von IRQ und CE bekomme ich nun endlich Datenpakete vom wr zurück.
+-----------+ +-----------+
| ESP8266 |--colour--| nRF24L01+ |
| | | |
| GND |---black--|[GND] |
| +3.3V |----red---| VCC |
| D3 |---grey---| CE |
| D8 |--purple--| CSN |
| D5 |---blue---| SCK |
| D7 |---green--| MOSI |
| D6 |---brown--| MISO |
| D4 |--yellow--| IRQ |
+-----------+ +-----------+
Good to hear of the improvement! I am afraid I cannot change the physical cabling right now, since I cannot access the hardware at the moment.
How is it for @TobiDD79, would you be able to check if the new code works for you with the original cabling (CE=D4, IRQ=D3)? It looks like we are using the same hardware and have the same problem.
@Argafal I have a WeMos D1 mini Pro around but I can't seem to find the nRF24L01+ modules with external PA Antenna, which I bought for this purpose at the moment. So my current setup is using a Lolin NodeMCU v0.1 and its working fine. I did not even add a capacitor to the module nor did I shield it using aluminium foil.
@TobiDD79 wäre interessant zu wissen, ob die Original Schaltung bei Dir mit der 0.4.15/0.4.17 auch funktioniert ? Ich konnte bisher keine Begründung finden, warum die nicht tun sollte. Daher vermute ich es hängt eher mit den fehlerhaften Settings nach dem Erase EEPROM o.a. in der Zwischenzeit behobenen TX/RX Problemen zusammen.
@lumapu was ist denn der Default in der 0.4.17 ? Ich habe das hier in der defines.h gefunden:
//-------------------------------------
// PINOUT (Default, can be changed in setup)
//-------------------------------------
#define RF24_CS_PIN 15
#define RF24_CE_PIN 2
#define RF24_IRQ_PIN 0
Hier noch zwei Referenzen für die Anbindung der ESP8266 GPIOs generell
ESP8266 Pinout Reference: Which GPIO pins should you use? https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/
Label | GPIO | Input | Output | Notes | Ahoy |
---|---|---|---|---|---|
D0 | GPIO16 | no interrupt | no PWM or I2C support | HIGH at boot, used to wake up from deep sleep | |
D1 | GPIO5 | OK | OK | often used as SCL (I2C) | |
D2 | GPIO4 | OK | OK | often used as SDA (I2C) | |
D3 | GPIO0 | pulled up | OK | connected to FLASH button, boot fails if pulled LOW | IRQ |
D4 | GPIO2 | pulled up | OK | HIGH at boot, connected to on-board LED, boot fails if pulled LOW | CE |
D5 | GPIO14 | OK | OK | SPI (SCLK) | SCK |
D6 | GPIO12 | OK | OK | SPI (MISO) | MISO |
D7 | GPIO13 | OK | OK | SPI (MOSI) | MOSI |
D8 | GPIO15 | pulled to GND | OK | SPI (CS), Boot fails if pulled HIGH | CSN |
RX | GPIO3 | OK | RX pin | HIGH at boot | |
TX | GPIO1 | TX pin | OK | HIGH at boot, debug output at boot, boot fails if pulled LOW | |
A0 | ADC0 | Analog Input | X |
Pinout | (Wemos) |
---|---|
CSN | D8 (GPIO15) |
CE | D4 (GPIO2) |
IRQ | D3 (GPIO0) |
Und einzelner Boards im Speziellen
ESP8266 und ESP8285 Module Anleitung - Module und Boards http://stefanfrings.de/esp8266/
Ich muß das mal ordnen und mir genauer ansehen, welche PINs / GPIOs am sinnvollsten sind.
Speziell #79 weist auch auf das Problem hin, daß an D4 / GPIO2 sowohl die blaue LED als auch der Serial Port beim Booten hängt:
Beim Booten serieller Ausgang, darf dabei nicht auf LOW gezogen werden. Kann nach dem Booten als normaler I/O Pin verwendet werden. Ist mit der blauen LED verbunden, die bei LOW Pegel leuchtet. Hat 12 kΩ Pull-Up Widerstand.
Version 0.4.19 braucht wieder mal / immer noch die Basic Settings:
02:26:46.624 -> I: connect to network 'YOUR_WIFI_SSID' ...
02:26:46.723 -> ...............................
02:26:51.474 -> I: RF24 Amp Pwr: RF24_PA_MIN
02:26:51.474 -> I: Radio Config:
02:26:51.474 -> SPI Frequency = 1 Mhz
02:26:51.474 -> Channel = 0 (~ 2400 MHz)
02:26:51.474 -> RF Data Rate = 1 MBPS
02:26:51.474 -> RF Power Amplifier = PA_MIN
02:26:51.474 -> RF Low Noise Amplifier = Disabled
02:26:51.474 -> CRC Length = Disabled
02:26:51.474 -> Address Length = 2 bytes
02:26:51.474 -> Static Payload Length = 32 bytes
02:26:51.474 -> Auto Retry Delay = 250 microseconds
02:26:51.507 -> Auto Retry Attempts = 0 maximum
02:26:51.507 -> Packets lost on
02:26:51.507 -> current channel = 0
02:26:51.507 -> Retry attempts made for
02:26:51.507 -> last transmission = 0
02:26:51.507 -> Multicast = Disabled
02:26:51.507 -> Custom ACK Payload = Disabled
02:26:51.507 -> Dynamic Payloads = Disabled
02:26:51.507 -> Auto Acknowledgment = Disabled
02:26:51.507 -> Primary Mode = TX
02:26:51.507 -> TX address = 0x0000000000
02:26:51.507 -> pipe 0 (closed) bound = 0x0000000000
02:26:51.507 -> pipe 1 (closed) bound = 0x0000000000
02:26:51.540 -> pipe 2 (closed) bound = 0x00
02:26:51.540 -> pipe 3 (closed) bound = 0x00
02:26:51.540 -> pipe 4 (closed) bound = 0x00
02:26:51.540 -> pipe 5 (closed) bound = 0x00
02:26:51.540 -> W: WARNING! your NRF24 module can't be reached, check the wiring
02:26:51.540 -> I:
02:26:51.540 ->
02:26:51.540 -> ----------------------------------------
02:26:51.540 -> I: Welcome to AHOY!
02:26:51.540 -> I:
02:26:51.540 -> point your browser to http://192.168.X.Y
02:26:51.540 -> I: to configure your device
02:26:51.540 -> I: ----------------------------------------
Setup
Pinout (Wemos) CS: D8 (GPIO15) CE: D4 (GPIO2) IRQ: D3 (GPIO0)
Reboot device after successful save [x] Save
+-----------+ +-----------+ | ESP8266 |--colour--| nRF24L01+ | | | | | | GND |---black--|[GND] | | +3.3V |----red---| VCC | | D3 |---grey---| CE | | D8 |--purple--| CSN | | D5 |---blue---| SCK | | D7 |---green--| MOSI | | D6 |---brown--| MISO | | D4 |--yellow--| IRQ | +-----------+ +-----------+
mit dieser Belegung klappt es auch bei mir und war so frei es gleich als neuen Standard (Vorgabe nach Reset, kann individuell geändert werden) in die Firmware zu integrieren.
Können wir auch die printDetails()
als Debug Output verwenden ?
Hier wird zusätzlich das NRF24 model ausgegeben:
https://nrf24.github.io/RF24/RF24_8cpp_source.html#l00684
printf_P(PSTR("Model\t\t= "
PRIPSTR
"\r\n"), (char *)(pgm_read_ptr(&rf24_model_e_str_P[isPVariant]()])));
printPrettyDetails()
hat interessanterweise keine Model Angabe.
Es könnte helfen fehlerhafte Modelle wie nrf24l01 anstelle von nrf24l01+ zu identifizieren.
Alternativ sollten wir isPVariant()
aufrufen um die Plus-Variante zu prüfen.
Der Raspberry Pi code hat bereits einen Check mit isPVariant()
, es fehlt also nur im ESP8266 code.
sehr gut, das klingt sinnvoll, evtl. können wir gleich eine aussagekräftige Nachricht auf der index.html hinterlassen falls wir denken, das es nicht funktionieren kann.
Die Änderung in defines.h muss noch dokumentiert werden:
https://github.com/grindylow/ahoy/blob/main/tools/esp8266/defines.h#L11-L16
Ich weiß nicht, ob meine letzte Änderung hier zu mehr Verwirrung geführt hat. Ich hatte nur den Kommentar von @TobiDD79 gelesen und meinen Aufbau von einem ESP-07 auf einen Wemos-D1-mini umgebaut. Ich habe es gleich so verdrahtet und es hat auch bei mir auf Anhieb geklappt - während das alte Pinout nicht bei allen klappt.
Hallo Lukas, wir müssen entweder die ganzen Schematics anpassen und die Platinen von Holger u.a. "umlöten" / umkonfigurieren oder die beiden Zeilen in der defines.h wieder ändern... Weiß auch nicht was weniger Irritationen und Aufwand verursacht. Ist halt so mit breaking changes / news 😃 Bei mir läuft es auf dem NodeMCU mit der alten Konfiguration schon mehrere Tage lang, ich kann mich an ca. 5 Tage erinnern, bevor ich eine aktuellere Version geflasht habe und rebooten musste.
Ich würde ein revert auf die alte config vorschlagen. Das macht viel mehr Sinn, ich hatte nicht auf den Schirm, dass schon so viel davon abhängig ist. Manchmal sind meine Scheuklappen aber auch nicht schlecht ;-P
Do they have to resolder? Isn't it sufficient to just update the configuration to the pins actually used? Whereas anyone who actually HAS problems with the default pin layout actually DOES have to physically change the connections.
What I dislike about the old defaults is that they cause problems in a number of documented cases. This might make it hard for newcomers to get started: imagine you just put the hardware together, flash the software the first time, and now you don't get any response from the inverters. It will take a long time to identify that the cause of the problem is the default pin layout, and not anything YOU got accidentally wrong with the inverter serials, version of the RF module, etc.. I remember that I nearly gave up after three hours when trying it the first time, until I re-soldered from the default pins to an alternative pin layout and everything just magically worked all of a sudden. I feel that this initial hurdle could have been easily avoided with a different default. Am I wrong?
Alternative suggestion, could there at least be a sentence in the documentation? Something on the lines of "If you do not get any response from the inverters, try swapping pins D4 and D3 for D2 and D1, both physically and in the software configuration. Using pins D4 and D3 caused problems for some users in the past depending on their individual hardware choices."
Everyone has the ability to contribute even to the documentation ;-)
I think we should discuss here a little bit the pros and cons before changing anything. I soldered only once using the changed Pinout. It started working immediately so I decided to make it the new default.
CS - D8 (GPIO 15) CE - D3 (GPIO 0) IRQ - D4 (GPIO 2)
I had it up and running with the old Pin out for ages. So I do not know why it would give troubles to some. Can those that claim it gives troubles in the old config give some hints on why that would fail and why the new is different and works. As I tried to make a case with the pins that are usable for IRQ according to the above table only GPIO16 is not usable for interrupts. I think that it should be backwards compatible in case we make changes, otherwise those having already etched their boards have to fix the setting for each software update. So if you can make a strong case that really shows it works one way and it does not work the other way around I am more than willing to change the documentation. But until now I have only read reports that someone tried it either way and it worked. But none (including myself) has proven / verified that it does (or does not) work both ways.
@stefan123t I tried it first with the old default pin layout and could not get it to work no matter what I did: The software reported a successful connection to the RF module, but I never got any data whatsoever from the inverters. At that stage the software was still highly experimental, so I suspected that my inverter types could have been different and tried and tried and tried on the software side.
Eventually I found the solution hidden in a post on the mikrocontroller forum by Olaf A. He wrote:
"Hatte mir das NRF24LE01+ mit externer Antenne gekauft und einige D1 mini V3, hatte jedoch nie Empfang. Kaufte verschiedene NRF24LE01+ und testete alle möglichen Kombinationen durch. Erst als ich D3 und D4 auf D1 und D2 umverdrahtete, mit der entsprechenden Setup-Änderung, konnte ich problemlos alles empfangen."
Once I found this post I resoldered to D2 and D1, and I immediately got responses from the inverters without touching the software (well, except for updating the pinout configuration of course).
As to why it fails with D4 for some and not for others, I couldn't say. One interesting bit is that both Olaf A and I use the Wemos D3 mini version 3. Maybe it's connected to the blue LED on D4 and the D1 mini v3 in particular?
Everyone has the ability to contribute even to the documentation ;-)
Let's first see if what we come up with in this discussion. If it is decided that the old pin layout stays as it is I would indeed be happy to propose a sentence or two for the documentation. That would at least give new users that encounter the same problems that Olaf A and I had some ideas what they could try. If the default pin layout changes then such a sentence in the documentation is of course not needed at all.
Interesting Point: Are there different versions of Wemos D1 mini? On mine the is no printed version, I ordered one from AZ delivery.
I knew already that GPIO16 hasn't interrupt capabilities, I figured it out several years ago. My idea regarding the Interrupts in this project is the RF24 Library, because it maybe die not use the interrupt capabilities correct. I already discuss with @stefan123t how we move further in another issue #83 here. Once this is solved we should try all the points and make a decision.
Maybe we can think of some auto detect or setup assistant on a fresh installation.
I had the same issue, switching to D1=CE and D2=IRQ fixed it. Also the default pinout in the graphic is CE=D4, IRQ=D3, but the default config in the code is switched CE=D3, IRQ=D4
Ich habe alle Pinouts durchprobiert, mit keiner ist die Kommunikation zum Inverter erfolgreich.
das zuletzt getestete Pinout: CS -> D8 (GPIO15) CE -> D1 (GPIO5) IRQ -> D2 (GPIO4)
Inverter am Netz angeschlossen und via Labornetzgerät am DC-Eingang versorgt -> grüne LED blinkt im 4-Sekunden Takt für "keine Kommunikation zum DTU".
Statistics:
Receive success: 0 Receive fail: 104 Frames received: 0 Send Cnt: 310
Inverter 'HM400_0' is not available and is not producing MQTT: not connected
Serielle Konsole:
.....
I: [NTP]: 2022-07-09 14:23:21 I: Inverter #0 I: no Payload received! (retransmits: 0) I: Requesting Inverter SN 1121xxxxxxxxx I: Transmit 27 | 15 80 13 35 19 78 56 34 12 80 0B 00 62 C9 8F 59 00 00 00 05 00 00 00 00 99 67 AF E: while retrieving data: last frame missing: Request Retransmit I: Transmit 27 | 15 80 13 35 19 78 56 34 12 80 0B 00 62 C9 8F 59 00 00 00 05 00 00 00 00 99 67 AF E: while retrieving data: last frame missing: Request Retransmit I: Transmit 27 | 15 80 13 35 19 78 56 34 12 80 0B 00 62 C9 8F 59 00 00 00 05 00 00 00 00 99 67 AF I: Inverter #0 I: no Payload received! (retransmits: 2) .... etc.
Was könnte das noch sein?
@billy0xff,
I: Requesting Inverter SN 1121xxxxxxxxx I: Transmit 27 | ... 80 13 35 19 ...
Deine Seriennummer dürfte also 112180133519 sein. Es ist ungewöhnlich eine Seriennummer mit 80 am Anfang zu haben. Ich habe in unserer Liste bisher nur Seriennummern mit 112163..112174 für die 1121-Modelle. Ich meine irgendwo im Sourcecode gelesen zu haben, daß die ersten Stellen der Seriennummer dem Baujahr entsprechen ?
edit: In https://www.mikrocontroller.net/attachment/559626/Micro-inverse_system_related_product_ID_coding_rules-A3-20190712.docx steht es:
2. Last eight coding rules For products such as micro-inverters, DTUs, repeaters, etc., the rules are as follows: The 5th to 12th digits are the production serial number and are used as the RF communication address of the micro-inverter/DTU/repeater, among which: The "5" digit is the year of production (time provided by the welder), the "1" is for 2015, and so on The "6~7" bits are the production week (the time provided by the welding factory), and the range is "1~52". The "8~12" bits are the pipeline coding (currently in decimal), the micro-inverter, repeater, and DTU share the same pipeline sequence, which is coded in sequence and must not be repeated, a total of 99999 bits.
11218****0133519 entspricht dem Baujahr 8=2022 (1=2015) und KW01, also erste Januar Woche 2022.
Vielleicht hast Du auch eine neuere Firmware auf dem Wechselrichter ?
E: while retrieving data: last frame missing: Request Retransmit
Er bekommt keine Pakete vom Wechselrichter als Antwort übermittelt. Stimmt das Präfix 1121 oder hat Dein HM-400 ein anderes Präfix ?
@permissionBRICK yes, we know that there is a mismatch between documentation and code right now (since v0.4.20-0.4.22 at least). Could you specify the Wemos D1 model you are using and could you retry with the D3/D4 connection but matching config in the settings ?
Are there different versions of Wemos D1 mini?
@lumapu yes there are at least three different models (mini, lite and pro) and several versions according to Stefan Frings page:
Das Wemos D1 Mini Board gibt es in folgenden Versionen:
Version | ESP Chip | Flash MByte | LED an GPIO2 | Antenne | Lithium Laderegler |
---|---|---|---|---|---|
Wemos D1 Mini Lite v1 | ESP8285 | 1 | ja | Leiterschleife | nein |
Wemos D1 Mini v2 | ESP-12 Modul (=ESP8266) | 4 | nein | Leiterschleife | nein |
Wemos D1 Mini v3 | ESP8266 | 4 | ja | Leiterschleife | nein |
Wemos D1 Mini Pro v1 (oder -16) | ESP8266 | 16 | ja | Keramikantenne und ext. Antennenanschluss | nein |
Wemos D1 Mini Pro v2 | ESP8266 | 16 | ja | Keramikantenne und ext. Antennenanschluss | ja |
Die oberen vier Boards haben die gleichen Abmessungen, das letzte mit Laderegler ist etwas länger. Alle Versionen haben einen USB-UART (CH-340) und einem Low-Drop Spannungsregler. Alle freien I/O Pins des ESP Chips sind herausgeführt, aber nicht der CHIP_EN Pin.
@stefan123t I did that originally, but no matter how I set the config it didnt work. pic its a v2... i think?
ESP8266 bei mir 4 MB Flash
@permissionBRICK
I did that originally, but no matter how I set the config it didnt work. pic its a v2... i think?
I can barely read the fine print on the chip picture. Does it say EPS8266 or ESP8285 ? Are you setting 4MB flash in the IDE and it compiles and flashes fine ? What does it show on the back / reverse side any more fineprint ?
It says 8266, so according to the table above it should be 4mb?
Also the default pinout in the graphic is CE=D4, IRQ=D3, but the default config in the code is switched CE=D3, IRQ=D4
Reverted the default settings to CE=D4 and IRQ=D3 so it matches the pinout diagrams for the time being.
ich nutze seit eh und je ESPs mit mind. 4MB Flash und erachte das quasi als Standard und min. Meistens habe ich die D1 mini Pro mit 16Mb
@stefan123t ja, exakt das ist die s/n, der Inverter ist vom Mai, da hat ihn auch der Händler erst bekommen. Präfix 1121 passt.
@permissionBRICK I wired the communication module directly to a ESP12-F without any carrier board:
D1 mini ESP12F NRF24L01+ SMD
D1 GOIO5 CE 3 D2 GPIO4 IRQ 8
D5 GPIO14 SCK 5 D6 GPIO12 MISO 7 D7 GPIO13 MOSI 6 D8 GPIO15 CS 4 3V3 Vcc Vcc 1 G GND GND 2
GPIO15 -> Pulldown ca. 10k EN -> Pullup ca. 10k GPIO0 -> Pulldown ca. 10k (optional)
Flashen:
GPIO0 -> GND RST -> HI->LO->HI ... flashen RST -> HI->LO->HI
Hier sind alle Signale am ESP12F zum NRF, Verdrahtungsfehler sollte keiner vorliegen:
Hallo @billy0xff anscheinend kommuniziert der ESP8266 ja mit Deinem NRF24 Chip was sich an den MISO/MOSI Daten auf Deinem SPI erkennen lässt. Vielleicht versuchst Du mal die TX/RX Channel wie von Ziyat T. vorgeschlagen anders einzustellen ? Offenbar haben manche Wechselrichter eine (temporäre?) Präferenz für bestimmte Sende/Empfangskanäle.
Da Du schon den ganzen Messaufbau mit Oszi/Logic Analyzer vorbereitet hast, könntest Du evtl. auch nochmal eine Messung mit D3/D4 unternehmen ? Da wir in diesem Issue der Anschluss-Kombination D3/D4 am Wemos D1 mini (Pro/Lite) und den Meldungen nach Problemen mit dieser Kombination nachgehen.
Herzlichen Dank im Vorraus.
Hallo @stefan123t; kann ich gerne am kommenden WE machen; Vor der Umlöterei schaue ich mir noch die Kanäle laut deinem Tip an; sehr klar ist mir das nicht, wie das Channelhopping implementiert ist und ob es reicht, einfach alle 5 Kanäle durchzuprobieren. Übrigens, das Diagramm zeigt nur die Kommunikation zum NRF, der Inverter war da gar nicht in Betrieb; ich wüsste auch nicht wie man in dieser Dauerkommunikation eine erfolgte Antwort erkennen könnte bzw. auf was man triggern könnte.
@billy0xff bisher werden bei der Initialisierung der NRF24 Bibliothek die retries mit 15 angegeben. D.h. er versucht alle Requests 16 mal zu schicken. Ich meine auf Seite 2/3 des Forum Threads erste HackRF Aufnahmen von einer DTU Lite o.a. gesehen zu haben bei der ebenfalls 15/16 Retries zu sehen waren. D.h. man sollte bei einigermaßen schnellem Channel Hopping die Responses auch sehen. In der Hoymiles DTU-PRO werden auch entsprechende LOCAL_TIMEOUTs gesetzt je nachdem welches Kommando bzw. welche Antwort erwartet wird. Das liegt m.W. so zwischen 1-2 Sekunden idR. Es gibt aber auch einzelne Kommandos ab 300 ms, das ist m.W das absolute Minimum eines Sende / Empfangsversuches.
Peter S. schrieb im Beitrag #7152099:
Hi Danke für all Eure tolle Vorarbeit, ich stamme aus der Hardware Ecke und mir ist da etwas aufgefallen: Irgendwann verabschieden sich meine beiden dauer-laufenden Installationen gerne mal mit einem watchdog reset (Ursache noch unbekannt) und bleiben hängen. Auch ein manueller Reset behebt dann den Hanger nicht, erst nach einem Power Reset läuft alles wieder. Wenn ich in diesem Fall den Serial Output mit 74880 Bd angucke, dann sehe ich einen falschen Bootloader Mode: ets Jan 8 2013,rst cause:2, boot mode:(1,6) verursacht durch einen LOW Pegel auf GPIO0 = D3 = IRQ vom NRF-Modul. Man sollte also den IRQ besser woanders hinlegen, meine ich.
Hallo Peter S., danke für den Hinweis, wir diskutieren das Problem schon seit geraumer Zeit hier.
Eigentlich war die ursprüngliche Intention die Pins D1/D2 für I2C oder andere zukünftige Anwendungen (ModBus485, etc.) freizuhalten. Gibt es nicht eine einfache Möglichkeit den GPIO0 / D3 beim Booten auf High zu ziehen -> RC-Glied ?
Bisher hatte ich als Grund für die WDT Resets in den dekodierten Exceptions meist ein Problem in umm_malloc ausgemacht. Ich vermute das hängt mit der Nutzung der String-Implementierung im ESP8266 zusammen.
Weiteren Debug Output dazu hier
```text 16:01:55.100 > Request: /setup 16:01:55.100 > Arguments: 16:01:55.100 > final list of key/value pairs: 16:01:55.103 > [String] Reallocating large String(3933 -> 3946 bytes) '
Hallo Lukas, et. al.
Bzgl. der blauen LED auf dem NodeMCU / Wemos D1 mini ist es evtl. keine so gute Idee gewesen den Anschluss D4 (GPIO2) für CE des nRF24 Moduls zu verwenden. Sobald CE low wird leuchtet die blaue LED. Das passiert wohl auch im Falle eines TX per Serial IO.
Soll ich die Fritzing Layouts nochmal anpassen und gibt es eine empfohlene Verdrahtung, bzw. sollten noch andere GPIOs evtl. nicht / anders verwendet werden ? https://www.computerhilfen.de/info/esp8266-blaue-led-ausschalten-oder-blinken-lassen.html
Aktuell ist die Belegung in der getting started ESP8266 Dokumentation: https://github.com/grindylow/ahoy/blob/main/doc/getting-started-ESP8266.md
Wire Connections
@Sprinterfreak, ich habe auch schon Fritzing Layouts für den Raspberry Pi angelegt. Hier ist die IRQ Leitung nicht belegt. Offenbar unterstützt die RF24 Python Bibliothek für den RaspberryPi per pigpio auch IRQs aber das ist default nicht aktiv bzw. noch in Arbeit ?
Sollen wir das Getting Started auch von der Readme.md im Hauptarchiv verlinken, dann kommen evtl. weniger Fragen bzgl. Verkabelung ?