Fakten / Fehlersuche / Erkenntnisse - ESP #791

[HomeAutoUser]

Da wir aktuell vielleicht einen übergreifenden Fehler haben von Firmware und Software eröffne ich hier dieses ISSUES um gezielter alles zu sammeln.

Sollte sich was ändern oder neue Erkenntnisse gesammelt werden, so kann der erste Post bitte gern geupdatet oder abgeändert werden um die Übersichtlichkeit zu bewahren. @elektron-bbs & @sidey79 ihr solltet die nötigen Rechte besitzen.

Fakten: 1) Im PR "fix - Set_bWidth & PERL WARNING" https://github.com/RFD-FHEM/RFFHEM/pull/791 wurde erkannt, das die Einstellung der bWidth nicht zuverlässig funktioniert. 2) Zusätzlich hat @sidey79 bei seinem 2. ESP die Erfahrung sammeln dürfen Ich habe mir einen ESP geflasht, ich sag nur Mist. Der Crasht dauernd:( Der Grund ist vermutlich unabhängig von wenn ich die bandreite setze oder abrufe. vermutlich auch unabhängig davon Die Ausbreitung ist vermutlich nicht von der Hardware abhängig Hab schon den 2. ESP und bei dem Passiert es auch, wenn auch nicht ganz so oft Firmware 3.4.0-dev (frisch compiliert) 3) Ich komm heute nicht mehr weiter. Irgendwas ist kräftig im argen. Bin jetzt einige Branches zurück gegangen. Sende ich ein W1257 schmiert er sofort ab 4) Zuverlässigkeit SIGNALduino, der mittels SoftwareSerial an einem ESP8266 mit ESPEasy Der sduinoEasy868 war zuletzt immer nur auf closed. Das ist ein SIGNALduino, der mittels SoftwareSerial an einem ESP8266 mit ESPEasy hängt. Das funktioniert nicht sonderlich zuverlässig, aber mit der dev-r34 seit einiger Zeit gar nicht mehr:

2020.02.04 08:48:05.982 3: sduinoEasy868: StartInit, get version, retry = 0
2020.02.04 08:48:15.994 1: sduinoEasy868: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2020.02.04 08:48:15.996 2: sduinoEasy868: CloseDevice, closed

2020.02.04 08:53:31.033 3: sduinoEasy868: StartInit, get version, retry = 0
2020.02.04 08:53:41.045 1: sduinoEasy868: CheckVersionResp, Not an SIGNALduino device, got for V: undef
2020.02.04 08:53:41.048 2: sduinoEasy868: CloseDevice, closed

Mit den Versionen aus dem SVN oder GitHub master funktioniert er plötzlich wieder:

2020.02.04 09:15:55.804 3: sduinoEasy868: StartInit, get version, retry = 0
2020.02.04 09:16:05.816 3: sduinoEasy868: StartInit, get version, retry = 1
2020.02.04 09:16:15.827 3: sduinoEasy868: StartInit, get version, retry = 2
2020.02.04 09:16:15.972 2: sduinoEasy868: CheckCmdResp, initialized v3.4.1
2020.02.04 09:16:15.983 3: sduinoEasy868: CheckCmdResp, enable receiver (XE)

2020.02.04 09:33:34.834 3: sduinoEasy868: StartInit, get version, retry = 1
2020.02.04 09:33:35.039 2: sduinoEasy868: CheckCmdResp, initialized v3.4.1
2020.02.04 09:33:35.050 3: sduinoEasy868: CheckCmdResp, enable receiver (XE)

---

Erkenntnisse: 1) Scheinbar ist die Umschreibung der Get Routine nicht kompatible mit der ESP Variante. 2) Zuverlässigkeit SIGNALduino, der mittels SoftwareSerial an einem ESP8266 mit ESPEasy funktioniert mit der dev-r34 nicht. Master bzw. SVN Version geht.

---

Testfakten / Erkenntnisse mit Versionsangaben:

