SIGNALESP: Firm- und Hardware für SIGNALduino direkt auf ESP8266 oder ESP32

[spi3845]

Mein SignalESP geht ständig auf closed.

Was hat das zu bedeuten?

Nach einem reset ist er wieder für ein paar Stunden opened....

Bei mir hat er auch immer resets ausgeführt. Allerdings viel häufiger als nur alle paar Stunden. Löschen des kompletten Speichers und neuflashen hat geholfen. Wie löschen geht, steht weiter oben im Thread.

[spi3845]

Update 1:
Nachdem der SIGNALESP läuft, habe ich erfolgreich mehrere SIMU (aka SOMFY) Rollläden angebunden (auf Frequenz 433.42MHz). Zuvor hat der SIGNALESP zufällig einige TCM Wetterstation-Sensoren aufgezeichnet - diese laufen auf 433.9MHz. Steht mein SIGNALESP auf 433.42MHz, hört er die Funksensoren nicht.

Gibt es einen Trick, um beides mit einem cc1101 zu empfangen? Z.B. den SIGNALESP auf 433.9MHz einzustellen, um Temperatur und Feuchtigkeit der Sensoren aufzuzeichnen und zum Steuern der SIMU-Rollläden kurzzeitig auf 433.42 MHz zu wechseln?

Ich habe den Parameter cc1101_bWidth entdeckt - aber den hochzustellen und die Sendefrequenz auf 433.42MHz zu lassen reicht nicht. Ich empfange die Sensoren dann immer noch nicht. Bei einer Frequenz "in der Mitte" bei 433.67MHz und bWidth von 650kHz kann ich die Sensoren empfangen und die Somfys steuern (ich habe aber noch keine Langzeiterfahrung, ob das auf Dauer mit dieser Sendefrequenz klappt). Gibt es sonst noch eine Möglichkeit, die Sendefrequenz bei genau 433.42MHz zu belassen, aber die Empfangsfrequenz nach oben hin zu erweitern?

Update 2:
Und noch eine Frage: ich sehe neue Nachrichten in RAWMSG, aber nicht im fhem EventMonitor bzw. Log. Attribut verbose habe ich 4 und 5 versucht, debug und development auch jeweils auf 1 getestet. Im EventMonitor sehe ich z.B., wenn er sich disconnected/connected.

Hat jemand eine Idee?
Grüße,
spi

[Sidey]

Hi,

Beim Senden wird automatisch auf die für das Somfy Protokoll hinterlegte Frequenz umgestellt.

Wenn Du Somfy nicht empfangen möchtest, kannst Du den cc1101 auf 433.9 MHz belassen.

Um die Raw Nachrichten im Eventlog zu sehen, musst Du das Attribut eventlogging setzen.

Grüße Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

[spi3845]

Hi,

Beim Senden wird automatisch auf die für das Somfy Protokoll hinterlegte Frequenz umgestellt.

Wenn Du Somfy nicht empfangen möchtest, kannst Du den cc1101 auf 433.9 MHz belassen.

Um die Raw Nachrichten im Eventlog zu sehen, musst Du das Attribut eventlogging setzen.

Grüße Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

Mille danke!

Das mit dem Event Logging hat geklappt.

Bzgl. der Frequenz läuft auch alles. Der Parameter cc1101_freq ist dann in der fhem GUI missverständlich ausgedrückt, dort steht: "...legt sowohl die Empfangsfrequenz als auch die Übertragungsfrequenz fest." Dachte, ich muss den manuell umschalten vor jedem Senden...

[Sidey]

Bzgl. der Frequenz läuft auch alles. Der Parameter cc1101_freq ist dann in der fhem GUI missverständlich ausgedrückt, dort steht: "...legt sowohl die Empfangsfrequenz als auch die Übertragungsfrequenz fest." Dachte, ich muss den manuell umschalten vor jedem Senden...

Stimmt. Die Beschreibung ist auch nicht falsch nur nicht allumfassend.

[spi3845]

Konnte den Branch `dev-r33_prepare_release` erfolgreich kompilieren für einen ESP32. Würde mich jetzt den Tests mit einem ESP32 widmen.
Welchen Branch sollte ich für Tests auf einem ESP32 am Besten verwenden?
Als GPIO-Pins habe ich folgende gefungen:

compile_config.h

Code Auswählen Erweitern

#ifdef ESP8266
#define PIN_RECEIVE            5// D1
#define PIN_LED                16
#define PIN_SEND               4// D2  // gdo0Pin TX out
#define ETHERNET_PRINT
#else
#define PIN_RECEIVE            2
#define PIN_LED                13 // Message-LED
#define PIN_SEND               11
#endif

