WS2812 LEDs in HomeKit einbinden?

[HaSch]

RE: ESP8266 D1 Mini Relais als HomeKit Schalter ohne Bridge - Tutorial

Ich bin auf diesen Beitrag gestoßen, weil ich einen Lightstrip, der an einem D1 ESP8266 Mini Pro hängt und per Webserver gesteuert wird, in Homekit einbinden wollte. Mit dem Beitrag war es ganz einfach, ein Relais in Homekit einzubinden und zu steuern. Wie aber geht das mit einem Lightstrip (WS2812, also individuell ansteuerbare LEDs)?
Wäre schön, wenn es dazu in absehbarer Zukunft noch ein Tutorial geben würde.

[cooper]

Hey, freut mich dass es reibungslos geklappt hat

Also du könntest auch mit dem Code schon sehr leicht deine LEDs einbinden. Was bei Druck auf den Schalter passiert, lässt sich ziemlich einfach ändern.

// Diese Funktion wird aufgerufen, wenn der Schalter in HomeKit betätigt wird
void cha_switch_on_setter(const homekit_value_t value) {
  bool on = value.bool_value;h
  cha_switch_on.value.bool_value = on;
  LOG_D("Switch: %s", on ? "ON" : "OFF");
  digitalWrite(PIN_SWITCH, on ? HIGH : LOW);
}

So kannst du sie zumindest schon mal an und ausschalten. Deine Steuerung, FastLED? WLED? Könntest du mit Sicherheit auch parallel dazu verwenden. Bzw eben deinen Webserver zur Not um die Patterns zu switchen.

---

Ich bin noch nicht dazu gekommen mich weiter mit der Libary zu beschäftigen…

Aber ohnehin wirds es schwierig die WS2812 LEDs mit allen Funktionen einzubinden. Es gehen in Homekit halt nur die Standard RGB Schalter mit Reglern etc.

Müsste man eine custom Lösung zurechtstückeln.

[HaSch]

Hallo cooper,

schön, dass du so schnell geantwortet hast.

Damit du eine Vorstellung hast, was ich da einbinden möchte, schicke ich mal einen Link. Ich habe das Projekt leicht verändert und ein paar bugs entfernt aber prinzipiell funktioniert es so, wie dargestellt. Das will ich auch nicht groß verändern. Über HomeKit sollen nur die NeoPixel LEDs ein/ausgeschaltet werden und die verschiedenen vorgefertigten Scenes eingestellt werden können. Schieberegler bedienen wäre auch ganz schön, muss aber nicht sein.

Gruß
Hans

[cooper]

Update: Also ich saß jetzt gefühlt 2h dran und hab versucht das ganze zu implementieren. Es scheitert aktuell wie es aussieht am Webserver. Ich hab das Problem noch nicht gefunden, der Schalter lässt sich pairen und erscheint auch. Leider gibt es aber dann keine Rückmeldung vom Schalter. Danach bricht der ESP zusammen und startet neu. Das ganze immer wieder. Ich hab auch versucht den Fehler auf verschiedene Weisen auszumerzen - keine Chance.

Scheint doch ein wenig aufwendiger zu sein mit der NeoPixel Libary. Aktuell hab ich da leider keine Plug & Play Lösung…

---

Ich denke da muss vielleicht was eigenes her

[HaSch]

Also:
Ich habe ebenfalls festgestellt, dass es soo einfach nicht ist. Meine WLAN-Einstellungen werden im EEPROM gespeichert und das scheint durch die HomeKit-Library überschrieben zu werden. In der Folge kann keine Verbindung zum WLAN mehr hergestellt werden und dann klappt das natürlich auch mit dem HomeKit nicht mehr. Ich werden mich wohl mal etwas intensiver mit der HomeKit-Library beschäftigen müssen. Dazu komme ich aber frühestens nächste Woche.

[cooper]

Ja, den EEPROM musst du in deiner NeoPixel Libary bearbeiten.

EEPROM.begin(1408);

Ich zitiere:

• The EEPROM is 4096B in ESP8266, this project uses max [0, 1408B)
• EEPROM of [1408, 4096) is safe for you to use.

Quelle: Arduino HomeKit ESP8266

Dann klappt das auch mit der WLAN Verbindung. Es sah ja zuerst super aus. Ich konnte den Streifen steuern übers Web, finden in Homekit und auch pairen. Aber dann ist der Wurm drin… 🧐

