MQTT Bluetooth BLE Anwesenheitserkennung mit ESP32
-
@utze86
Habe die erste Version hochgeladen:https://github.com/gsicilia82/ShellyNimBLE
Bin gespannt, wie gut deine MiBand7 gefunden wird. Bei mir ist es total kurios: Meine GTS4 Mini wird bis auf wenige Ausnahmen in 1-3 Sekunden gefunden. Meine MiBand6 aber nur alle 4-8 Sekunden...
Bin mit dem Projekt noch nicht ganz fertig. Etwas Komfort bei Shelly Plus2PM will ich noch ergänzen (Leistungsmessung wegen autom. Rollo-Kalibrierung).
[Ich will nachher auch prüfen ob ich einen Shelly OTA direkt flashen kann. Dank Github steht ein Link mit der Firmware zur Verfügung. Aber wahrscheinlich wird so etwas direkt unterbunden...
https://github.com/gsicilia82/ShellyNimBLE/releases/download/0.0.1/firmware.bin]
EDIT: Schade, klappt leider nicht mit OTA aufspielen auf original Firmware -
@giuseppes
So ich habe heute einen Shelly mit der firmware.bin geflashed. Ich komme über den AP auch auf die Maske zur Eingabe der WIFI-Daten, etc. Im Anschluss erhalte ich die Meldung:
soweit so gut. Allerdings finde ich den Shelly anschließend nicht über meine Fritzbox. Ein Blick ins WLAN zeigt mir dann, dass der Shelly wieder im AP Mode ist. Also habe ich mal die Logs ausgelesen. Nach dem Flashen mit ESPtool erhalte ich immer die folgende Einträge:
[12:01:27]rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
[12:01:27]invalid header: 0x3b666972
[12:01:27]invalid header: 0x3b666972
[12:01:27]invalid header: 0x3b666972
[12:01:27]invalid header: 0x3b666972
[12:01:27]invalid header: 0x3b666972
[12:01:27]invalid header: 0x3b666972
[12:01:27]invalid header: 0x3b666972
[12:01:27]invalid header: 0x3b666972
[12:01:27]ets Jul 29 2019 12:21:46
[12:01:27]nach dem Flashen mit dem ESPFlasher erhalte ich folgende Einträge:
[12:03:47]
[12:03:47]devMode or deviceName is empty, starting CaptivaPortal
[12:03:47]Setting up AP Mode
[12:03:47]
[12:03:47]Brownout detector was triggered
[12:03:47]
[12:03:47]ets Jul 29 2019 12:21:46
[12:03:47]
[12:03:47]rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
[12:03:47]configsip: 188777542, SPIWP:0xee
[12:03:47]clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
[12:03:47]mode:DIO, clock div:2
[12:03:47]load:0x3fff0030,len:1184
[12:03:47]load:0x40078000,len:12784
[12:03:47]load:0x40080400,len:3032
[12:03:47]entry 0x400805e4
[12:03:48]Das ganze liest sich für mich nach nem Bootloop. Ich habe keine Ahnung wie das mit deiner Firmware zusammenhängen kann, bei den anderen FW's hatte ich das Problem bisher aber noch nicht. Probleme mit nem Bootloop hatte ich sonst immer nur am Anfang als ich immer die falsche Version von Tasmota geflashed habe. Da hatte sich damals allerdings nichtmal der AP aufgebaut.
-
@utze86
Hmmm, ich habe immer mit Platformio geflasht. Ich muss es wohl auch mit dem esptool testen. Eine Möglichkeit könnte sein, dass die Firmware nicht vollständig 4MB groß ist, die ich aus Platformio genommen habe.
Ich werde heute Abend mal mit dem esptool am Shelly 2pm testen und mich melden. Danke schonmal für den Test und die Rückmeldung.Edit:
Kurios finde ich auf jeden Fall, dass das Captive Portal kam und es erst danach nicht weiter ging.
Möglich ist dass die Partition für die Speicherung der Werte (nvs) quasi nicht existiert, weil die Firmware unvollständig sein könnte. -
@giuseppes
Wo du es grade sagst. Ich habe die Firmware über den Link gezogen:https://github.com/gsicilia82/ShellyNimBLE/releases/download/0.0.1/firmware.bin
Die Datei ist bei mir aber nur ca. 900KB groß.
-
@utze86
Damit flashed man nur die App Partition. Das wird der Fehler sein. Ich werde schauen, wie ich eine 4MB Firmware aus Platformio bekomme. Bin mit Platformio auch noch kein Profi, habe erst mit diesem Projekt damit angefangen. Aber durch die Integration in vscode ist es echt genial.
Falls ich es damit nicht schaffe, setze ich mein Shelly zurück und lese das Image über esptool aus. -
@utze86
Habe nun ein 4MB image unter dem selben Release hochgeladen. Es gibt firmware_update und firmware_full unter dem letzten Release. *_full enthält alle Partitionen. Habe es nun als Backup von meinem Shelly entnommen. Das Flashen auf einen anderen Shelly war erfolgreich. Bin also recht optimistisch für deinen Versuch.
Wie das in platformio geht, ist mir noch ein Rätsel; aber das esptool kann ich wohl auch für das mergen benutzen. Sind für mich gerade viele Lern-Baustellen gleichzeitig
-
@giuseppes
Hab die Datei geladen und es nochmal mit dem ESPTool versucht. Zunächst erase_flash ausgeführt und im Anschluss write_flash ausgeführt. Habe leider wieder das gleiche Problem, aber das log sieht minimal anders aus, beachte die Ausdrücke in "dick":[20:45:21]
[20:45:21]devMode or deviceName is empty, starting CaptivaPortal
[20:45:21]Setting up AP Mode
[20:45:21]
[20:45:21]Brownout detector was triggered
[20:45:21]
[20:45:21]ets Jul 29 2019 12:21:46
[20:45:21]
[20:45:21]rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
[20:45:21]configsip: 188777542, SPIWP:0xee
[20:45:21]clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
[20:45:21]mode:DIO, clock div:2
[20:45:21]load:0x3fff0030,len:184
[20:45:21]load:0x40078000,len:12592
[20:45:21]load:0x40080400,len:2724
[20:45:21]entry 0x40080594
[20:45:21]EDIT: Hattest du mit Platformio oder ESPTool auf den anderen Shelly geflashed?
-
@utze86
Mein Vorgehen war wie folgt:- erase flash über platformio an ShellyA
- flashen über platformio
- auslesen komplett Image über esptool
- erase flash von ShellyB
- flashen des Image auf ShellyB
- einrichten des Shelly, ohne Probleme
Erklären kann ich mir die Fehler bei dir nicht. Dachte esp32 ist esp32...
Setzt du die korrekte Konfiguration für den Shelly 1 beim Einrichten? Da wo "optional" steht? Aber selbst "keine Konfig" dürfte nicht zu Fehlern führen.Evtl bestelle ich mir einen Shelly Plus 1PM. Könnte ein altes Modell ersetzen. Aber Schritt für Schritt. Für Shelly 2pm habe ich die Leistungsmessung am laufen. Sobald ich die automatische Kalibrierung der Rollläden umgesetzt habe, widme ich mich dem Shelly 1.
-
@utze86
Zum Fehler brownout triggered habe ich online einen Thread gefunden. Problem wurde behoben durch korrekte Baudrate. Diesen Befehl hatte ich benutzt:esptool.py --baud 115200 write_flash 0x0 firmware_full.bin
-
@giuseppes
okay, baud habe ich beim flashen nicht mit einbezogen, da mir der Befehl nichts gesagt hat. Ich werde morgen nochmal versuchen mit baud zu flashen. Wofür wird baud genau benutzt? Weißt du das? -
@utze86
Das ist die Übertragungsgeschwindigkeit. Aber, den Thread habe ich jetzt erst weiter gelesen, evtl ist die Spannungsversorgung nicht optimal?https://www.esp32.com/viewtopic.php?t=16299
Wenn ich dazu komme, werde ich in den kommenden Tagen versuchen, deinen Fehler zu reproduzieren. Ich denke eigentlich, wenn es an der Spannungsversorgung liegt, hättest du schon eher Probleme gehabt.
Edit:
Hier steht annähernd das selbe
https://randomnerdtutorials.com/esp32-troubleshooting-guide/#:~:text=Error%3A “Brownout detector was triggered”&text=It's often related to one,defect (bad solder joints)%3B -
@giuseppes
Okay. Ja ich habe es sowohl mit als auch ohne Konfiguration versucht aber das Ergebnis war das gleiche. Ich möchte nochmal darauf hinweisen, dass ich den Shelly Plus 1 habe, nicht den Shelly Plus 1 PM. Eventuell spielt das ja auch eine Rolle, von wegen Fehlerreproduktion. Nicht, dass du dir dafür extra den Shelly zulegst. -
@utze86
Danke für deine Bemühungen. Ich kann mir das nicht erklären, wieso es mit dem Shelly 1 scheitert.Nur für mein Verständnis:
Mit der 4MB Firmware hast Du auch das Verhalten, dass erstmalig nach dem Flashen ein CaptivePortal kommt, wo Du alles eintragen kannst? Die Daten werden dann auch übermittelt, weil es auf der Webseite angezeigt wird. Nach dem anschließenden Neustart kommen aber die Fehlermeldungen mit dem Brownout, korrekt? Oder kommen diese Fehlermeldungen sofort beim erstmaligen Start und du kommst nie auf den AP?Grundsätzlich beschreiben wir den esp32 mit der Firmware. Ob an den Pins Sensorik (PM) hängt oder nicht, spielt zumindest für den Shelly 1 keine Rolle. Bei der v0.0.1 fehlt von der Leistungsmessung noch jegliche Zeile Code. Alle Plus Modelle (bis auf Plus 2PM Ausnahmen mit DualCore) haben den selben Chip. Bei Tasmota läuft die selbe Version auch bei dir und bei mir...
EDIT:
Die load Befehle aus deinem letzten Log sehe ich bei mir auch. Kommen wohl vom Bootloader -
@giuseppes
Genau nach dem Flashen kommt die "Website" auf der ich alles eingebe. Dann tätige ich meine Eingaben für Wifi, MQTT, etc. und es kommt die Meldung dass alle Daten übermittelt wurden und das Gerät startet neu. Im Anschluss öffnet sich wieder der AP und alle vorher getätigte Eingaben sind verschwunden.Na wenn du die Logs auch erhältst, dann scheint es ja "normal" und das Flashen scheint bei mir ordnungsgemäß funktioniert zu haben. Ich kann es mir auch nicht erklären...
-
@utze86
Und im Log steht immerdevMode or deviceName is empty, starting CaptivaPortal?Edit: habe übrigens nochmals das firmware_full.bin auf einen frisch gelöschten Shelly aufgespielt. AP wurde gestartet, Werte eingegeben, Neustart, alles ok. Es muss mit dem Shelly 1 zusammenhängen. Ich denke, ich muss durch verschiedene Tests am Shelly 1 debuggen, was da genau los ist. Ich würde mich dann nochmal melden, wenn es soweit ist. Werde nun zunächst die Kalibrierung der Rollläden für 2pm fertigstellen.
-
@utze86
Habe heute meinen ShellyPlus1 bekommen (ohne "PM"). Werde damit im Flur den alten 1er ersetzen, sodass ich auch dort einen Scanner habeZum wesentlichen: Es funktioniert bei mir ohne Probleme.
Mein Vorgehen vollständig über esptool:
- Backup der original Firmware
python3 ./esptool.py read_flash 0x0 0x400000 fw-backup-4M.bin - Löschen des Speichers
python3 ./esptool.py erase_flash - Aufspielen der neuen Firmware
python3 ./esptool.py --baud 115200 write_flash 0x0 firmware_full.bin
AP wurde aufgerufen, habe Daten eingegeben und Submit ausgeführt. Daraufhin funktionierte alles. Habe dann VSCode gestartet, um den Log zu sehen und anschließend über die Shelly Reset-Taste den Shelly zurückgesetzt (>10s gedrückt halten). Mein log sah dann wie folgt aus:
- Interner Speicher wurde gelöscht
- AP wurde gestartet
- Config wurde übernommen
Ich habe immer mehr deine Spannungsversorgung über USB in Verdacht. Mit Tasmota o.ä. fällt es evtl nicht auf, weil die nach dem AP-Modus keinen Neustart ausführen, sondern fließend in den STA Modus übergehen. Ich wüsste nicht, wie ich das sauber umsetzen kann (wenn es überhaupt daran liegt).
P.S.:
Wieso bei mir zu beginn der esptool-Befehle python3 steht: Das esptool von meiner Kubuntu Distribution ist uralt (v2.8). Deshalb habe ich es original über github runtergeladen (=v4.5). Weil es nicht im System bekannt ist, muss ich es mit python3 aufrufen.Eine Kleinigkeit war mir übrigens aufgefallen, was aber nichts mit deinem Fehlerfall zu tun hatte: Die Konfiguration für den Shelly1 war bzgl. Reset Button falsch. Eingetragen war Pin27, korrekt ist Pin25.
- Backup der original Firmware
-
@giuseppes
Okay danke für die Rückmeldung. Ich werde es am Wochenende nochmal mit genau deinen Eingaben testen. Eventuell liegt ja der Fehler im Detail. Wundert mich dennoch das der Flash soweit durch läuft, aber wenn es bei dir funktioniert muss es ja in irgend einer Form an meinem Setup liegen. -
@utze86
Ans Setup habe ich auch gedacht. Hast du im Gerätenamen oder in deinen Wifi Daten Sonderzeichen?
Ansonsten spricht einiges für die Spannungsversorgung, hatte auch mal was über zu lange Flash-Kabel gelesen. -
@giuseppes
So ich setze mich jetzt nochmal dran. Hast du eigentlich unterm Schnitt bessere Ergebnisse mit deiner FW gegenüber der Messung mit Tasmota erzielt?Ja ich habe tatsächlich ein Sonderzeichen im Netzwerknamen.
-
@giuseppes
da ich ebenfalls mit Python3 arbeite habe ich es jetzt exakt mit deinen eingaben in python3 versucht... Copy... Paste. Leider besteht das Problem weiterhin, das log gibt folgendes aus:[20:58:10]
[20:58:10]devMode or deviceName is empty, starting CaptivaPortal
[20:58:10]Setting up AP Mode
[20:58:10]
[20:58:10]Brownout detector was triggered
[20:58:10]
[20:58:10]ets Jul 29 2019 12:21:46
[20:58:10]
[20:58:10]rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
[20:58:10]configsip: 188777542, SPIWP:0xee
[20:58:10]clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
[20:58:10]mode:DIO, clock div:2
[20:58:10]load:0x3fff0030,len:184
[20:58:10]load:0x40078000,len:12592
[20:58:10]load:0x40080400,len:2724
[20:58:10]entry 0x40080594
[20:58:11]Zur Info: Ich flashe den Shelly an meinem Rechner und stöpsel ihn aus. Danach hänge ich den Shelly per Kabel an die Steckdose, wenn dann der AP aufgespannt wird tätige ich die Eingaben. Ich betreibe den Shelly also nicht am USB Port falls das eine Rolle spielt oder den Fehler eingrenzt. Der Shelly dürfte somit im Betrieb eigentlich keine Probleme mit der Spannungsversorgung haben.
Wie dem auch sein. Bei dir läuft es ja, also muss das Problem irgendwo bei mir liegen. Ich frage mich jetzt halt ob ich noch weiter rumprobieren soll oder ob ich meine Tests mit Tasmota fortführe. Ggf. könne ich mich noch um einen anderen Rechner zum Flashen bemühen und das ganze nochmal mit einem anderen Shelly testen, dazu müsste ich mir dann aber erstmal was organisieren und einrichten.
Merkst du denn einen Unterschied zwischen deiner FW und Tasmota? Werden die RSSI gleich schnell gelesen? Wird das Signal in etwa gleich stark wahrgenommen? Hattest du das mal verglichen?
