ESP32_dev Austausch

[HomeAutoUser]

Dieses Issues dient zur Zusammenführung von Informationen vom User @Dattel um den Faden RFD-FHEM/SIGNALDuino#130 nicht unnötig in die Länge zu ziehen.

Es werden hier die Dinge zur Änderung via Web getauscht und zu einem PR für das Projekt gebündelt.

[Dattel]

So hier meine Änderungen mit WinMerge generiert.
Kommst du damit klar, ober brauchst du ein anderes Format?

Gruß
D

compile_config.h

75,79d74
< 	#elif ESP32
< 		#define PIN_RECEIVE            5 // D5
< 		#define PIN_LED                2 // D2
< 		#define PIN_SEND               4 // D4  // gdo0Pin TX out
< 		#define ETHERNET_PRINT

signalesp.h

145,152d144
< 
< 	disconnectedEventHandler = WiFi.onStationModeDisconnected([](const WiFiEventStationModeDisconnected & event)
< 	{
< 		Server.stop();
< 		Serial.print("WiFi lost connection. Reason: ");
< 		Serial.println(event);
< 	});
< 
154,162c146,148
< 	
< 	WiFi.onEvent([](WiFiEvent_t event, WiFiEventInfo_t info){
< 		Server.begin();  // start telnet server
< 		Server.setNoDelay(true);
< 	}, WiFiEvent_t::SYSTEM_EVENT_STA_CONNECTED);
< 	
< 
< 	WiFi.onEvent([](WiFiEvent_t event, WiFiEventInfo_t info) {
< 		Server.stop();
---
> 	// TODO: Check why this can't be compiled
> 	/*
> 	WiFiEventId_t eventID = WiFi.onEvent([](WiFiEvent_t event, WiFiEventInfo_t    info) {
164c150
< 		Serial.println(info.sta_er_fail_reason);
---
> 		Serial.println(info.d;
166c152
< 	
---
> 	*/
177c163
< 	esp_timer_start_periodic(blinksos_handle, 300000);
---
> 	esp_timer_start_periodic(blinksos_handle, 300);
398c384
< 	//esp_timer_stop(cronTimer_handle);
---
> 	esp_timer_stop(cronTimer_handle);
429c415
< 	esp_timer_start_periodic(cronTimer_handle, 31000);
---
> 	esp_timer_start_periodic(cronTimer_handle, 31);
451c437
< 	esp_timer_start_periodic(cronTimer_handle, timerTime);
---
> 	esp_timer_start_periodic(cronTimer_handle, timerTime / 1000);

[HomeAutoUser]

Hallo @Dattel
ich denke es richtig übernommen zu haben.
Kannst du bitte beide Dateien noch in das Vormat txt umbenennen und hier mal hochladen?
So kann ich direkt via compare noch einmal gegenprüfen.

[Dattel]

Klar...
habe allerdings gesehen, dass seit meinem PULL bezüglich CC1101 jetzt noch ein paar kleine Änderungen drin sind, die du jetzt natürlich übersehen musst.

compile_config.h.txt
Hier sind ja nur die PINS für den ESP32 dazugekommen. Ob bei allen Boards die LED Pin auf 2 hängt weiß ich jetzt natürlich nicht

signalesp.h.txt

Primäre Änderungen sind in der setup() Funktion. ESP8266 & ESP32 registrieren hier unterschiedlich die beiden WIFI-Events. Beim ESP32 scheint onEvent jetzt generisch alles abzufrühstücken.

Beim Wifi.Disconnect lasse ich den Telnet-Server einfach beenden, wenn WLAN wieder da ist, wird dieser neu gestartet. (Weiß nicht, ob das notwendig ist, aber ich hab das einfach mal so aus der Vorgabe interpretiert)

Zweite Änderung betrifft os_timer_arm vs. esp_timer_start_periodic Soweit ich das gestern gelesen habe, bezieht sich os_timer_arm mit dem Intervall auf Millisekunden, esp_timer_start_periodic will Mikrosekunden.
Selbiges in der Callback-Funktion cronjob: Hier ist das /1000 dann logischerweise unnötig. Hab zwar noch nicht verstanden, woraus sich maxPulse ergibt, aber das wird schon stimmen :-D

[HomeAutoUser]

Ich habe deine Dinge erstmal implementiert.

Gesehen habe ich, du hast auch die Events beim ESP8266 "angegriffen" hast. War dies Absicht?

	disconnectedEventHandler = WiFi.onStationModeDisconnected([](const WiFiEventStationModeDisconnected & event)
	{
		Server.stop();
		Serial.print("WiFi lost connection. Reason: ");
		Serial.println(event);
	});

[Dattel]

Ja... Wenn schon disconnect/reconnect, dann macht das für beide Sinn, oder? Schaden wird es sicher nicht.
Update: Was ich gerade noch sehe: ich printe einfach das "Event" in Richtung Serieller Schnittstelle.. Wahrscheinlich gibt's da eine Membervariable, die man anstelle dessen zurückgeben sollte. So wird wohl nur ein Handle vom Event ausgegeben- was wenig Sinn macht

[HomeAutoUser]

Ich trage derzeit alles hier alles https://github.com/HomeAutoUser/SIGNALDuino/tree/dev-r3.4_plattformIO_ESP32dev zusammen. Es beinhaltet deine Änderungen bis auf das u.g. hier.

Wenn man
Serial.println(event); übernimmt, so geht der Code nicht mehr zu kompilieren bei dem ESP8266.

Meine TEsts belaufen sich immer auf die doppelten Platformen ARDUINO IDE + PlatformIO um dort keinen Fehler hinein zu bringen.

[Dattel]

sehr gut... na das hab ich ja schon befürchtet. das
Serial.println(event); nicht funktionieren wird.

schau doch einfach mal, was dir IntellieSense so anbietet

Serial.println(event.reason);
dürfte gehen..

[HomeAutoUser]

Das sieht schon besser aus.
Das klappt wie du vorgeschlagen hattest.

Wie sind die PINS bei dir auf dem ESP32 beschriftet?

	#elif defined(ESP32)
		#define PIN_RECEIVE            5 // D5
		#define PIN_LED                2 // D2
		#define PIN_SEND               4 // D4  // gdo0Pin TX out
		#define ETHERNET_PRINT

D5 / D2 ... bestimmt nicht ;-) Das würde ich noch anpassen zur Doku. Die fangen ja alle mit G an oder ist es bei deinem Model anders?

[Dattel]

Bei meinem Board stehen die mit D aufgedruckt

[Dattel]

Quick and dirty

[HomeAutoUser]

Sehr interessant, bei meinem nicht.

Da gibt es noch einen Grund mehr nach den Unterschieden zu schauen.

[HomeAutoUser]

Ich habe eine andere Version mit mehr PINs und die haben D durch G ersetzt....

[Dattel]

ja da scheint einiges an Fragmentierung auf dem Markt zu sein.

Deins passt zum offiziellen Espressif ESP32 - DevKitC V4

Mein Pinout scheint identisch mit dem China-Clon DOIT ESP32 DevKit V1 Board zu sein.

Deswegen habe ich bei der PIN-Definition ja auch 4 und nicht D4 oder G4 oder sonstwas genommen. Zum einen, weil es in den ESP32Lib's wohl keine DEFINES dafür gibt??
Wenn du da 4 drin lässt, ist bei mir halt D4 und bei dir G4 gemeint....

Aber ich hab noch zwei andere Frage: wenn ich den ESP vom Strom nehme, dann geht der beim nächsten Reboot erstmal IMMER in den Portalmode (Fehlermeldung "Invalid WLAN-Password"). Drücke ich einmal den EN (oder bei dir RST) Pin, dann verbindet WLAN sauber. Ist das so gewollt, dass der nach PowerLoss erstmal das Portal startet? (Also bevor ich jetzt anfange zu suchen)

Und letzteres: ich hab einen RXB6 verbunden mit einem einfachen 17,4cm Kupferdraht - allerdings lässt die Empfangsreichweite arg zu wünschen übrig. Testweise habe ich den mal anstelle 3.3V mit 5V betrieben und den Data-Pin mit einem Spannungsteiler (1KOhm&2KOhm) an D5 geklemmt. Dann kommt gar kein Signal mehr an. Meine Bestellung (CC1101 & RXB8 & Levelshifter) stecken noch irgendwo auf dem Postweg fest - aber ich befürchte, dass das auch nicht viel besser wird. Zum Thema CC1101 betreibe ich bereits seit längerem einen ESP8266 mit dem blauen CC1101 Modul mit Schraubantenne. Auch hier ist die Reichweite nicht sonderlich gut, aber für meine Thermometer im Wohnzimmer und im Garten reicht es gerade. Hier vermute ich allerdings, dass ich eine 868Mhz Antenne mitgeliefert bekommen habe. Hast du eine Tipp, woran das liegen könnte oder eine Modulempfehlung?

[HomeAutoUser]

Aber ich hab noch zwei andere Frage: wenn ich den ESP vom Strom nehme, dann geht der beim nächsten Reboot erstmal IMMER in den Portalmode (Fehlermeldung "Invalid WLAN-Password"). Drücke ich einmal den EN (oder bei dir RST) Pin, dann verbindet WLAN sauber. Ist das so gewollt, dass der nach PowerLoss erstmal das Portal startet? (Also bevor ich jetzt anfange zu suchen)

Diesen Fehler bzw. das Verhalten muss ich mal reproduzieren.

Thematik Empfang

Da spielt einiges ein. Antennenlänge

• 433MHz λ/4 | 17.31 cm bzw. λ/8 | 8.65 cm
• 868MHz λ/4 | 8.63 cm bzw. λ/8 | 4.32 cm

Du kannst zwecks Empfang auch an der Bandbreite mal "spielen". Es gibt Module welche angeblich etwas mit der Frequenz abweichen. Wie sind deine Umgebungsbedingungen?

Ich habe festgestellt, das der Empfang mit einem CC1101 auf jedenfall besser geht als mit einem "LowBudget" Empfänger.

Ich hatte soeben mal Testweise die FW mit cc1101 auf den ESP geschoben und kämpfe da mit einem
Absturz.

Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC      : 0x4008264b  PS      : 0x00060430  A0      : 0x800827a1  A1      : 0x3ffb1ef0  
A2      : 0x00000000  A3      : 0x3f40494c  A4      : 0x0802a8c0  A5      : 0x3ffc1d18
A6      : 0x000000ff  A7      : 0x00000000  A8      : 0x3ffb79c8  A9      : 0x00000001
A10     : 0x3ffb1f00  A11     : 0x3f40494c  A12     : 0x00000000  A13     : 0x0000ff00  
A14     : 0x00ff0000  A15     : 0xff000000  SAR     : 0x00000018  EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000000  LBEG    : 0x400014fd  LEND    : 0x4000150d  LCOUNT  : 0xffffffff  

Backtrace: 0x4008264b:0x3ffb1ef0 0x4008279e:0x3ffb1f10 0x400df2e6:0x3ffb1f30 0x400e8fcb:0x3ffb1fb0 0x40088c65:0x3ffb1fd0

Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:8896
load:0x40080400,len:5828
entry 0x400806ac



.........................................done
dump

Hattest du dir die Mühe gemacht, schonmal die cc1101 Anbindung heraus zu suchen?
Ich bin mir da momentan unsicher weil es ja mehrere SPI Anschlüsse gibt.

VSPI	GPIO23 (MOSI), GPIO19(MISO), GPIO18(CLK) and GPIO5 (CS)	Used for SPI-1 communication.

[Dattel]

Hattest du dir die Mühe gemacht, schonmal die cc1101 Anbindung heraus zu suchen?
Ich bin mir da momentan unsicher weil es ja mehrere SPI Anschlüsse gibt.

Nein, bis eben noch nicht... Im Detail werde ich das wohl erst machen, wenn mein neuer CC1101 hier eingetroffen ist und ich das direkt testen kann. Vermutlich dann in 2,3 Wochen :-D

Aber laut Google:
SPI1&2 sind sowieso nicht nutzbar, weil intern verwendet - SPI2&3 sind nutzbar.
Bei mir kann GPIO5(CS) nicht stimmen, denn der ist gar nicht rausgeführt. Das müsste bei mir dann D2 sein.

Ich hatte soeben mal Testweise die FW mit cc1101 auf den ESP geschoben und kämpfe da mit einem
Absturz.

Für die Arduino IDE gibt es ein Plugin ESP Exception Decoder. Der fragt nach eine kompilierten ELF Datei und dann kopierst du deinen Backtrace in ein Textfeld und bekommst einen sauber lesbaren Stacktrace ausgegeben, mit dem du dann im Platformio auf Fehlersuche direkt an der auslösenden Codestelle weitermachen kannst. Damit bin ich ja auch auf den esp_timer_stop(cronTimer_handle); aufmerksam geworden.

Du kannst zwecks Empfang auch an der Bandbreite mal "spielen". Es gibt Module welche angeblich etwas mit der Frequenz abweichen.

Mit der Bandbreite spielen? Ich dachte, die billigen Module sind fix...zumindest fehlt mir in FHEM beim SignalESP bei meinem Empfänger die Bandbreitenoption (beim CC1101 kann man das ja einstellen)

Wie sind deine Umgebungsbedingungen?

Empfänger = Fensterbank innen, Sender vl. 6m Sichtweite entfernt im Poolthermometer draußen :-D.
Der mitgelieferte Emfänger geht ohne zu murren, mein ESP ist taub. Jetzt steht der ESP draußen im Schuppen. Das ist zwar die selbe Entfernung zum Pool, aber das Holz scheint nicht so zu schirmen, wie das Haus (auch wenn das ebenfalls Holzständerwerk ist). Ich hoffe auf den CC1101 oder RXB8... ggf. bastel ich mir noch eine einfache Dipol dafür.

Hach jetzt hast du mich direkt angefixt mit dem Debugging und dem CC1101... Ich warte ja auch zusätzlich noch auf mein Debugging-Board für den ESP.... dann geht's mit dem Fehlerfinden vielleicht auch etwas leichter.

[Dattel]

fällt mir gerade so auf: dein Board hat den Wroom32, meins den Wroom32D

[HomeAutoUser]

Hallo @Dattel,
ich hatte mir heute den Code angesehen und den ESP32 mit cc1101 implementiert.
Empfang in FHEM hatte ich & die Register wurden gelesen bzw. gesetzt.

Bitte passe die PIN´s an, sonst geht der cc1101 nicht ;-)