Wäre cool wenn du dich meldest wenn du weiter kommst, bin jetzt auch auf den Geschmack so einer Lampe gekommen…

[HaSch]

@cooper
Ja, das hatte ich auch schon gefunden. Das hat aber nichts mit der NeoPixel Library zu tun sondern damit, an welcher Stelle im EEPROM die WLAN-Zugangsdaten abgespeichert werden. Richtig ist:

EEPROM.begin(4096);

und auch an einigen anderen Stellen muss der Code angepasst werden. Damit ist es mir mittlerweile gelungen, die LEDs in HomeKit einzubinden. Über den Webserver lässt sich die Lampe weiterhin steuern aber über HomeKit geht (noch) nichts.

[cooper]

Bei mir hatte das funktioniert. Na ja aber klingt ja schon mal sehr vielversprechend.

Nur eine Frage:

Kannst du den D1 Mini koppeln und auch steuern, nur tut sich mit den LED noch nichts? Oder hast du das selbe Problem was ich nachträglich beschrieben hatte bzgl. koppeln geht aber sobald ich schalte nichts mehr?

Gruß

[HaSch]

@cooper
Also: Wenn ich versuche, über HK zu steuern, geht der “Schalter” an und gleich wieder aus. Bei den LEDs tut sich nix. Das ist aber auch klar, weil über HK ja nur ein PIN des D1 (ist übrigens ein Mini Pro, also mit 16MB Speicher, ist für den Webserver erforderlich) geschaltet wird. Das muss noch so geändert werden, dass die richtige Zeichenfolge an den Webserver weitergereicht wird, statt den PIN einzuschalten. Ich habe im Code gesehen, dass das PIN 15 ist, das Relais ist aber an D8 angeschlossen. Ist das der PIN 15?

[cooper]

Ja Pin D8 ist GPIO 15.

Willst du über den Webserver zugreifen oder auf die Funktion zum Einschalten direkt?

---

Komisch ist aber auch, dass der Schalter gleich wieser aus geht. Weil der Pin sollte ja eig High gehen. Auch ohne Relais. Oder hast du den schon als Input definiert?

[HaSch]

@cooper
Ich will über den Webserver zugreifen und nach Möglichkeit alles das, was ich über den Webserver kann, auch über HK machen.

Ich habe nun mal den Namen des Schalters geändert und den neu kompilierten Sketch hoch geladen. Nun geht es mit dem Einschalten über HK, ohne dass sich der “Schalter” gleich wieder ausschaltet. War wohl nur etas wackelig. Auf die LEDs aber hat das (wie erwartet) keinen Einfluss.

[HaSch]

@HaSch
PIN D8 ist auch meine Datenleitung für die NeoPixel LEDs, das beißt sich dann.

[HaSch]

@HaSch
Habe ich jetzt mal auf PIN 16 gesetzt, das ist D0.

[cooper]

Klappt es dann mit dem Schalter?
Bleibt er an?

Wäre natürlich geil weil dann… Homekit Lampe incoming

[HaSch]

@cooper
Prinzipiell klappt es dann, aber wackelig ist es immer noch. Ab und zu startet das Board neu und dann muss ich den Schalter wieder neu in HK einbinden. Auch wenn er mal stromlos war, wird er nicht wieder gefunden. Wenn er aber drin ist, kann auch ein Relais an D0 geschaltet werden.

[HaSch]

@HaSch sagte in WS2812 LEDs in HomeKit einbinden?:

@cooper
Prinzipiell klappt es dann, aber wackelig ist es immer noch. Ab und zu startet das Board neu und dann muss ich den Schalter wieder neu in HK einbinden. Auch wenn er mal stromlos war, wird er nicht wieder gefunden. Wenn er aber drin ist, kann auch ein Relais an D0 geschaltet werden.

Das ist aber kein Problem, das wegen der LED-Geschichte auftaucht, das hat ein Board nur mit Relais (an D8) auch.

[cooper]

homekit_storage_reset();

Kommentier die Zeile mal aus. Aus deinem setup() dann musst du nicht dauern neu pairen.

[HaSch]

@cooper sagte in WS2812 LEDs in HomeKit einbinden?:

homekit_storage_reset();

Geht trotzdem nicht. Ich kann einige Male schalten, dann wird das Board in HK wieder nicht gefunden.

Ab und zu startet das Board ohne erkennbaren Grund auch neu. Den Grund habe ich noch nicht gefunden, Brownout?

