meta data for this page
  •  

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

Link zu der Vergleichsansicht

Beide Seiten, vorherige ÜberarbeitungVorherige Überarbeitung
Nächste Überarbeitung		Vorherige Überarbeitung
gadget_entwicklung [2021/06/13 13:44] – [Kontakt mit einem WLAN aufnehmen] tomgadget_entwicklung [2025/04/17 05:39] (aktuell) – Externe Bearbeitung 127.0.0.1
Zeile 7: Zeile 7:
 Die Bedienbarkeit über Mobilgerät (Tablet, Handy, Android oder iOS, PC) erfordert eigentlich zwangsläufig eine Browserlösung mit Javascript. Das hat zwar ein paar hässliche Implikationen, weil die meisten Browserhersteller inzwischen der Meinung sind, lokal auf dem Gerät gespeicherte Dateien sind gefährlich, die von Servern aber nicht.  Die Bedienbarkeit über Mobilgerät (Tablet, Handy, Android oder iOS, PC) erfordert eigentlich zwangsläufig eine Browserlösung mit Javascript. Das hat zwar ein paar hässliche Implikationen, weil die meisten Browserhersteller inzwischen der Meinung sind, lokal auf dem Gerät gespeicherte Dateien sind gefährlich, die von Servern aber nicht. 
  
-Von der Hardware Seite war gefordert: Robustes Gehäuse, integrierte Stromversorgung, WiFi oder BLE, leichte Programmierbarkeit. Bei der Wahl des Steuergerätes wurde mir der ESP32 empfohlen, im Rückblick eine gute Wahl. Ich habe mich für das Developmentboard entschieden, das erfordert nicht so ganz gute Lötfähigkeiten. Die ESP32 haben etliche IO-Pins, sind über C++ programmierbar, es gibt etliche Bibliotheken, und ganz wichtig: Etliche Tutorials.+Von der Hardware Seite war gefordert: Robustes Gehäuse, integrierte Stromversorgung, WiFi oder BLE, leichte Programmierbarkeit. Bei der Wahl des Steuergerätes wurde mir der ESP32 empfohlen, im Rückblick eine gute Wahl. Ich habe mich für das Developmentboard entschieden, das erfordert nicht so ganz gute Lötfähigkeiten. Die ESP32 haben etliche IO-Pins, sind über C++ programmierbar, es gibt etliche Bibliotheken, und ganz wichtig: Viele Tutorials.
  
 ===== Hardwarekonzept ===== ===== Hardwarekonzept =====
Zeile 39: Zeile 39:
 Die Kommunikation erfolgt auf zwei Ebenen. Zum einen steht ein WebServer bereit, der statische Seiten serviert. Die Ursprungsidee war, dort nur die Konfiguration abzuhandeln und die eigentlichen LED-Programme lokal auf den Clients zu speichern. Das funktioniert auch prima mit dem FireFox auf dem Desktop, aber so gar nicht mit mobilen Clients unter Android (Safari unter iOS habe ich dann gar nicht mehr probiert...). Dort sind die Browserhersteller der Meinung, lokale Dateien sind viel gefährlicher als Web-Seiten, deswegen muss das unbedingt verboten sein. Kann man sich gar nicht ausdenken, so was. Die Kommunikation erfolgt auf zwei Ebenen. Zum einen steht ein WebServer bereit, der statische Seiten serviert. Die Ursprungsidee war, dort nur die Konfiguration abzuhandeln und die eigentlichen LED-Programme lokal auf den Clients zu speichern. Das funktioniert auch prima mit dem FireFox auf dem Desktop, aber so gar nicht mit mobilen Clients unter Android (Safari unter iOS habe ich dann gar nicht mehr probiert...). Dort sind die Browserhersteller der Meinung, lokale Dateien sind viel gefährlicher als Web-Seiten, deswegen muss das unbedingt verboten sein. Kann man sich gar nicht ausdenken, so was.
  
-Also braucht man entweder einen externen Web-Server oder die Seiten müssen auf den ESP. Wenn man als AP einen RasPi 4 nimmt, kann man auch noch gleich einen nginx oder lighttpd draufsetzen und gut. Das verkompliziert aber den Aufbau, also kommen die Seiten auf die Micros. Da der Speicher dort recht knapp ist, wurden die Seiten vor dem Upload weitgehend komprimiert. Einmal durch einen Minifier, und dann mit gzip verkleinert, bevor sie im PROGMEM der Micros landen. Beim Ausliefern muss lediglich noch der Header für "Inhalt kommt komprimiert" gesetzt werden, das Entpacken übernimmt der Client auf dem PC/Smartphone.+Also braucht man entweder einen externen Web-Server oder die Seiten müssen auf den ESP. Wenn man als AP einen RasPi 4 nimmt, kann man auch noch gleich einen nginx oder lighttpd draufsetzen und gut. Das verkompliziert aber den Aufbau, also kommen die Seiten auf die Micros. Praktischerweise sind von den 4MB Speicher 1.2MB für ein Dateisystem reserviert (Das war früher man die Kapazität einer Floppy...). Die einzelnen Dateien werden "minified" und gezippt. Beim Ausliefern muss lediglich noch der Header für "Inhalt kommt komprimiert" gesetzt werden, das Entpacken übernimmt der Client auf dem PC/Smartphone.
  