#define PIN_RECEIVE            16 // D16 | G16 (depending on type / clone / seller)
#define PIN_LED                2  // D2  | G2 (depending on type / clone / seller)
#define PIN_SEND               4  // D4  | G4 (depending on type / clone / seller) // gdo0Pin TX out

Das Projekt ist aktuell hier https://github.com/HomeAutoUser/SIGNALDuino/tree/dev-r3.4_plattformIO_ESP32dev

PIN	Definition			Definition
1	VCC	----->		VCC
2	GPIO4	----->		GDO0
3	GPIO16	----->		GDO2
4	GPIO19	----->		MISO	- SPI - BUS
5	GPIO23	----->		MOSI	- SPI - BUS
6	GPIO18	----->		SCLK	- SPI - BUS
7	GPIO5	----->		CSn	- SPI - BUS
8	GND	----->		GND

Weiterhin ist noch die Frage bzw. der Fehler drin, wenn der cc1101 aktiviert ist und die Zeile
//esp_timer_stop(cronTimer_handle); // with cc1101 reset loop
einkommentiert ist, das es eine restart Schleife gibt der Hardware.

[Dattel]

Sauber... das klingt doch gut.
Ja bei der Wahl des GPIO habe ich einfach den erstbesten ohne Rücksicht auf SPI genommen. Super, dass du das gleich mich korrigiert hast.