[cooper]

Hm. Vielleicht braucht beides zusammen zu viel Ressourcen. Ich kann dir da leider nicht mehr weiterhelfen, hatte ja das selbe Problem - bin mit meinem Latein am Ende.

Aber ich denke demnächst werde ich mich nochmal damit beschäftigen. Vielleicht nicht FastLED, aber irgendwas eigenes, das dann hoffentlich auch mit Homekit läuft.

Würde mich trotzdem freuen, wenn du hier weiterhin dein Werdegang teilst, ich verfolge das mit großem Interesse. 🤩

[HaSch]

@cooper
Ich habe mir gerade mal den Output vom Exception Decoder des “unmotivierten” Neustarts angesehen aber der sagt mir nicht viel. Vielleicht kannst du ja etwas damit anfangen:

Decoding stack results
0x401004a8: _write_r(_reent*, int, char*, int) at /Users/hasch/Library/Arduino15/packages/esp8266/hardware/esp8266/2.7.3/cores/esp8266/libc_replacements.cpp line 90
0x4023ac6d: __sfputs_r at /home/earle/src/esp-quick-toolchain/repo/newlib/newlib/libc/stdio/nano-vfprintf.c line 433
0x40236508: __swrite at /home/earle/src/esp-quick-toolchain/repo/newlib/newlib/libc/stdio/stdio.c line 105
0x40235ab1: _printf_i at /home/earle/src/esp-quick-toolchain/repo/newlib/newlib/libc/stdio/nano-vfprintf_i.c line 194
0x4023bb45: __sflush_r at /home/earle/src/esp-quick-toolchain/repo/newlib/newlib/libc/stdio/fflush.c line 226
0x4023bbd5: _fflush_r at /home/earle/src/esp-quick-toolchain/repo/newlib/newlib/libc/stdio/fflush.c line 282
0x4023b7ff: __swbuf_r at /home/earle/src/esp-quick-toolchain/repo/newlib/newlib/libc/stdio/wbuf.c line 82
0x4023ac07: __sfputc_r at /home/earle/src/esp-quick-toolchain/repo/newlib/newlib/libc/stdio/nano-vfprintf.c line 404
0x4023ac6d: __sfputs_r at /home/earle/src/esp-quick-toolchain/repo/newlib/newlib/libc/stdio/nano-vfprintf.c line 433
0x4021d1b9: ClientContext::_write_from_source(DataSource*) at /Users/hasch/Library/Arduino15/packages/esp8266/hardware/esp8266/2.7.3/libraries/ESP8266WiFi/src/include/ClientContext.h line 472
0x4023adf4: _vfprintf_r at /home/earle/src/esp-quick-toolchain/repo/newlib/newlib/libc/stdio/nano-vfprintf.c line 531
0x40100b27: free(void*) at /Users/hasch/Library/Arduino15/packages/esp8266/hardware/esp8266/2.7.3/cores/esp8266/umm_malloc/umm_malloc.cpp line 398
0x4021f886: send_tlv_response(_client_context_t*, tlv_values_t*) at /Users/hasch/Documents/Arduino/libraries/HomeKit-ESP8266/src/arduino_homekit_server.cpp line 793
0x4023b692: vprintf at /home/earle/src/esp-quick-toolchain/repo/newlib/newlib/libc/stdio/vprintf.c line 40
0x4010089f: umm_free_core(void*) at /Users/hasch/Library/Arduino15/packages/esp8266/hardware/esp8266/2.7.3/cores/esp8266/umm_malloc/umm_malloc.cpp line 351
0x40237984: printf_P at /home/earle/src/esp-quick-toolchain/repo/newlib/newlib/libc/sys/xtensa/stdio_pgmspace.c line 15
0x4022021f: homekit_server_on_pair_verify(_client_context_t*, unsigned char const*, unsigned int) at /Users/hasch/Documents/Arduino/libraries/HomeKit-ESP8266/src/arduino_homekit_server.cpp line 1779
0x40220229: homekit_server_on_pair_verify(_client_context_t*, unsigned char const*, unsigned int) at /Users/hasch/Documents/Arduino/libraries/HomeKit-ESP8266/src/arduino_homekit_server.cpp line 1784
0x40100b5c: malloc(size_t) at /Users/hasch/Library/Arduino15/packages/esp8266/hardware/esp8266/2.7.3/cores/esp8266/umm_malloc/umm_malloc.cpp line 552
0x40100ba5: realloc(void*, size_t) at /Users/hasch/Library/Arduino15/packages/esp8266/hardware/esp8266/2.7.3/cores/esp8266/umm_malloc/umm_malloc.cpp line 586
0x40222170: homekit_server_on_message_complete(http_parser*) at /Users/hasch/Documents/Arduino/libraries/HomeKit-ESP8266/src/arduino_homekit_server.cpp line 2796
0x40204df8: http_parser_execute at /Users/hasch/Documents/Arduino/libraries/HomeKit-ESP8266/src/http_parser.c line 1928
0x4022104c: homekit_server_accept_client(homekit_server_t*) at /Users/hasch/Documents/Arduino/libraries/HomeKit-ESP8266/src/arduino_homekit_server.cpp line 3016
0x40220f21: homekit_client_process(_client_context_t*) at /Users/hasch/Documents/Arduino/libraries/HomeKit-ESP8266/src/arduino_homekit_server.cpp line 2938
0x402211b2: homekit_server_process(homekit_server_t*) at /Users/hasch/Documents/Arduino/libraries/HomeKit-ESP8266/src/arduino_homekit_server.cpp line 3120
0x402224e1: arduino_homekit_loop() at /Users/hasch/Documents/Arduino/libraries/HomeKit-ESP8266/src/arduino_homekit_server.cpp line 3596
0x40217102: my_homekit_loop() at /Users/hasch/Documents/Arduino/New_IKEAHack_20200824_HK/New_IKEAHack_20200824_HK.ino line 89
0x4021b871: loop() at /Users/hasch/Documents/Arduino/New_IKEAHack_20200824_HK/New_IKEAHack_20200824_HK.ino line 1470
0x40224834: loop_wrapper() at /Users/hasch/Library/Arduino15/packages/esp8266/hardware/esp8266/2.7.3/cores/esp8266/core_esp8266_main.cpp line 197