a)

version V 3.4.0-dev SIGNALESP cc1101 (chip CC1101) - compiled at Dec 4 2019 22:01:01
versionProtocols 1.15
versionmodul v3.4.2_dev_27.01

set cc1101_bWidth funktioniert nicht:

2020.02.04 09:01:01.545 3: sduino_IP: Set_bWidth, Request register 10
2020.02.04 09:01:55.976 3: sduino_IP: Set_bWidth, Request register 10
2020.02.04 09:01:56.191 3: sduino_IP: Set_bWidth, Request register 10

set raw W1207 Freq: 433.920 MHz, Bandwidth: 812 KHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 5603.79 Baud set raw W1257 Freq: 433.920 MHz, Bandwidth: 325 KHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 5603.79 Baud

b)

version V 3.4.0-dev SIGNALESP cc1101 (chip CC1101) - compiled at Dec 4 2019 22:01:01
versionProtocols 1.10
versionmodul v3.4.1 (aktuell SVN)

set cc1101_bWidth 58

2020.02.04 09:19:10.754 3: sduino_IP: parseResponse, bWidth: Setting MDMCFG4 (10) to f7 = 58 KHz
ccconf freq:433.920MHz bWidth:58KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud)

set cc1101_bWidth 325

2020.02.04 09:23:02.080 3: sduino_IP: parseResponse, bWidth: Setting MDMCFG4 (10) to 57 = 325 KHz
ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud)

c)

https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt
version V 3.4.0-dev SIGNALESP cc1101 (chip CC1101) - compiled at Dec 4 2019 22:01:01
versionProtocols 1.10
versionmodul v3.4.1 (aktuell GitHub master)

set cc1101_bWidth 650

2020.02.04 09:42:06.111 3: sduino_IP: parseResponse, bWidth: Setting MDMCFG4 (10) to 17 = 650 KHz
ccconf freq:433.920MHz bWidth:650KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud)

set cc1101_bWidth 325

2020.02.04 09:43:56.910 3: sduino_IP: parseResponse, bWidth: Setting MDMCFG4 (10) to 57 = 325 KHz
ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB (DataRate:5603.79Baud)

set raw W1207 Freq: 433.920 MHz, Bandwidth: 812 KHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 5603.79 Baud

set raw W1257 Freq: 433.920 MHz, Bandwidth: 325 KHz, rAmpl: 42 dB, sens: 8 dB, DataRate: 5603.79 Baud

---

ToDO´s 1) @sidey79 Von der aktuellen V 3.4.0 von 050120 gibt es keine compilierte Datei für den SIGNAL-ESP auf GitHub.

[sidey79]

Wieso lesen wir erst? Weil wir nur nen Bruchteil davon ändern richtig?

Das ist richtig.

[elektron-bbs]

Ich habe jetzt wieder alles auf aktuelle Versionen aus Github geladen. Dabei fällt mir auf, das der SIGNAL-ESP auch manchmal bei set rampl neu startet. Ich schätze, da funktioniert der SPI-Zugriff auf den Flash nicht mehr richtig.

[HomeAutoUser]

Ich versuche gerade 1 : 1 Unterschied mir anzusehen aber sehe noch nichts. Kann man ggf mehr Zwischenausgaben hinzufügen um Zugriffe oder Cmd‘s abzufangen / prüfen.

[HomeAutoUser]

@elektron-bbs (mit Arduino IDE + EspExceptionDecoder) @sidey79 bitte prüfen.

Ich habe nun den Fall mehrfach rekonstruieren können, das nach 3x Schreiben und lesen, beim 4 mal der Fehler auftrat. Ich schrieb die bWidth 58, 68, 81 und bei 102 kam der Fehler.

Dann nach einem Spannunglos, kam der Fehler sofort beim setzen von 812.

Stackausgabe deutet auf das SimpleFIFO hin.