Was den esp_timer_stop betrifft: Wenn du den Call hierzu aus der Setup-Funktion meinst, dann
ist es klar, dass der zum Reboot führen muss, denn man kann den Timer erst beenden, wenn der vormals auch gestartet wurde. Deshalb ist auch das Handle ungültig. Nimm die Zeile ganz raus, dann ist Ruhe und es zerbrechen sich nicht noch 100 Leute den Kopf, warum die Zeile da auskommentiert steht :-D

Der zweite Call in der Callback Funktion cronjob sollte nicht das Problem sein... Die Funktion wird angesprungen, wenn der Timer abgelaufen ist. Hier ist es legitim, den auslösenden Timer zu beenden und diesen erneut zu starten.

[HomeAutoUser]

Hallo @Dattel ,
soeben haben wir den Support für den ESP32 in die Firmware übernommen.
Nun sollte es funktionieren wenn du deinen Prozessor und dann den cc1101 zusammen steckst :-)

Als Tip, wenn du die aktuellen PIN´s suchst, diese sind ja in der compileConfig Datei vermerkt.

[Dattel]

fein fein...
Derzeit schnurrt der ESP32 jetzt schon ein paar Tage unterbrechnungsfrei und zuverlässig mit einem RXB Sensor draußen im Schuppen...
Bevor ich das nächste mal compiliere, hole ich mir mal die zusammengeführten Quellen aus dem GIT raus.