[cooper]

Leider sagt mir das nichts. Aber ich vermute dass die beiden loops() dafür verantwortlich sein können. Evtl. ist auch die Leistung vom ESP8266 für beides parallel nicht ausreichend.

Vielleicht kannst du deinen aktuellen Code mal hier veröffentlichen, dann kann @Fl0ri4n das ganze mal auf einem ESP32 testen. Vielleicht kommen wir der Lösung dadurch näher.

Grüße

[HaSch]

@cooper
Ich habe mittlerweile herausgefunden, dass der Watchdog Timer (WDT) dafür verantwortlich ist. In der Dokumentation zur Homekit Library befindet sich ein Hinweis darauf. Während der Preinit-Phase und der Pairing-Phase werden in der Library (in arduino_homekit_server.cpp) der Hardware- und Software-WDT abgeschaltet, danach wieder eingeschaltet. Als ich das Einschalten temporär wieder unterbunden habe, lief der Homekit-Schalter auf einem Wemos D1 Mini Pro wie von dir veröffentlicht ohne Neustart durch (allerdings kann er immer noch nach einiger Zeit durch HK nicht mehr gefunden werden). Bezüglich der ws2812-Geschichte brachte die Änderung der Library allerdings keinen Fortschritt.

Der aktuelle Code:
New_IKEAHack_20200824_HK.zip

[dieterh]

@HaSch ich habe gerade über einen anderen Thread entdeckt, dass es scheinbar jetzt auch eine WS2812 Einbindung für HomeKit gibt, mit der selben Libary.

https://github.com/Mixiaoxiao/Arduino-HomeKit-ESP8266/tree/master/examples

Da gibt es neuerdings dieses Example:

Example05_WS2812_Neopixel

[HaSch]

Leider habe ich nicht automatisch eine Benachrichtigung bekommen, wenn sich in diesem Thread etwas tut. Daher habe ich heute erst den Hinweis von @dieterh gefunden. Ich habe jetzt aber mal versucht, die Benachrichtigung einzuschalten.
Das Beispiel ist super, funktioniert alles wie es soll, ohne den Watchdog auszulösen. Ich habe aber auch - wie ich irgendwo gelesen habe - das ganze mit einer CPU-Frequenz von 160MHz kompiliert, damit ich keine Timeout Probleme bekomme. Vielleicht hat das ja auch etwas bewirkt.
Momentan läuft schon den ganzen Tag sehr stabil ein Dauertest. Anschließend versuch ich mal, das Ganze in den Code des IKEA-Lampen-Hacks einzuarbeiten. Ich melde mich dann hier wieder, wenn ich weiter gekommen bin.