cc1101.h

Code Auswählen Erweitern

#define csPin SS    // CSN  out, Oktal 5
#define mosiPin MOSI   // MOSI out, Oktal 27
#define misoPin MISO   // MISO in, Oktal 23
#define sckPin  SCK    // SCLK out, Oktal 22


Zur Laufzeit sehe ich auf einem ESP

Code Auswählen Erweitern

csPin 5
mosiPin 23
misoPin 19
sckPin 18
PIN_RECEIVE 2
PIN_SEND 11


Update 1:
Habe in der Config-Seite des SIGNALESP unter 192.168.4.1 das WLAN konfiguriert. Er verbindet sich, und stürzt ab mit folgendem Fehler:

Code Auswählen Erweitern

*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] Connect to new AP [SUCCESS]
*WM: [1] Got IP Address:
*WM: [1] 192.168.0.147
*WM: [2] disconnect configportal
*WM: [2] restoring usermode STA
*WM: [2] wifi status: WL_CONNECTED
*WM: [2] wifi mode: STA
*WM: [1] config portal exiting
Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.
Eine IP@ hat er noch per DHCP bekommen (die ich zuvor statisch im Router hinterlegt hatte).

Ein

Code Auswählen Erweitern


esptool.py --chip esp32 -p /dev/ttyUSB0 erase_flash
und Neuflashen ändern nichts. Es wird die aktuellste WIFIManager#development verwendet.

[spi3845]

Update 1:
Habe in der Config-Seite des SIGNALESP unter 192.168.4.1 das WLAN konfiguriert. Er verbindet sich, und stürzt ab mit folgendem Fehler:

Um einen Fehler im WiFiManager auszuschließen, habe ich folgenden Sketch auf einem ESP32 getestet - läuft:

Code Auswählen Erweitern


#include <Arduino.h>

#include "WiFiManager.h"          //https://github.com/tzapu/WiFiManager

void setup() {
  Serial.begin(115200);
while (!Serial) {
delay(50);
}
 
  //WiFiManager
  WiFiManager wifiManager;
  wifiManager.setTimeout(180);
 
  if(!wifiManager.autoConnect("AutoConnectAP")) {
    Serial.println("failed to connect and hit timeout");
    delay(3000);
    ESP.restart();
    delay(5000);
  }

  Serial.println("Verbunden");
}

void loop() {
  Serial.print("WiFi status: ");
  Serial.print(WiFi.status());
  Serial.print(", local ip: ");
  Serial.println(WiFi.localIP());
  delay(5000);

}