Was ist das eigentlich für eine dev_r3.5_plattformIO_xFSK branch? Ich finde es schade, dass im Readme solche Erklärungen fehlen, was welche Version für Besonderheiten hat. Mit dem xFSK kann ich nichts anfangen.

[Dattel]

ich denke, wir müssen da in den nächsten Wochen nochmal dran...

functions.h Zeile: 85ff

	#ifdef ESP8266
	EEPROM.commit();
	#endif

und Zeile 119ff

	#ifdef ESP8266
	EEPROM.begin(512); //Max bytes of eeprom to use
	#endif

und Zeile 134ff

#ifdef ESP8266
		EEPROM.commit();
#endif

bedeutet, dass Einstellungen beim ESP32 nicht im Flash gespeichert werden. Hab das gerade mal rausgesucht, denn wenn mein ESP vom Strom genommen wird, muss ich anschließend alle MessageTypes wieder aktivieren..
Laut Doku sollte das aber ebenfalls beim ESP32 so funktionieren. Siehst du einen Grund, warum das auf den ESP8266 beschränkt wird?

[HomeAutoUser]

Ich denke, die Beschränkung ist drin, weil der Gedanke dahinter ist, so gezielter wie möglich die Hardware zu integrieren.

Ich bin eh an der FW oft um mich zwecks einer Integrierung zu vollziehen von einer CPU Familie.

