search

Man-fred / culfw.esp8266

CUL/CUN 433/868 MHz CC1101 Transceiver mit WLAN-Schnittstelle für FHEM - originally forked from svn2github/culfw (https://github.com/svn2github/culfw)
GNU General Public License v2.0
8 stars 5 forks source link

compile error: "non-local lambda expression cannot have a capture-default" #16

Open babajun12 opened 1 year ago

babajun12 commented 1 year ago

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?

grafik

daved3luxe commented 1 year ago

Das Problem habe ich leider auch

babajun12 commented 1 year ago

Vielleicht kann jemand ein fertiges binary uploaden? Die wifi credentials sind ja nicht mehr in der private.h

Man-fred commented 1 year ago

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.

daved3luxe commented 1 year ago

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 ;)

babajun12 commented 1 year ago

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!

daved3luxe commented 1 year ago

Super! Das mit der binary hat funktioniert. Leider kommt er mit einem "@" im WIFI-Passwort nicht zurecht... Gibt es dafür eine Lösung?

babajun12 commented 1 year ago

nur eine Idee von mir, aber vielleicht lässt sich das mit dem ESPflash tool bewerkstelligen? grafik

daved3luxe commented 1 year ago

Leider nein... Aber danke für die gute Idee.

babajun12 commented 1 year ago

Ich kanns zur Zeit leider nicht testen da ich noch auf den CC1101 warte.

daved3luxe commented 1 year ago

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 :(

babajun12 commented 1 year ago

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:

grafik

Man-fred commented 1 year ago

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 ;)

babajun12 commented 1 year ago

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 ?

daved3luxe commented 1 year ago

https://github.com/Man-fred/culfw.esp8266#readme Das da...

daved3luxe commented 1 year ago

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

Man-fred commented 1 year ago

@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.

Man-fred commented 1 year ago

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.

daved3luxe commented 1 year ago

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 :/

babajun12 commented 1 year ago

Howto zu setup und Fhem (ich habe das mit dem seriellen Teil nicht gecheckt)

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)

Man-fred commented 1 year ago

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.

Man-fred commented 1 year ago

Update zu MBUS: Compiliert fehlerfrei, testen kann ich aber leider nicht da mir die Sender fehlen.

babajun12 commented 1 year ago

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!

Man-fred commented 1 year ago

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.

babajun12 commented 1 year ago

Lt. command reference müsste "brt" den wmbus auf receive t-mode sein:

Wireless M-Bus: r start receiving messages. bust be either s or t for desired mode s 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 <<
Man-fred commented 1 year ago

Das konnte ich nachvollziehen. Der esp8266 kommt mit DS_P(PSTR()) nicht klar, ich habe das ersetzt zu DS(). Ich habe die Änderungen hochgeladen.

babajun12 commented 1 year ago

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

Man-fred commented 1 year ago

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.

babajun12 commented 1 year ago

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<<<

Tool-use-today commented 1 year ago

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:

2023_02_18_19_57_37_Window

mit 74880 baud kommt:

2023_02_18_19_58_03_Window

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!

babajun12 commented 1 year ago

Versuch mal mit 9600bps

Tool-use-today commented 1 year ago

selbes Ergebnis...

2023_02_19_09_07_12_Window

babajun12 commented 1 year ago

Putty

image


▒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
Tool-use-today commented 1 year ago

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.

babajun12 commented 1 year ago

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.

Tool-use-today commented 1 year ago

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.

Man-fred commented 1 year ago

Freut mich das es jetzt läuft. Mit dem Flasher habe ich nie gearbeitet, deshalb hab ich mich zurückgehalten mit Kommentaren.

daved3luxe commented 1 year ago

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