compile error: "non-local lambda expression cannot have a capture-default"
Opened this issue · 37 comments
Ich versuche den culfw.esp8266 zu kompilieren/flashen - den error output von der Arduion IDE kann ich leider nicht behben.
Hat vielleicht jemand einen Tip für mich?
Das Problem habe ich leider auch
Vielleicht kann jemand ein fertiges binary uploaden? Die wifi credentials sind ja nicht mehr in der private.h
Moin,
ich war abgelenkt und les es erst jetzt: ich hatte gleiche Probleme zwischendurch und das ist ein Problem mit den Compilerversionen. Ich nutze gerade die Arduino-IDE 1.8.19 und esp8266 in der Version 3.0.2. Damit läuft es bei mir und ich lade die binary mal hoch.
Nachtrag: auch mit der esp8266-Version 3.1.1 funktioniert es. Die neue IDE 2.0 nutze ich noch nicht wegen des fehlenden Exception Decoders.
Moin,
ich hatte das genau so installiert aber leider ohne Erfolg. Der Fehler ist der Gleiche - sehr merkwürdig.
Ich warte auf die Binary, damit wirds dann hoffentlich klappen :)
Danke übrigens für die Umsetzung, das rettet mir meinen Stromverbrauchszähler ;)
Hallo!
Ich habe auch erst heute gesehen dass da eh schon immer ein binary lag. Im Verzeichnis:
culfw.esp8266/php/esp8266/
Werde ich ausprobieren sobald ich Zeit finde - danke Man-fred!
Super! Das mit der binary hat funktioniert.
Leider kommt er mit einem "@" im WIFI-Passwort nicht zurecht...
Gibt es dafür eine Lösung?
nur eine Idee von mir, aber vielleicht lässt sich das mit dem ESPflash tool bewerkstelligen?
Leider nein... Aber danke für die gute Idee.
Ich kanns zur Zeit leider nicht testen da ich noch auf den CC1101 warte.
Den habe ich noch nicht angelötet, im Netzwerk taucht der Wemos ja trotzdem auf.
Ich habe es jetzt mit einem anderen VLAN mit anderer SSID und Passwort getestet - problemlos.
Bin jetzt dabei ALLE IoT Geräte mit nem neuen WLAN-Passwort zu versehen, soweit bin ich schon :(
Interessant. Habe den Wemos gelöscht und neu geflashed. Aber ohne CC1101 ist da kein WLAN/AP vom ESP8266 zu finden. Ich dachte der ESP bootet nicht ohne den CC1101 zu initianlisieren? Seriell kommt:
Ist ja lange her und mein Wissen nicht mehr ganz frisch, aber ich finde im Code keinen Hinweis auf einen AP. Ich hab die Einstellung des WLAN immer mit Wis und Wik auf den esp gebracht. Funktionierte jetzt gerade auch ohne CC1101. Den muss ich auf dem Testchip auch erst noch verbinden.
Ich habe auch mit dem Passwort 1111@2222 Verbindung bekommen, natürlich sofort wieder geändert ;)
Sorry, ich steh auf dem Schlauch!
Wis Wik.. ? Hätte auch google befragt, aber was benötige ich dazu? setup via UDP oder das eeprom mit der IDE beschreiben?
Ich kenne wifi setup entweder hard-coded im scetch oder via web-gui z.B. 192.168.4.1 ?
So Stand der Dinge: Augenringe!
Ich habe mein komplettes IoT VLAN mit einem Neuen PSK versehen, die nen bin geflashed und siehe da, ich finde das Teil endlich im WLAN.
Was meinst du damit: "Ich habe auch mit dem Passwort 1111@2222 Verbindung bekommen, natürlich sofort wieder geändert ;)" Kann ich irgendwie auf das Teil zugreifen und wie iszt das default Passwort?
Nächste Herausforderung: In FHEM einbinden
@daved3luxe Mein "1111@2222" war die Reaktion auf dein "Leider kommt er mit einem "@" im WIFI-Passwort nicht zurecht...". Mit dem Passwort bekam ich Verbindung, das @ führte zu keinem Problem.
zum Einbinden in FHEM: das Teil verhält sich im Idealfall wie ein CUN, sollte mit telnet wie in der Command Reference (https://htmlpreview.github.io/?https://github.com/Man-fred/culfw.esp8266/master/docs/commandref.html) beschrieben unter CUN/CUNO: funktionieren.
Auch in FHEM ist es über "define <name> CUL <device> <FHTID>" einzubinden, auch da wie ein CUN, genaueres dort in der commandref.
Ich habe jetzt auch den Fehler zu compile error: "non-local lambda expression cannot have a capture-default"
gefunden:
Im Release steckt noch { '1', [&](char *data) { Ethernet.func(data); } }, //'E' und erzeugt die Fehlermeldung. Das war aber nach irgendeinem Update von IDE und Board nicht mehr gültig.
Im aktuellen Master wurde daraus { '1', [& obj](char *data) { Ethernet.func(data); } }, //'E', ein kleiner aber wichtiger Unterschied.
Um aus dem Master ein neues Release zu machen, vergleiche ich aber lieber noch die Einstellungen in board.h.
Ich bin auch einen Schrit weiter.
Nachdem er immer wieder die Verbindung zum WLAN verloren hat (was auch der Grund dafür war, das ich ihn nicht in FHEM einbinden konnte) habe ich mal den Wemos getauscht und siehe da, er nimmt das WLAN Passwort problemlos und er schent zu laufen wie er soll... Die ganze Mühe mit dem WLAN umsonst :/
Howto zu setup und Fhem (ich habe das mit dem seriellen Teil nicht gecheckt)
- IP Adresse, mask, GW via seriellem Terminal nach der CUL command referenz eingeben. http://culfw.de/commandref.html
Bsp: "Wia192.168.0.20" "WisMeineSSID" ... - Mit commands "Ria" , "Rig"... kann das eeprom ausgelesen werden
- Bsp für fhem: "define cul-name 192.168.0.20:2323 1234"
Sobald ich das mit den compilation errors im Griff habe, werde ich "define HAS_MBUS" für den Wasserzähler austesten (sofern der CC1101 eintrifft)
HAS_MBUS
MBus ist noch gar nicht implementiert, Ich aktiviere das gerade mal, kann es aber nicht testen. Einfach nur aktivieren funktioniert nicht, da ich am Anfang des Projekts alles was ich brauchte von C (culfw) auf C++ (Arduino, esp) umgestellt habe.
das mit den compilation errors
In dem Release V1.67.00 stecken einige Sachen, die im neuen esp8266-Compiler nicht mehr funktionieren. Ich bin im Master-Branch unterwegs.
Update zu MBUS: Compiliert fehlerfrei, testen kann ich aber leider nicht da mir die Sender fehlen.
Gleich getestet heute. CUL wird erkannt und intialisiert (zuvor ohne Fehler kompiliert). Konfiguriere ich am cul rfmode auf "WMBus_T", geht dieser auf disconnected. Mit einem seriellen nanoCUL hat das vorher funktioniert.
2023-02-06 11:59:45 Global global ATTR espcul rfmode WMBus_T
2023-02-06 11:59:53 CUL espcul DISCONNECTED
2023-02-06 11:59:53 CUL espcul cmds: B b C e F f G K l M N q R s T t u V W X x Z 1
Zurückstellen des rfmode:
2023.02.06 13:35:43 2: Switched espcul rfmode to SlowRF
2023.02.06 13:35:48 3: espcul: Possible commands: BbCeFfGKlMNqRsTtuVWXxZ1
2023.02.06 13:35:49 1: 192.168.50.35:2323 reappeared (espcul)
WMBus wäre ein feines extra feature, der ESP-CUL ist aber auch so genial!
Eventuell beschäftigt MBUS das System so, dass WiFi Timingprobleme bekommt. Ich werde mal ein paar Unterbrechungen aktivieren. Vielleicht gehts dann besser. Wenn der esp8266 während des Betriebs an der seriellen Console hängt: kommen dann Hinweise auf Neustarts? Poste doch mal das serielle Protokoll beim Aktivieren von MBUS. Vielleicht ergibt sich da ein Hinweis.
Lt. command reference müsste "brt" den wmbus auf receive t-mode sein:
Wireless M-Bus:
r<mode>
start receiving messages. <mode> bust be either s or t for desired mode
s<data>
send data (tbd)
returns always the actual receiving mode
Gebe ich "b" auf der console ein crashed der wemos:
?3⸮⸮�1⸮D�⸮⸮LH�⸮eeprom_init
EEPROM bytes 265
eeprom_init ok
Connecting ESP-773B70, hostname cul-esp
noDHCP
.......
UDP 1, TCP 0 on 192.168.50.35:2323
Channel 1100
CC1100_PARTNUM 0x00: 0
CC1100_VERSION 0x14: 14
20000028 sec 20 silence 1 edge 0 reset 0
b
--------------- CUT HERE FOR EXCEPTION DECODER ---------------
Exception (3):
epc1=0x40202bbf epc2=0x00000000 epc3=0x00000000 excvaddr=0x4024a5cc depc=0x00000000
stack>>>
ctx: cont
sp: 3ffffd90 end: 3fffffd0 offset: 0190
3fffff20: 00000000 3fff151c 4020e312 3fff151c
3fffff30: 00000000 3fff0e38 00000001 402113b8
3fffff40: 3ffee91a 00000001 3ffee91a 40208c4e
3fffff50: 3ffee91a 00000001 00000062 40204e61
3fffff60: 00000000 00000000 00000000 3ffeed18
3fffff70: 3ffeec04 3ffeec8f 3ffee91a 40204ef5
3fffff80: 0000000c 3ffeed9c 3fff1390 4020b580
3fffff90: 3fffdad0 0000000a 3fff1390 3fff151c
3fffffa0: 3ffee910 3ffeed9c 3ffee8e8 402014cc
3fffffb0: 3fffdad0 00000000 3fff14f0 4020e4a0
3fffffc0: feefeffe feefeffe 3fffdab0 40101349
<<<stack<<<
Das konnte ich nachvollziehen. Der esp8266 kommt mit DS_P(PSTR()) nicht klar, ich habe das ersetzt zu DS(). Ich habe die Änderungen hochgeladen.
Habs schnell gestet, hatte leider wenig Erfolg. Wie gesagt, ist kein Beinbruch wenn mbus nicht läuft.
brt
TMODE
--------------- CUT HERE FOR EXCEPTION DECODER ---------------
Soft WDT reset
stack>>>
ctx: cont
sp: 3ffffdb0 end: 3fffffd0 offset: 01a0
3fffff50: 40211c04 00000000 00001388 4020f508
3fffff60: 00000000 00000000 0000000f 401007d3
3fffff70: 4020f25c 3ffee92c 3ffee92c 4020193c
3fffff80: 3fff0e58 0000002f 3ffee92c 40201ab6
3fffff90: 0000002f 3ffee92c 3fff1234 40208435
3fffffa0: 3ffee930 3ffeedbc 3ffee908 3fff153c
3fffffb0: 3fffdad0 00000000 3fff1510 4020e494
3fffffc0: feefeffe feefeffe 3fffdab0 40101349
<<<stack<<<
--------------- CUT HERE FOR EXCEPTION DECODER ---------------
?�)⸮⸮T9⸮⸮ ⸮9⸮⸮ ⸮eeprom_init
EEPROM bytes 265
eeprom_init ok
Connecting ESP-773B70, hostname cul-esp
........
UDP 1, TCP 0 on 192.168.50.35:2323
Channel 1100
CC1100_PARTNUM 0x00: 0
CC1100_VERSION 0x14: 14
Hatte Erfolg ;) ein anderer Fehler. Soft WDT reset deutet jetzt wirklich auf Timing-Probleme hin. Ich hab jetzt mal die delay's eingetragen, damit müssten die resets weg sein.
Ich möchte aber nicht ausschließen dass ich da einen Fehler mache...
CC1100_PARTNUM 0x00: 0
CC1100_VERSION 0x14: 14
UDP 1, TCP 0 to 192.168.1.30:52510
V
V 1.67 CUL868
?
? (? is unknown) Use one of B b C e F f G K l M N q R s T t u V W X x Z 1
X21
brt
T01
TMODE
1234
--------------- CUT HERE FOR EXCEPTION DECODER ---------------
Soft WDT reset
stack>>>
ctx: cont
sp: 3ffffdc0 end: 3fffffd0 offset: 01a0
3fffff60: 00000000 00000000 0000000f 401007d8
3fffff70: 4020f25c 3ffee92c 3ffee92c 4020193c
3fffff80: 3fff0e58 3ffee922 3ffee92c 40201acb
3fffff90: 0000002f 3ffee92c 3fff1234 40208435
3fffffa0: 3ffee930 3ffeedbc 3ffee908 3fff153c
3fffffb0: 3fffdad0 00000000 3fff1510 4020e494
3fffffc0: feefeffe feefeffe 3fffdab0 40101349
<<<stack<<<
Guten Abend und vielen Dank für die erbrachte Arbeit!
Ich dachte, culfw.esp kann nicht so schwer sein, habe ich schon einige ESP geflasht, z.T. Sofware selber geschrieben, etc.
Aber auch meine Arduino IDE (1.8.19) möchte nicht fehlerfrei kompillieren. Daher habe ich das .bin aus folgendem Ordner geflasht.
https://github.com/Man-fred/culfw.esp8266/blob/master/culfw-esp8266/culfw-esp8266.ino.d1_mini.bin
Ich habe zwei verschiedene, neue, Wemos genutzt. Nach dem flashen kommt auf der Konsole nur:
mit 115200 baud kommt:
mit 74880 baud kommt:
Nach den letzen Aussagen scheint die besagte .bin wohl zu funktionieren. Daher meine Frage, ob jemand eine Idee hat, auf welchem Schlauch ich stehe. Vielen Dank!
Versuch mal mit 9600bps
selbes Ergebnis...
Putty
▒eeprom_initO▒▒p 8
EEPROM bytes 265
eeprom_init ok
Connecting ESP-773B70, hostname cul-esp
........
UDP 1, TCP 0 on 192.168.50.35:2323
Channel 1100
CC1100_PARTNUM 0x00: 0
CC1100_VERSION 0x14: 14
V 1.67 CUL868
192.169.50.35
auch über Putty nur kryptische Ausgaben. Möglicherweise ist die bin Datei bei mir korrupt. Ich habe mit NodeMCU und mit ESP EASY Flahser geflahst, den Flash vorher mehrfach mit blank überschrieben, verschiedene Geschwindigkeiten ausprobiert und auch mal zum Testen vom Wemos eine andere Datei draufgespielt (welche läuft). Leider kann ich die Sourcen auch nicht kompilieren. Schade, irgendwo ist da der Wurm bei mir drin.
Ich hatte auch mit dem esp easy flasher die binary eingespielt. War kein Problem.
Welches Problem gibts denn beim kompilieren? Arduino IDE 1.8.19 läuft bei mir.
Ich nutze auch die 1.8.19 IDE. Dazu esp 2.7.4
Und nun das:
Um den Fehler beim Kompilieren nachzustellen, habe ich nochmals das letze Release runtergeladen, nur die culfw-esp8266.ino aus dem zip in den vorhandenen Ordner culfw.esp8266-1.67.00 kopiert und das Ganze nochmal kompilliert. Und siehe da: ohne Fehler. Das Ding geflasht, Wifi eingetragen.... läuft.
Echt eigenartig, aber toll, dass es doch noch geht.
Vielen Dank für die Unterstützung und Begleitung bei der Fehlersuche. Ich kann zwar nicht sagen, was der Fehler war, aber immerhin kann ich bestätigen, dass es geht.
Freut mich das es jetzt läuft. Mit dem Flasher habe ich nie gearbeitet, deshalb hab ich mich zurückgehalten mit Kommentaren.
Hier nochmal eine Ergänzug zu meinem WLAN-Problem.
Es scheint so als könnte man den WIFI-PSK ab einer gewissen Länge nicht mehr mit dem "Wik" Befehl eingeben.
Was aber funktioniert ist, wenn man die Datei ethernet.cpp wie folgt anpasst:
const char* SSID = "SSID";
const char* PSK = "PASSWORD";
WiFi.begin(SSID, PSK);
//WiFi.begin(FNcol.ers(EE_WPA_SSID), FNcol.ers(EE_WPA_KEY));
Quelle: FHEM Forum