Gezielt werde ich mal mit dem Board testen sobald Ich es vor mir habe.

Die zeilen anzupassen sollte kein Problem sein und wenn wir es gestartet haben, werde ich es auch als Änderung einreichen.

Verstand ich es richtig? Die Zeilen verursachen, das die Einstellungen wie Bsp nur MU aktiv derzeit nicht gespeichert werden wenn die Hardware vom
Strom genommen wird?

[Dattel]

Ich denke, die Beschränkung ist drin, weil der Gedanke dahinter ist, so gezielter wie möglich die Hardware zu integrieren.

Das sehe ich ein und das macht auch Sinn. Wenn wir schon mal am ESP32 dran sind, dann können wir das ja gleich mit korrigieren. Ich hab's aber bisher nicht getestet. Mir ist nur aufgefallen, dass die Einstellungen nicht gespeichert werden und habe mich auf die Suche begeben. Laut Doku sind die Funktionen für den ESP32 ebenfalls verfügbar.

Verstand ich es richtig? Die Zeilen verursachen, das die Einstellungen wie Bsp nur MU aktiv derzeit nicht gespeichert werden wenn die Hardware vom
Strom genommen wird?

korrekt....

Hier mal für dich zum Nachvollziehen..

in der commands.h in der function "inline void configCMD()" werden die Einstellung (MU,MC,MS,Mred) gesetzt und am Ende wird die function "storeFunctions(musterDec.MSenabled, musterDec.MUenabled, musterDec.MCenabled, musterDec.MredEnabled);" aufgerufen. Die Funktion maskiert die 4 Einstellungen in ein int und speichert diese dann im EEPROM.. (oder wie im vorliegenden Fall halt nicht)