[HaSch]

Es funktioniert, allerdings musste ich nach längerem Ausschalten jetzt wieder mit HK paaren. Da stehen noch ein paar Tests an. Außerdem muss ich noch den Code bereinigen, weil er doch recht unübersichtlich geworden ist.

[cooper]

@HaSch Das scheint ein typisches Problem zu sein. Das hab ich jetzt nicht nur von dir gehört. Das mit dem Pairen.

Aber mal sehen was sich da unten Zukunft noch tut.

Hast du auch deine Animationen rein bekommen oder wie hast du es jetzt gelöst? Hast du jetzt immer nur eine Animation, oder kannst du die auch wechseln?

[HaSch]

@cooper So, den Code habe ich jetzt mal bereinigt.
Das mit dem Pairen scheint aber mit der Kombination der beiden Sketche zusammenzuhängen, im Beispielcode klappt es nämlich.
Die Animationen sind drin, die Kombination von ursprünglichem Sketch und Homekit funktioniert ganz gut. Die Steuerung über das Webinterface hat Vorrang gegenüber HK, d.h. wenn über das Webinterface eingeschaltet ist, kann ich über HK aus- und wieder einschalten, es läuft dann wieder so, wie über das Webinterface eingestellt ist. Wenn ich über das Webinterface ausgeschaltet habe, kann ich über HK einschalten und alle Einstellungen vornehmen. Eigentlich perfekt, wenn da nur nicht das Problem mit dem Pairen wäre…

Übrigens: Benachrichtigungen bei neuen Beiträgen bekomme ich hier immer noch nicht obwohl das mittlerweile eingeschaltet sein sollte.

[HaSch]

Ich habe Folgendes herausgefunden:
Wenn ich das Beispiel benutze (HK ohne das andere Gedöns) und das Board kurz stromlos mache, finde ich anschließend im Log die Zeilen:
[ 5206] HomeKit: Starting server
[ 5210] HomeKit: Using existing accessory ID: xx:xx:xx:xx:xx:xx

Wenn ich aber den anderen Sketch nehme, legt der HK Server eine neue accessory ID an:
[ 7359] HomeKit: Starting server
[ 7362] HomeKit: Formatting HomeKit storage at 0x3fb000
[ 7458] HomeKit: Generated new accessory ID: yy:yy:yy:yy:yy:yy

Scheinbar hängt das mit dem Formatieren des HK Speichers zusammen…
Die Zeile homekit_storage_reset() ist im Sketch NICHT aktiv (in keinem der beiden).

Irgend eine Idee?

[cooper]

@HaSch Probiere vielleicht mal einen Async Webserver statt dem normalen. Evtl. hängt es damit zusammen. Immerhin tritt das Problem doch nur ob Verbindung damit auf, oder?

https://github.com/me-no-dev/ESPAsyncWebServer

[HaSch]

@cooper Ich habe herausgefunden, was die Ursache ist, habe aber noch keine Lösung des Problems gefunden.
HK belegt im EEPROM den Speicher bis maximal 1408, ab da ist frei bis 4096. Eine Library wird dafür nicht benötigt. In dem Sketch mit dem Webinterface wird aber die EEPROM Library benutzt. Wenn ich nun die Anweisung EEPROM.begin(4096) aufrufe, wird der Schlüssel, den HK beim Pairen angelegt hat, gelöscht. Die Folge ist, dass ich beim nächsten Mal wieder neu pairen muss. Leider gibt es in der EEPROM Library keine Anweisung, nur einen Teil des Speichers zu initialisieren.
Wenn ich nun die Anweisung aus dem Sketch rausnehme und diesen neu hoch lade, funktioniert es zunächst scheinbar (weil die Daten, die der Webserver im EEPROM ab der Adresse 1408 in der vorigen Sitzung abgelegt hat, gelesen werden können), sobald aber eine Änderung gemacht wird, die abgespeichert werden soll, geht das nicht mehr.
Man müsste zu Beginn des Sketches vor der Initialisierung den Speicher bis 1408 auslesen und zwischen speichern, dann das EEPROM initialisieren und anschließend die Daten wieder ablegen.
Fällt dir noch eine andere Möglichkeit ein?