Exception 0: Illegal instruction
PC: 0x402024bc: SimpleFIFO ::enqueue(int) at D:\Temp\arduino_build_791524\sketch/SimpleFIFO.h line 77
EXCVADDR: 0x00000000

Decoding stack results
0x4010054e: interrupt_handler(void*) at D:\Eigene Dateien\ArduinoData\packages\esp8266\hardware\esp8266\2.6.3\cores\esp8266\core_esp8266_wiring_digital.cpp line 141
0x401005d8: interrupt_handler(void*) at D:\Eigene Dateien\ArduinoData\packages\esp8266\hardware\esp8266\2.6.3\cores\esp8266/interrupts.h line 29
...

Die Zeile 77 wäre bool SimpleFIFO<T,rawSize>::enqueue( T element ) {

VerlaufsProtokoll:

192.168.2.20
XQ
V
XE
C0DnF
C3E
C10
W12f7
18=247
WS36
WS34
C0DnF
C10
W12e7
18=231
WS36
WS34
C0DnF
C10
W12d7
18=215
WS36
WS34
C0DnF
C10
W12c7
18=199
Fatal exception 0(IllegalInstructionCause):
epc1=0x402024bc, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000

Edit: Zusätzlich fiel mir auf, wenn ich bWidth 102 setze, kommt als Ergebnis bei ccconf 101 raus. Alle anderen Werte stimmten bisher.

Edit 2: cc1101_patable | C3E = FF FF FF FF FF FF FF FF nach einem Absturz, fraglich oder?

Edit 3: selbst bei einem raw e kam der Fehler ebenso mit dem selben Ergebnis. Nun versuche ich den "alten Zustand" irgendwie erstmal herzustellen.

[HomeAutoUser]

Wie ist der Test von @sidey79 denn bisher verlaufen hier?

@elektron-bbs, kannst du bitte ggf deine Erkenntnisse des bisherigen Standes Sidey mitteilen.

[elektron-bbs]

Mit der aktuellen Firmware bin ich jetzt noch nicht weiter zum Testen gekommen. Ich habe nur mal das Einstellen der Bandbreite probiert. So, wie es jetzt ist, geht es gar nicht. Nach folgender Änderung:

    # if ($hash->{ucCmd}->{cmd} eq "set_bWidth" && $a[1] =~ /^C10\s=\s([A-Fa-f0-9]{2})$/ )
    if ($hash->{ucCmd}->{cmd} eq "set_bWidth" && $a[0] =~ /^C10\s=\s([A-Fa-f0-9]{2})$/ )

funktoiniert es dann beim 2. Anlauf:

2020.02.19 21:35:24 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/00_SIGNALduino.pm line 862.
2020.02.19 21:35:24 3: sduinoACM: Set_bWidth, Request register 10
2020.02.19 21:35:24 3: sduinoACM: Set_bWidth, Request register 10
2020.02.19 21:35:26 1: PERL WARNING: Use of uninitialized value in join or string at ./FHEM/00_SIGNALduino.pm line 934.
2020.02.19 21:36:45 3: sduinoACM: Set_bWidth, Request register 10
2020.02.19 21:36:45 3: sduinoACM: Set_bWidth, bWidth: Setting MDMCFG4 (10) to f7 = 58 KHz
2020.02.19 21:37:21 3: sduinoACM: Set_bWidth, Request register 10
2020.02.19 21:37:21 3: sduinoACM: Set_bWidth, bWidth: Setting MDMCFG4 (10) to 57 = 325 KHz

Da muss dann wohl noch die Prüfung wie bei dir mit rein:

if (exists($hash->{ucCmd}->{cmd}) && $hash->{ucCmd}->{cmd} eq "set_bWidth" && $a[0] =~ /^C10\s=\s([A-Fa-f0-9]{2})$/ )

[sidey79]

Weisst Du denn, was in $a[0] steht?

[elektron-bbs]

Ich habe mir in die sub SIGNALduino_Set_bWidth eine Logausgabe geschrieben:

$hash->{logMethod}->($hash->{NAME}, 3, "$hash->{NAME}: Set_bWidth, a[0]=$a[0], a[1]=$a[1], ucCmd=" . $hash->{ucCmd}->{cmd});

Die Ausgabe ist dann:

2020.02.20 17:07:37 3: sduinoIP: Set_bWidth, a[0]=cc1101_bWidth, a[1]=58, ucCmd=
2020.02.20 17:07:37 3: sduinoIP: Set_bWidth, Request register 10
2020.02.20 17:07:37 3: sduinoIP: Set_bWidth, a[0]=C10 = F7, a[1]=, ucCmd=set_bWidth
2020.02.20 17:07:37 3: sduinoIP: Set_bWidth, bWidth: Setting MDMCFG4 (10) to f7 = 58 KHz

2020.02.20 17:08:11 3: sduinoIP: Set_bWidth, a[0]=cc1101_bWidth, a[1]=325, ucCmd=
2020.02.20 17:08:11 3: sduinoIP: Set_bWidth, Request register 10
2020.02.20 17:08:11 3: sduinoIP: Set_bWidth, a[0]=C10 = F7, a[1]=, ucCmd=set_bWidth
2020.02.20 17:08:11 3: sduinoIP: Set_bWidth, bWidth: Setting MDMCFG4 (10) to 57 = 325 KHz

[sidey79]

Hmm, Aufgerufen wird folgendes

($returnMessage,$event) = $hash->{ucCmd}->{responseSub}->($hash,$rmsg) ;

Also ist $a[0] = $rmsg Mich wundert, dass ich schon mal darüber gestoplert bin und der Meinung war dass es richtig ist. So wie jetzt dürfte es dann eigentlich auch nie funktionieren

[elektron-bbs]

Ich bin mittlerweile auch verunsichert, weil ich der Meinung war, das es vor der letzten Firmwareänderung noch bei den SIGNALduinos funktioniert hat, nur beim SIGNAL-ESP nicht. Das kann ja aber eigentlich nicht sein, wenn $a[1] die Ursache ist, oder?

Mit der Änderung auf $a[0] funktioniert es jedenfalls aktuell mit SIGNALduino und SIGNAL-ESP.

[sidey79]

Nur damit wir jetzt nicht von unterschiedlichen Ständen reden.

In dem PR hatten wir bereits einiges Identifiziert und korrigiert: https://github.com/RFD-FHEM/RFFHEM/pull/791/files

[HomeAutoUser]

Auf jedenfall wenn das Argument auf $a[0] umgeschrieben wird, so müssen noch Variablen abgefangen werden weil sonst Warnings erscheinen.

2020.02.20 22:46:39 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/00_SIGNALduino.pm line 861.
2020.02.20 22:46:39 3: nano_433Mhz: Set_bWidth, Request register 10
2020.02.20 22:46:39 3: nano_433Mhz: Set_bWidth, bWidth: Setting MDMCFG4 (10) to 87 = 203 KHz
2020.02.20 22:46:41 1: PERL WARNING: Use of uninitialized value in join or string at ./FHEM/00_SIGNALduino.pm line 933.

Das Einstellen ging auf jedenfall bei "Normalo" und beim ESP.

[sidey79]

Wir sollten jetzt nicht anfangen Perl und Firmware Fehler hier zu vermischen!

[HomeAutoUser]

Da das ISSUES ja auf die Fakten basiert, so kommen wir nicht an einer Vermischung vorbei. Um die Dinge zu trennen, so müsstest du @sidey79 bewerten ob wir die Firmware soweit gefixt haben das dort das Ergebiss stimmt. Wenn ja, so muss nun im Modul für Richtigkeit und keine PERL Warnings gesorgt werden.

[HomeAutoUser]

Hier sind wir durch oder wird der Faden noch benötigt?

[sidey79]

Ich denke wir können ihn schließen