Eine weitere Stelle habe ich noch gefunden, die korrigiert werden müsste

commands.h 346ff:

#ifdef ESP8266
			EEPROM.commit();
#endif

[Dattel]

ach ich seh gerade...
das ist wohl mittlerweile schon korrigiert... ich flashe gerade die 3.5 branch um das zu testen.

[HomeAutoUser]

Der letzte Branch ist der https://github.com/RFD-FHEM/SIGNALDuino/tree/dev-r3.4_plattformIO welcher auch dem r3.5_... gleichgesetzt ist. Dieser r3.5 wird noch entwickelt.

[Dattel]

okay.. ich hab auch noch nicht wirklich Unterschiede zwischen 3.4 und 3.5 gefunden.
Zumindest kann ich Rückmelden, dass meine letzten Anmerkungen zwecks EEPROM da bereits drin sind und funktionieren.

[HomeAutoUser]

Hallo @Dattel ,
wie läuft dein ESP32?

Wenn du es nicht mitbekommen hattest, die von dir damals vorgeschlagene PIN Belegung wurde an einem PIN geändert weil dies ein sehr ungünstiger PIN ist.

MfG

[Dattel]

Nein, letzte Änderung habe ich noch nicht mitbekommen. Mein ESP läuft noch immer zuverlässig mit dem RBX-Empfänger. Der CC1101 liegt zwar, aber ich habe noch keine Zeit gefunden, den umzubauen.
Einziges Problem, bei PowerLoss geht der ESP permanent in den ConfigMode und muss einmal händisch rebootet werden, damit der wieder ins konfigurierte WLAN joined.

Werde den in den nächsten Tagen nochmal aktualisieren und zum CC1101 wechseln.

[Dattel]

So jetzt habe ich endlich mal Zeit gefunden, den CC1101 anzuschließen und mit der 3.4.0-dev verheiratet, aber das klappt nicht sauber:

ich habe hier mal exemplarisch einen Consolenauszug... der CC1101 wird offensichtlich erkannt, aber wohl nicht sauber.

Reading values from EEPROM..done
dump
EEPROM=33 1d ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff ff ff ff ff
CCInit CCInit SRES Started,POR Done,EEPROM read .........................................done
CCVersion =0x14
CCPartnum =0x0
cc1101 found
Starting config portal with SSID: NodeDuinoConfig
*WM: [1] AutoConnect
*WM: [2] ESP32 event handler enabled
*WM: [2] Connecting as wifi client... 
*WM: [1] STA static IP:
*WM: [2] setSTAConfig static ip not set
*WM: [3] WIFI station disconnect
*WM: [1] Connecting to saved AP: **********
*WM: [3] Using Password: *********************
*WM: [3] WiFi station enable
*WM: [1] connectTimeout not set, ESP waitForConnectResult...
*WM: [2] Connection result: WL_CONNECTED
*WM: [3] lastconxresult: WL_CONNECTED
*WM: [1] AutoConnect: SUCCESS
*WM: [1] STA IP Address: 192.168.178.77
cc1101 _PKTCTRL0=127 vs initval PKTCTRL0=50
cc1101 _IOCFG2=127 vs initval IOCFG2=13
cc1101 is not correctly set. Please do a factory reset via command e
[E][WiFiClient.cpp:288] setSocketOption(): 1006 : 9
Starting Web Portal 
*WM: [3] dns server started with ip:  192.168.4.1
*WM: [2] HTTP server started
*WM: [2] WiFi Scan ASYNC started
*WM: [2] WiFi Scan ASYNC completed in 2109 ms
*WM: [2] WiFi Scan ASYNC found: 3