-Es gibt ein paar spezielle Seiten. Unter der Adresse "http://esp/scan" +Der Web-Server liefert HTML, Javascript und ein bischen CSS aus. Für die Kommunikation baut der Client eine Web-Socket Verbindung zu den ESPs auf, über die er Kommandos schicken kann. 
  
 +Das einfachste Kommando ist "STATE". Damit kommt als Antwort der Zustand der drei LED-Farben, der Zeit in Millisekunden seit dem Start des Micros, und der Wert des Toucheingangs. Die Farben werden als 0 und 1 ausgegeben, Eine typische Antwort wäre also "STATE001 231298 32". Fast genauso sieht auch die Nachricht vom Micro aus, wenn eine Berührung erkannt wird: "TOUCH001 234124 21".
  
-  * Async WebServer +Die weiteren Kommandos von Clientseite sind: 
-  * Start mit AP&Versuch, in ein WLAN einzuloggen. Grün Blink: Versuch +  * setX, wobei X zwischen 0 und 2 liegt: Schaltet Farbe X an (Rot, Grün, Blau) 
-  * Wenn in WLAN, Stop AP +  * SETxyz: x, y, z jeweils 0 oder 1: Setzt den Zustand Rot auf x, Grün auf y, Blau auf z. 
-  * Ansonsten bleibt AP 20 Minuten aktiv, dann Schlaf +  * CLR: Schaltet alle Farben dunkel
-  * in AP: http://192.168.4.1/scan mit reload, set name, SSID&PW +
- +
-Web-Sockets, clr, CLR set SET, STATE+
  
 +Als Antwort schickt der Micro jeweils den neuen Zustand, Zeit und Toucheingang zurück.
 ===== Software auf dem Browser ===== ===== Software auf dem Browser =====
  
 Es braucht nicht viel, ein Browser, der JavaScript kann. Getestet habe ich mit dem Firefox unter Linux und Windows, Safari unter iOS, sowie Fennec und Bromite unter Android. Etwas nervig ist die Angewohnheit moderner Browser, ''https'' zu verlangen und bei jeder Gelegenheit darauf zu wechseln. Dieses an sich positive Privacy Feature brauchen wir an der Stelle nicht. In die Adresszeile muss man also explizit ''http://esp00/portal.html'' eingeben. Am besten als Bookmark. Etwas sperrig stellen sich manche Browser an, den der Web-Host mal ein Nickerchen macht, insbesondere auf den Seiten, in denen die LEDs angesteuert werden. Am besten die ESPs aufwecken, zur Portalseite zurück gehen und neu laden. Es braucht nicht viel, ein Browser, der JavaScript kann. Getestet habe ich mit dem Firefox unter Linux und Windows, Safari unter iOS, sowie Fennec und Bromite unter Android. Etwas nervig ist die Angewohnheit moderner Browser, ''https'' zu verlangen und bei jeder Gelegenheit darauf zu wechseln. Dieses an sich positive Privacy Feature brauchen wir an der Stelle nicht. In die Adresszeile muss man also explizit ''http://esp00/portal.html'' eingeben. Am besten als Bookmark. Etwas sperrig stellen sich manche Browser an, den der Web-Host mal ein Nickerchen macht, insbesondere auf den Seiten, in denen die LEDs angesteuert werden. Am besten die ESPs aufwecken, zur Portalseite zurück gehen und neu laden.
 +
 +Bislang gibt es drei Seiten, die man tatsächlich im Training gebrauchen kann:
 +
 +demo01.html: Lässt den Trainer manuell jeweils eine LED ein- oder ausschalten. Gut zum Testen der Kommunikation und für Aufgaben, in denen es auf ein individuelles Timing ankommt.
 +
 +demo02.html: Die LEDs der eingebundenen Micros werden in einer zufälligen Reihenfolge eingeschaltet und bleiben kurz an und gehen wieder aus. Los geht die Sequenz, wenn man auf Start drückt. Bis zum Aufleuchten der ersten LED dauert es die Startverzögerung plus einer zufälligen Zeitspanne von 0 bis jitter. Die Pause zwischen den nächsten Schritten dauert auch wieder Delay plus zufälliges Jitter-Intervall. An bleibt die LED für die "On time". Alle Angaben sind in ms, wobei man die leider nicht so 100% ernst nehmen kann. 
 +
 +demo03.html: Macht fast das selbe wie demo02, aber die LEDs bleiben so lange an, bis der Touch-Interrupt ausgelöst wird. Die Dauer wird auf dem Client angezeigt.
  
 ===== Anwendung in der Praxis ===== ===== Anwendung in der Praxis =====