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/12 10:38] – [Software auf dem Browser] 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 29: Zeile 29:
  
 ==== Kontakt mit einem WLAN aufnehmen ==== ==== Kontakt mit einem WLAN aufnehmen ====
 +
 +Beim Start wird das WLAN zweigleisig initialisiert. Zum einen wird versucht, sich als Client im letzten bekannten WLAN einzuloggen. Gleichzeitig wird auch ein eigenes WLAN als Accesspoint aufgespannt. Das ist komplett offen. Falls das Einloggen als Client erfolgreich ist, wird der AP abgeschaltet. Falls der Client nicht innerhalb von 60s in ein WLAN einloggen kann, wird der Versuch aufgegeben. Der AP bleibt dann insgesamt 10 Minuten aktiv. In der Zeit kann man sich mit diesem offenen WLAN verbinden, und die URL http://192.168.4.1/scan aufrufen. Beim ersten mal sieht man, dass die Verbindung erfolgreich war, beim zweiten mal sieht man alle aktiven Netzwerke in der Umgebung. Von denen kann man sich dann eins aussuchen und konfigurieren. Ja, dass man diese Seite zweimal aufrufen muss ist ein Bug.
 ==== Updates über OTA ==== ==== Updates über OTA ====
  
Zeile 37: 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 =====
 +
 +Ich habe mir auf einen Raspi einen Accesspoint installiert, der mir im Training ein WLAN für die ESPs und mein Tablet aufspannt, und es kann losgehen. Soft- und Hardware haben beim Training zuverlässig funktioniert, aber es gab einen unschönen Effekt. Die LEDs sind etwas mager. Wenn es hell genug ist in der Halle, sind sie manchmal schwer zu sehen. Insbesondere die grünen LEDs waren vor unserem, leider grünlichen Hallenboden, schwer zu sehen (ich könnte schwören, dass der vor Corona grau war...). Deswegen sollte man beim Aufbau des LED-Rings darauf achten, dass die LEDs aus dem Deckel herausspitzen, ansonsten ist es wirklich schwer zu sehen. Außerdem sollte der Vorwiderstand für die drei grünen LEDs verringert werden, damit man nächer an die 20mA/LED herankommt, und die Dinger etwas heller leuchten. Rot und Blau funktionieren prima.
 +
 +Ich habe mit den Mädels Reaktionstest gemacht (demo03), vier Stück im Quadrat, möglichst schnell berühren, hat gut funktioniert. demo02 war nicht so wirklich gut, weil das Grün schwer zu erkennen war. Die habe ich kombiniert mit der Aufgabe: Rot=Blocksprung, Blau=Pritschbewegung, Grün=Bagger mit Ausfallschritt. Ansonsten haben wir festgestellt, dass ein Quadrat von etwa 2x2m schon verdammt schwer im Auge zu behalten ist. Mir fehlen da noch die Vergleichswerte, und spannend ist, ob sich das im Laufe von weiteren Trainings verbessert.
 +
 +Auf dem Plan habe ich noch, einen Spieler oder eine Halterung beim Einschlagen von der IV auf die I und die V zu stellen. Zwischen Anspiel zum Zuspieler und Schlag leuchtet einer der Pods auf, und entsprechend soll Longline oder Diagonal geschlagen werden. Aber da ist erst mal noch ausgiebiges Stellertraining vor...
 +
 +Weitere Ideen von außerhalb nehme ich natürlich gerne auf.