Wenn ich immer mal wieder probiere und den ESP resette, dann bootet der gelegentlich mal und verbindet auch mit FHEM
Hier die Readings, die alle etwas krumm aussehen. eigentlich sollte der in der 433er Frequenz unterwegs sein..

cc1101_config | Freq: 1664.000 MHz, Bandwidth: 58 KHz, rAmpl: 42 dB, sens: 16 dB, DataRate: 1621826.17 Baud 
cc1101_config_ext | Modulation: , Syncmod: 30/32 + carrier-sense above threshold 
cc1101_patable  C3E = FF 00 00 00 00 00 00 00
cmds | V R t X S P C r W s 
config | MS=1;MU=1;MC=1;Mred=1

Was auch immer ich von den Ändern möchte führt zum Reboot.
Any Idea??

[HomeAutoUser]

Hi, auf jedenfall hat der ESP nicht die Defaultwerte übernommen.

Die Werte in FHEM sind auch nicht normal.

• in Konsole mal das Kommando e ausführen (macht einen FactoryDefault)
• Verbindung cc1101 zum ESP überprüfen (könnte ne unsaubere Verbindung sein)

Das was mir ab und zu auffiel, der ESP32 macht sporadisch ein Reboot welchen ich noch nicht nachstellen konnte bzw. die Ursache eindämmen.

[Dattel]

Den Reset mit "e" habe ich über FHEM bereits probiert... Dann geht der ebenfalls in einen Reboot - ändern tut das aber nichts.

Habe gerade mal einen funktionierenden CC1101 von einem ESP8266 an den ESP32 umgebaut -> selbiges Ergebnis. Ich checke nachher nochmal zum zigten mal die Verkabelung.

Komisch ist aber, dass der CC1101, der gerade noch am 8266 funktioniert hat und in FHEM auch eine vernünftige Config hatte, jetzt auch mit dem 8266 komische Werte in FHEM liefert. Da kann ich einstellen, was ich will, als wenn da Zufallswerte ausgegeben werden. Der Einzige Unterschied zwichen ESP32 und ESP8266 ist gerade, dass der ESP8266 keinen Reboot macht, wenn ich was Ändere..

Scheiße, hätte ich den mal nicht angefasst :-/
Aber zumindest behaupte ich jetzt mal, dass es nicht unbedingt am CC1101 liegen kann

[Dattel]

okay update:
ich habe nach dieser Anleitung gearbeitet und den RX Pin abgezogen und anschließend mit "e" den Reset für den CC1101 getriggert - das hat funktioniert. Jetzt muss ich mal schauen, ob da auch Werte reinkommen.

Es bleiben 2 Probleme. Wunder mich, dass du da noch nicht drüber gestolpert bist.

• cc1101_patable führt bei mir zum Reboot
• nach jedem Reboot wird erstmal das WiFiConfigPortal gestartet, weil angeblich mein WLANPassword falsch ist.

[Dattel]

Welchen WifiManager hast du installiert?

[HomeAutoUser]

Ich verwende den WifiManager aus den Sourcen direkt. Also nichts zusätzliches.

Den oder einen Reboot hatte ich mal aber derzeit ist der ESP32 nur auf dem Steckbrett und offline. Ich durchkämme gerade den Code für die FSK Optimierung.

Ich werde den ESP32 mal wieder in Betrieb nehmen um dir bei see Fehlersuche zu helfen.