Es wird jeweils die aktuellste WiFiManager Version aus dem Branch development (https://github.com/tzapu/WiFiManager.git#development) verwendet.

Der Sketch läuft, keine Abstürze, der Fehler muss also in der Implementierung von WiFiManager in SGINALESP liegen. Suche weiter...

Folgender Sketch nutzt WiFiManager so wie in SIGNALESP - und läuft auch:

Code Auswählen Erweitern


#include <Arduino.h>

#include "WiFiManager.h"          //https://github.com/tzapu/WiFiManager

WiFiManager wifiManager;

void setup() {
  Serial.begin(115200);
while (!Serial) {
delay(50);
}
 
  //WiFiManager
  WiFi.mode(WIFI_STA);
  wifiManager.setShowStaticFields(true);
  wifiManager.autoConnect("NodeDuinoConfig",NULL);
wifiManager.setConfigPortalBlocking(false);
wifiManager.startWebPortal();


  Serial.println("Verbunden");
}

void loop() {
  wifiManager.process();

  Serial.print("WiFi status: ");
  Serial.print(WiFi.status());
  Serial.print(", local ip: ");
  Serial.println(WiFi.localIP());
  delay(5000);

}

WiFiManager läuft also, aber irgendwie verbindet der SIGNALESP-ESP32 sich nicht mit dem WLAN, sobald das WLAN in der webgui konfiguriert wurde. Da kommt immer nur der folgende Fehler und der ESP32 resettet und startet den AP-Modus.

Code Auswählen Erweitern


Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled
Hat jemand eine Idee?

[Sidey]

Funktioniert das Beispielprogramm auch mit dem OTA Branch?

Gesendet von meinem Moto Z (2) mit Tapatalk

[elektron-bbs]

Funktioniert Flash OTA jetzt beim ESP8266? Wenn ja, wie?

[Sidey]

Hmm, den OTA Branch hatte ich schon vor langer Zeit referenziert.

Der Upload wird via http Post auf /U durchgeführt.

Ich hatte es damals aber nicht weiter verfolgt, da ich keine Username / Passwort Absicherung hinbekommen habe.

Gruß Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

[spi3845]

Funktioniert das Beispielprogramm auch mit dem OTA Branch?

Ich sehe auf github keinen OTA Branch - im Screenshot die, die ich sehe. Habe mit dem dev-r33_prepare_release getestet. Da ich mit VScode und platformIO arbeite, könnte der Fehler auch auf die Toolchain zurückzuführen sein. Hat jemand diesen Branch auf einem ESP32 getestet?

[spi3845]

WiFiManager läuft also, aber irgendwie verbindet der SIGNALESP-ESP32 sich nicht mit dem WLAN, sobald das WLAN in der webgui konfiguriert wurde. Da kommt immer nur der folgende Fehler und der ESP32 resettet und startet den AP-Modus.

Code Auswählen Erweitern


Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled
Hat jemand eine Idee?

Ich habe den Neustart weiter analysiert. Der Backtrace sieht so aus:

Code Auswählen Erweitern


12:14:42.028 -> Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.
12:14:42.028 -> Core 1 register dump:
12:14:42.028 -> PC      : 0x40082643  PS      : 0x00060430  A0      : 0x80082799  A1      : 0x3ffb1f10 
12:14:42.028 -> A2      : 0x00000000  A3      : 0x00000004  A4      : 0x3ffb9680  A5      : 0x00000036 
12:14:42.061 -> A6      : 0x3ffc3c30  A7      : 0x00000000  A8      : 0x3ffb79c8  A9      : 0x00000001 
12:14:42.061 -> A10     : 0x00000000  A11     : 0x00000004  A12     : 0x3ffb1ef0  A13     : 0x3ffb1ec0 
12:14:42.061 -> A14     : 0x3ffb1ec0  A15     : 0xff000000  SAR     : 0x00000018  EXCCAUSE: 0x0000001c 
12:14:42.061 -> EXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff 
12:14:42.061 ->
12:14:42.061 -> Backtrace: 0x40082643:0x3ffb1f10 0x40082796:0x3ffb1f30 0x400d2265:0x3ffb1f50 0x400e257b:0x3ffb1fb0 0x40088c5d:0x3ffb1fd0
12:14:42.095 ->
12:14:42.095 -> Rebooting...
12:14:42.095 -> ets Jun  8 2016 00:22:57
12:14:42.095 ->
12:14:42.095 -> rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
12:14:42.095 -> configsip: 0, SPIWP:0xee
12:14:42.095 -> clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
12:14:42.095 -> mode:DIO, clock div:2
12:14:42.095 -> load:0x3fff0018,len:4
12:14:42.095 -> load:0x3fff001c,len:1044
12:14:42.128 -> load:0x40078000,len:8896
12:14:42.128 -> load:0x40080400,len:5828
12:14:42.128 -> entry 0x400806ac

Die Analyse dazu:

Code Auswählen Erweitern


PC: 0x40082643: timer_armed at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/esp_timer.c line 251
EXCVADDR: 0x00000000

Decoding stack results
0x40082643: timer_armed at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/esp_timer.c line 251
0x40082796: esp_timer_stop at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/esp_timer.c line 152
0x400d2265: setup() at src/main.cpp line 365
0x400e257b: loopTask(void*) at /home/sp/.platformio/packages/framework-arduinoespressif32/cores/esp32/main.cpp line 14
0x40088c5d: vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c line 143

Um einen HW-Fehler auszuschließen, habe ich das ganze auf einem anderen ESP32 getestet - gleicher Fehler.
Hat jemand hierzu eine Idee, der den Code von SIGNALESP besser kennt?

[elektron-bbs]

Ich weiß nicht, ob es daran liegt:
Auf der Seite https://github.com/tzapu/WiFiManager steht noch auf der Wishlist: "ESP32 support or instructions".

Vieleicht mal diesen probieren: https://github.com/zhouhan0126/WIFIMANAGER-ESP32

[spi3845]

Ich weiß nicht, ob es daran liegt:
Auf der Seite https://github.com/tzapu/WiFiManager steht noch auf der Wishlist: "ESP32 support or instructions".

Ohne SIGNALESP läuft der WiFiManager - habe ich extra getestet, um Fehler darin auszuschließen. Siehe https://forum.fhem.de/index.php/topic,83273.msg986547.html#msg986547

[Sidey]

Sieht ja auf den Ersten Blick auch eher nach einem Problem mit den timern aus