-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ESP32_dev Austausch #1
Comments
So hier meine Änderungen mit WinMerge generiert. Gruß compile_config.h
signalesp.h
|
Hallo @Dattel |
Klar... compile_config.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. |
Ich habe deine Dinge erstmal implementiert. Gesehen habe ich, du hast auch die Events beim ESP8266 "angegriffen" hast. War dies Absicht?
|
Ja... Wenn schon disconnect/reconnect, dann macht das für beide Sinn, oder? Schaden wird es sicher nicht. |
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 Meine TEsts belaufen sich immer auf die doppelten Platformen ARDUINO IDE + PlatformIO um dort keinen Fehler hinein zu bringen. |
sehr gut... na das hab ich ja schon befürchtet. das schau doch einfach mal, was dir IntellieSense so anbietet
|
Das sieht schon besser aus. Wie sind die PINS bei dir auf dem ESP32 beschriftet?
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? |
Bei meinem Board stehen die mit D aufgedruckt |
Ich habe eine andere Version mit mehr PINs und die haben D durch G ersetzt.... |
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?? 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? |
Diesen Fehler bzw. das Verhalten muss ich mal reproduzieren.
Da spielt einiges ein. Antennenlänge
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
Hattest du dir die Mühe gemacht, schonmal die cc1101 Anbindung heraus zu suchen?
|
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:
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.
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)
Empfänger = Fensterbank innen, Sender vl. 6m Sichtweite entfernt im Poolthermometer draußen :-D. 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. |
fällt mir gerade so auf: dein Board hat den Wroom32, meins den Wroom32D |
Hallo @Dattel, Bitte passe die PIN´s an, sonst geht der cc1101 nicht ;-)
Das Projekt ist aktuell hier https://github.com/HomeAutoUser/SIGNALDuino/tree/dev-r3.4_plattformIO_ESP32dev
Weiterhin ist noch die Frage bzw. der Fehler drin, wenn der cc1101 aktiviert ist und die Zeile |
Sauber... das klingt doch gut. Was den esp_timer_stop betrifft: Wenn du den Call hierzu aus der Setup-Funktion meinst, dann 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. |
Hallo @Dattel , Als Tip, wenn du die aktuellen PIN´s suchst, diese sind ja in der compileConfig Datei vermerkt. |
fein fein... 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. |
ich denke, wir müssen da in den nächsten Wochen nochmal dran... functions.h Zeile: 85ff
und Zeile 119ff
und Zeile 134ff
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.. |
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 |
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.
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:
|
ach ich seh gerade... |
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. |
okay.. ich hab auch noch nicht wirklich Unterschiede zwischen 3.4 und 3.5 gefunden. |
Hallo @Dattel , 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 |
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. Werde den in den nächsten Tagen nochmal aktualisieren und zum CC1101 wechseln. |
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.
Wenn ich immer mal wieder probiere und den ESP resette, dann bootet der gelegentlich mal und verbindet auch mit FHEM
Was auch immer ich von den Ändern möchte führt zum Reboot. |
Hi, auf jedenfall hat der ESP nicht die Defaultwerte übernommen. Die Werte in FHEM sind auch nicht normal.
Das was mir ab und zu auffiel, der ESP32 macht sporadisch ein Reboot welchen ich noch nicht nachstellen konnte bzw. die Ursache eindämmen. |
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 :-/ |
okay update: Es bleiben 2 Probleme. Wunder mich, dass du da noch nicht drüber gestolpert bist.
|
Welchen WifiManager hast du installiert? |
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. |
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.
The text was updated successfully, but these errors were encountered: