Handhabung & Technik Besteht Interesse an einer DIY Zündanlage?

Nochmal Statusupdate.

Die Android Oberfläche ist jetzt dynamisch und zeigt N x 8 Kanäle an. Ich kann damit meine beiden Module (8 und 16) steuern.

Im 8 Kanal Modus ist die Scharfschaltung von den Kanalbuttons schwer zu unterscheiden. Da will ich mir noch was überlegen, wie das besser geht.

Ansonsten geht es jetzt direkt weiter mit der Multimodul Geschichte.

 

Wenn ich soweit bin, dass die Funktionen drin sind und ich mit der Codequalität einigermaßen zufrieden bin, veröffentliche ich den Source ganz allgemein (für beide Teile).
Findet sich bestimmt jemand, der noch was beizutragen hat oder das Grundgerüst brauchen kann.
Ich selbst bin allerdings kein Android Spezialist, ist sicherlich nicht optimal gelöst.

Falls du vorab schonmal den aktuellen Stand willst, kann ich dir den gerne zukommen lassen.

 

Ich hab mal Screenshots angehängt, wie das aussehen kann mit 8 und 16 Kanälen.
Ich bin mir noch nicht sicher, wo ich den Button zum Scharfschalten am besten platzieren soll. Unten mittig (letztes Bild) ist symmetrisch. Button nach links sorgt mehr dafür, dass man ihn garantiert nicht mit einem Kanal verwechseln kann.

Ansonsten könnte ich auch die Scharfschaltung in die Toolbar machen und unten nur noch den Text anzeigen.

 

Ich hab jetzt noch eine deutlich andere Variante gefunden. Vorteil ist, dass die Scharfschaltung jetzt komplett anders aussieht.

Ich habs leider nicht hinbekommen, den Switch genau in die Mitte zu setzen. Also ist er jetzt erstmal rechts.

 

Master Slave hatte ich mittlerweile mal ausprobiert. Macht die Modulsoftware recht komplex und gefällt mir nicht.
Das Problem mit Android als AP und Module als Clients ist geklärt. Ich hatte den Modulen statische IPs vergeben. Da Android den AP aber in einen anderen Adressbereich packt, als meinen Router, kann das natürlich nicht funktionieren.
Mit dynamischer IP kann ich die Module ansprechen.

 

Mal der aktuelle Status:

Ich schreibe die APP gerade quasi neu. Grund ist, dass ich mit dem Multimodulkonzept eine Kapselung der Steuerfunktionen brauche und mir ist das zu blöd, jetzt in dem großen unübersichtlichen Code zu refaktorieren. Daher übernehme ich nach und nach die Funktionen, die ich brauche.

Ich habe jetzt damit angefangen, dass ich überhaupt erstmal die angemeldeten Module finden kann. Die App findet aktuell schon die verbundenen Clients und deren IP und zeigt sie in einer Liste an.
Die Modulsoftware ist bereits fähig, im EEPROM ssid, password und einen namen/alias für das Modul zu speichen. Das Modul versucht sich als Client im WiFi anzumelden. Wenn das nach 30sec noch nicht geklappt hat, dann wechselt das Modul in den Konfigurationsmodus und macht selbst einen AP mit den eingestellten default ssid/password auf.

Die Konfiguration kann man prinzipiell einfach per Webbrowser machen. Ob ich da noch eine Funktion in der App vorsehe, weiß ich noch nicht. Aktuell mach ich das selbst auch so, dass ich mein Android als Client zum Modul verbinde und dann einfach die passende URL im Browser aufrufe.

Was meint ihr, reicht das für die Konfiguration so aus? Die Lücke ist halt die Standardeinstellung. Wenn man die vorm Einspielen der Software nicht ändert, dann kennt jeder, der den Source kennt auch die Daten und kann sich connecten, sofern das Modul keinen Hotspot findet. Das sollte in der Praxis nicht passieren, aber wenn man vergisst, den Hotspot anzuschalten, dass ist das Modul erstmal in der Konfiguration.
Wirklich richtig kaputt machen kann keiner was. Der Konfigurationsmodus lässt keine weitere Steuerung zu (da kann also niemand was zünden). Wenn man allerdings danach das Modul neu startet und da hat jemand die Daten verändert und er hat den passenden Hotspot offen, dann kanns problematisch werden.
Ich hatte auch überlegt, ob ich im Konfigurationsmodus einen Softwarereset des Moduls über WiFi ermögliche. Aber dann wäre das Szenario noch problematischer.

Safe wird die Sache natürlich dann, wenn man 1. eigene Daten vergibt und 2. dafür sorgt, dass man beim Einschalten der Module mit dem Hotspot in der Nähe ist und prüft, ob alle Module gefunden wurden. Erst dann schaltet man mechanisch scharf.

Das schlimmste, was dann noch passieren kann ist, dass ein Modul aus irgend einem Grund nen Reset macht und den Hotspot nicht mehr rechtzeitig findet. Dann ist es im Konfigurationsmodus und das wars dann erstmal.
Das kann ich aber leider absolut nicht verhindern, wenn eine Konfiguration über WiFi möglich sein soll.

Alternativ könnte man auch über Serial (USB) konfigurieren oder eben direkt hardcoded. Beides ist nicht besonders nutzerfreundlich, würde aber den AP Modus obsolete machen und beim Reset zumindest sicher wieder im normalen Modus hochfahren.


Was ist noch offen?
1. Konfigurationskonzept final festlegen (ich denke der aktuelle Ansatz ist ok, ein ungeplanter Modulreset wäre sowieso ein Problem, da ist es egal, ob es hier vielleicht auch final die Verbindung verliert).

2. N Module für Direktsteuerung im UI der App unterstützen. Hier bin ich noch unsicher, wie ich den Wechsel zwischen den Modulen machen will. Normalerweise würde ich einfach "Swipe" nutzen, allerdings swiped man dann über die Feuerbuttons drüber. Weiß nicht, ob das sooo toll ist. Vielleicht mache ich das aber auch über die Toolbar oder ich lasse die Direktsteuerung für Multimodul nur im Landscape Modus zu und zeige die Module nebeneinander (gleichzeitig) an. Das wäre dann aber nur noch mit Tablet praktikabel. Vorteil wäre hier, dass man wieder Kanäle von verschiedenen Modulen gleichzeitig erreichen kann.

3. N Module für Direktsteuerung in der Kommunikation der App unterstützen. Muss ja auch alles ans richtige Modul gehen und Statusabfragen müssen passend zugeordnet werden.

-- An der Stelle wäre die App dann schon nutzbar --

4. Kombinierbarkeit von Kanälen zu virtuellen "Kanälen". Also eine Oberfläche, in der man frei belegen und auch kombinieren kann (Modul A Kanal 3 + Modul B Kanal 7). Hier kommt dann aber die Problematik hinzu, dass Spannung und Sicherungszustand der einzelnen Module ja getrennt laufen. Der virtuelle Kanal muss dann checken, ob auch beide Module scharf sind und genug Spannung haben. Ansonsten muss der Kanal irgendwie ein Problem signalisieren. Das wird noch ne Kopfnuss, das umzusetzen.

 

Direkt am Modul will ich keine weiteren Knöpfe und Schalter anbringen. Das attraktive ist doch, dass man mit so wenig auskommt.
Daher scheidet ein Werksreset in der Form aus. Es gibt zwar einen User Button, der funktioniert aber nicht einfach so. Dazu müsste man wohl an dem entsprechenden Pin einen Pullup setzen. Hinzu kommt das Problem, dass man diesen Button nicht beim Start drücken darf, sonst geht das Teil in den Flash Modus.

Was ich machen könnte, wäre ein Hack mit der Versorungsspannung. Wenn er über USB Power bekommt und nicht über Vin versorgt ist, dann messe ich quasi 0V. Das könnte man als Bedingung einbauen, damit er in den Konfigurationsmodus geht (falls Verbindung zum AP nicht möglich).
Dann hat man aber wieder das Problem, dass man die Kiste aufmachen und ans Kabel hängen muss, damit man konfigurieren kann (dann könnte man auch direkt das Sketch hardcoded ändern und hochladen).

Das mit dem scharf schalten muss ich mir mal noch anschauen. Ich bekomme direkt feedback, wenn der Request ankam. Somit weiß ich, dass das Modul was empfangen hat. Allerdings kommt der Status auch zyklisch zurück und könnte sich ändern (z.B. bei Neustart). In dem Fall ist fraglich, was passieren soll.
- Wieder automatisch scharf schalten, weil die App diesen Zustand als Zielzustand hat?
- Oder die App auf unscharf stellen, weil ein Modul abgeschalten hat?
- Oder nix machen und irgendwie den Differenzzustand anzeigen?

Mein Ansatz ist aktuell der, dass die App komplett die Kontrolle hat. Demnach darf sie auch gerne ein Modul wieder scharf schalten. Die Module sind nur dumme Befehlsempfänger und folgen keiner eigenen Logik.
Wobei ich es plausibel finde, nach einem Timeout auf sicher zu stellen, wenn sich die App nicht mehr meldet. In dem Fall muss die App aber immer mit allen Modulen zugleich kommunizieren. Das ist aktuell nicht der Fall, da kommuniziert sie nur mit dem aktiv ausgewählten Modul.

Scharfschalten in die Toolbar hab ich auch schon überlegt und den Switch nur noch passiv zum anzeigen.

Benennung der Kanäle hab ich ja schon im Plan. Allerdings muss man das dann auch irgendwie persistieren. Das klappt aber nur, wenn man auch wieder korrekt dem passenden Modul zuordnen kann. Das wird noch etwas fummelig, daher schiebe ich das nach hinten.

Mit Swipe bin ich grad am rumprobieren. Allerdings braucht man dafür die Support Libs und da ist die Unterstützung im Eclipse eher schlecht. Hab mir jetzt mal Android Studio besorgt. Wenn es klappt, dann kann ich so ganz easy Tabs für die Module anzeigen und per Swipe wechseln. Man kann aber auch einfach auf die Tabs klicken.

Nur bezünderte Kanäle anzuzeigen ist ne ganz gute Idee. Allerdings sieht man dann nicht sofort, wenn was fehlt. In der aktuellen Variante sieht man halt alle Kanäle und was nicht leuchtet, hat nix dran (oder hat Fehler).

Eine Automatische Show zu schießen stelle ich aktuell mal ganz hinten an. Für eine simple Umsetzung hab ich schon eine Idee, aber die hat halt ihre Grenzen. In dem Fall würde man den Kanälen (oder virtuellen Kanälen) eine Laufzeit zuordnen und kann dann ganz billig Kanäle in eine Liste einfügen. Er wartet dann immer die Laufzeit eines Kanals ab und zündet danach den nächsten.
Das passt natürlich nur, wenn man auch wirklich nacheinander zünden will. Wenn man aber zwischendrin dazuzünden will, geht das so dann nicht mehr (oder man muss mit den Laufzeiten schummeln). Am Ende wird man sowieso für jedes Item nochmal Verzögerungen einstellen können müssen. Aber ob ich sowas überhaupt umsetze ist noch sehr fraglich (geht imho schon sehr in die Profirichtung).

Hardwaretasten kann man nutzen (guter Hinweis). VolumeUp und VolumeDown kann ich im Emulator schonmal abfangen. Allerdings spielt er trotzdem nen Sound ab. Muss ich mal am echten Device checken, ob das eine Eigenheit des Emulators ist.
Nutzen könnte man das dann, um zwischen Modulen zu wechseln. Eine Totmannschaltung kann man vielleicht auch umsetzen aber das ist dann imho echt overkill. Lieber die Tasten für was praktischeres nutzen.

Btw:
Die App kann aktuell schon die Module auflisten und man kann ein Modul aus der Liste auswählen und es steuern. Man kann zurück zur Auswahl und so auf das andere Modul wechseln. Jedes Modul ist komplett autark. Die Infrastruktur steht also, ich komme an alle nötigen Informationen ran und die Kommunikation klappt.
Der Code ist halt immer noch wüst wie Sau, weil alles in der selben Activity steckt. Ich muss dafür eigene Fragmente machen, die Grundlage dafür ist aber, dass das mit dem Swipen/Tabben geht.

 

Der Userbutton bzw. der Pin ist nicht richtig angeschlossen. Ohne zusätzliche Beschaltung funktioniert der nicht (zumindest lese ich mir das soweit so zusammen).

Bevor ich mir da einen abbreche, mache ich die Config lieber so, dass man sie über Serial reinspielt. Dann braucht man halt nen PC und Putty und muss USB anschließen.

Das mit dem Initialstate ist ne Idee. Auf die normale Statusanfrage meldet ein Modul erstmal nur, dass es da ist und wie es heißt. Die App sendet dann ein Startsignal und erst dann ist das Modul im normalen Modus und sendet die normalen Statusdaten.
Dann kann die App einen Neustart erkennen und reagieren.

Leider muss ich aktuell noch mit den Grundlagen von Android oder viel mehr mit der korrekten Einrichtung der IDE kämpfen. Ich bekomme einfach bestimmte Supportlibs nicht in kompilierter Form her, die brauche ich aber, wenn ich bestimmte Funktionen im UI nutzen will.

 

Durchbruch:
Ich habs endlich hinbekommen, dass ich Tabs mit Holodesign und ohne Verwendung von deprecated Funktionalitäten habe. Das beste daran ist, dass ich es im Eclipse hinbekommen habe und auf IntelliJ verzichten kann.

Screenshot, wie das aussieht ist angehängt.

Jetzt mache ich erstmal den Code wieder sauber und dann mache ich mir Gedanken darüber, wie die nächsten Features umgesetzt werden könnten.

 

Kurzes Update, warum hier schon ne Weile nix mehr kommt.

Ich hab aktuell nur wenig Zeit für die Coderei und wenn ich mal drankomme, dann muss ich mir wieder Basics reinziehen.

Die bestehenden Features waren relativ einfach, weil sie keinerlei Zustand der App erfordert haben. Jetzt wirds schwieriger, weil ich an den Virtuellen Kanälen und Automatisierung arbeite. Hier möchte man ja nicht immer alles neu machen, also muss das gespeichert werden. Außerdem kommen Benutzereingaben hinzu (also Daten), was vorher auch nicht der Fall war.
Das alles will erstmal ausprobiert und gelernt werden. Man findet meist schnell irgend einen Weg, wie es geht aber der ist nicht zwingend toll oder für den Nutzer gut.

Ich muss erstmal ermöglichen, dass man Module auch von Hand bekannt macht (Name und Kanalzahl). Man will ja nicht immer Module aktiv im Netz haben müssen, nur damit man Virtuelle Kanäle oder ein Programm bearbeiten kann. Das Ganze muss die App sich merken.
Als nächstes kommen dann die virtuellen Kanäle oder die Automatisierung. Wobei ich bei der Automatisierung aktuell auf dem Trichter bin, dass das semiautomatisch gehen soll. Man startet das "Programm" und der erste Kanal bzw. mehrere zugleich werden gezündet. Dann läuft ein Timer, der Bescheid gibt, wenn die nächste Batterie/Kombination laut Plan gezündet werden sollte. Erst wenn man dann eine Aktion ausführt, passiert die nächste Zündung auch. Dabei kann man die Zündung sowohl früher, als auch später ausführen. Im Optimalfall geht das ohne Touchscreen, einfach mit der Volume Taste.
Der Gedanke dahinter ist, dass die App nur die entsprechenden Informationen liefert, man aber weiterhin selbst Verantwortlich für die Zündung ist und auch den tatsächlichen Zeitpunkt selbst bestimmt. So sieht man z.B. dass in 5sec der nächste Effekt geplant ist, aber die aktuelle Batterie hat schon den Finalschlag abgeschossen. Dann zündet man einfach früher (sofern nicht eine Pause gewollt ist). Ebenso zündet man später, wenn eine Batterie unerwartet länger läuft.
Da man ja das Feuerwerk beobachtet und dann nicht noch Augen dafür hat, den richtigen Button auf dem Touchscreen zu suchen, der Ansatz mit der Volumetaste. Die kann man erfühlen und auch blind betätigen. Das Display dient dann im Wesentlichen nur noch zur Orientierung.

Da es eine App ist, kann man das am Ende natürlich beliebig ändern und auch vollautomatik oder sonst was hinzufügen bzw. aktivieren. Als ersten Schritt in Richtung einer Automatisierung finde ich die Semiautomatik aber ganz passend.

Wenn man bei der Semiautomatik den einzelnen Programmschritten Namen geben kann, dann können die virtuellen Kanäle vielleicht sogar erstmal gänzlich entfallen.

Also, ich arbeite dran und ich will auch mal wenn sich die Gelegenheit bietet ein kleines Video machen, damit ihr mal sehen könnt, wie das in der Praxis aussieht. Nur immer Text und ab und an ein Screenshot sagen einfach nicht sonderlich viel aus

 

Ich hab das mit dem Netzwerk verworfen. Das würde natürlich die Reichweite erhöhen, wenn der Master vorne steht und die Slaves hinten. Ansonsten seh ich da aber keine Vorteile, eher nur Nachteile.

Wenn mein Android den AP macht, dann habe ich dort schon die volle Kontrolle über das WLAN unabhängig von meiner Software.
Die verbundenen Clients kann man ermitteln (macht meine App bereits) und dann abfragen. Das kann sogar alles parallel in mehreren Threads laufen.

Da liegt imho der große Vorteil. Jedes aktuelle Handy hat mehrere Cores und kann somit parallel mit mehreren Kisten zugleich kommunizieren. Man bekommt das geschenkt, weil man URL Aufrufe sowieso immer in eigene Threads packen muss.
Egal wie viele Clients ich habe, der Ping bleibt gleich.

Mache ich Master/Slave, dann wird der Ping mit Anzahl der Kisten schlechter, weil der Master sich um alle Anfragen kümmern und sie delegieren muss. Ich packe die Last auf ein Gerät, das für heutige Verhältnisse sau langsam ist, anstatt das potente Gerät zu nutzen, das eh schon jeder in der Tasche hat.

Ich habe vor meine App so zu schreiben, dass man auch nach Clients suchen kann, wenn man nicht im AP Modus ist. Der Usecase tritt dann ein, wenn noch ein Router dazwischen ist (was bei mir zu Hause beim Entwickeln der Fall ist).

Mit diesem Feature fällt imho das einzige valide Argument für Master/Slave, nämlich die Reichweitenerhöhung, ebenfalls komplett flach. Ich kann dann nämlich einfach einen weiteren AP dazwischen hängen und sowohl Android, als auch die Module sind dann Clients. Den AP könnte wiederum ein weiteres Handy machen. Somit kann man die Reichweite dann fast verdoppeln und hat weiterhin den Vorteil, dass man jedes einzelne Modul direkt ansprechen kann.

Das ist dann auch Fehlertolleranter. Wenn bei Master/Slave der Master ausfällt, dann wars das. Wenn es keinen Master gibt, dann legt ein ausfallendes Modul nicht gleich das ganze System lahm.
Klar bleibt der Androide der single point of failure, aber das ist ja auch gewollt. Wenn die Steuereinheit weg ist, dann soll nix mehr laufen.

 

Du musst dann aber auch den Modulen eine doppelte Software verpassen. Die müssen ja dann Master und Slave können. Und irgendwie musst du umswitchen.
Mir was das zu umständlich, ich hab den großen Nutzen davon nicht gesehen. Es wäre für mich eher eine Notlösung gewesen, weil Android als AP bei mir anfangs ja nicht ging.

 

Ich sitz mal wieder dran, allerdings gibts Funktional nix neues. Ich arbeite gerade daran, technisch etwas zu verbessern.

Ich bringe den Modulen Broadcast bei, um somit einfach im Netz nach Modulen fragen zu können. Die sollen dann selbständig antworten und somit ist es nicht mehr nötig, dass man irgendwie die Geräte im AP des Android ausliest. Außerdem führt die Maßnahme dazu, dass die App auch dann funktioniert, wenn ein Router dazwischen hängt.

Ich hab auch mal den "bequemen" Weg probiert, einfach alle 255 Addressen anzufragen. Das ist allerding Müll, das dauert eeeeeeewig. Broadcast ist der einzig gangbare Weg an der Stelle.

Der bisher vorhandene Ad Hoc Modus wird entfallen. Man muss die Module IMMER konfigurieren. Die App sucht dann, nach den konfigurierten Modulen und zeigt an, ob sie online sind. Nur online Module können benutzt werden.
Ich plane aber andere Module, die nicht konfiguriert sind auch anzuzeigen, so dass man sie direkt in die Konfiguration übernehmen kann.

 

Der Broadcast kommt an den Modulen an, jedoch schaffe ich es nicht, eine Antwort zurück zu bringen. Hängt wohl irgendwie mit dem Emulator zusammen.

Ich lasse das erstmal weg, es funktioniert also vorerst nur, wenn sich die Module direkt am Android als AP anmelden.

Vielleicht versuche ich mich später nochmal dran, prinzipiell funktionieren tut es ja und ich wette auf einem echten Gerät geh es auch (ist ein Emulator Problem, weil der kein eigenes echtes Netzwerk hat).

 

Nicht aufgeben heißt die Devise.

Mein Smartphone schickt einen Broadcast und bekommt vom Modul eine Antwort.
Jetzt muss ich noch dafür sorgen, dass die Rückmeldung auch sinnvoll verwurstet wird (aktuell wird nur eine Meldung ausgegeben).

Ich spiele jetzt mit dem Gedanken, dass ich die Statusabfrage auch damit noch umbaue. Nicht der Androide fragt zyklisch an, sondern die Module geben von selbst zyklisch Bescheid.
Hätte dann aber den Nachteil, dass:
1. keine offene Webapi mehr existiert (Adaptierung an andere Clients schwieriger)
2. kein Ping mehr gemessen werden kann (weniger dramatisch)
3. Module ewig weitersenden, auch wenn kein Androide mehr da ist (außer man prüft hier noch ab)


Dass die Rückkommunikation vom Modul an Android im Emulator nicht klappt hat 2 Gründe.
1. muss man den entsprechenden TCP Port in den Emulator weiterleiten (hier gibt es eine Möglichkeit per Telnet in die Console des Emulators zu kommen und das dort zu setzen).
Ab dann kann man vom localhost schon den Android erreichen.
2. man muss Anfragen von Außen auf diesen Port auf die interne IP des Emulators forwarden. Sonst kommt man von Außen nicht drauf.
Dafür hab ich aktuell noch keine Lösung. Da muss ein kleines Tool her, das das übernimmt. Vorerst wollte ich den Proof of Concept.

Damit ich jetzt gescheit weiterarbeiten kann, muss ich das im Emulator zum laufen bringen. Falls das nicht geht, muss ich den Teil der Kommunikation fürs Emulieren immer durch einen Fake ersetzen und das mag ich überhaupt nicht (Fehleranfällig).

Ich gehe davon aus, dass ich die Kommunikation bis zum Wochenende wieder sauber hab. Dann kanns wieder an weitere Features gehen.

 

Ich entwickle mittlerweile auf dem echten Device. Hätte ich vorher gewusst, wie einfach das ist, dann hätte ich das von Anfang an so gemacht.
Der Emulator ist somit nicht mehr relevant.

Der Android fragt jetzt zyklisch per Broadcast nach den Modulen (die IP ist aktuell noch fix, aber das ist ne Kleinigkeit). Die Module melden sich und es wird automatisch angezeigt, welche Module online sind.

Was hier noch fehlt, ist die Validierung der Kanalzahl. Wenn man die falsch eingegeben hat, dann muss das auch angezeigt werden. Ebenso muss ich die Anzeige allgemein verbessern.
Zudem will ich auch Module anzeigen, die noch nicht in der Konfiguration sind.

Modulseitig hat sich ebenfalls noch mal was getan. Die Module bieten jetzt fürs Setup ein eigenes Webinterface. Man muss nur die IP wissen, den Rest macht der Browser.
Das ist deutlich angenehmer, als wenn man eine spezielle "get" Url wissen muss.

 

Gibt wieder eine Neuerung:
Die Übersicht zeigt direkt alle konfigurierten Module an und ob sie online sind. Kanalzahl wird noch nicht berücksichtigt.
Module, die nicht konfiguriert sind, sich aber zurückmelden, werden jetzt ebenfalls angezeigt.

Der Plan ist, dass diese AdHoc verfügbar sind und auch bequem zum konfigurierten Modul gemacht werden können.

Unterscheidung zwischen "konfiguriertem Modul" und "adHoc Modul":
- Konfiguriertes Modul ist in der App gespeichert und kann für die Planung benutzt werden. So kann man "offline" ein Feuerwerk planen, Kanäle benennen etc.
- AdHoc Modul ist nicht gespeichert und kann nur für die direkte Ansteuerung verwendet werden.

Bisher kann man Module selbst mit Namen und Kanalzahl eingeben. Hier überlege ich, ob ich das nicht wieder rausschmeisse und die Modulkonfiguration nur automatisch angelegt werden kann (über gefundene AdHoc Module). Damit spare ich mir die ganzen Eingabemasken, die eh keiner will.
Nachteil: Das Modul muss halt existieren und mindestens 1x online sein, bevor man was planen kann.
Ebenso ist dann ein umbenennen eines Moduls nicht ohne weiteres möglich. Ich denke aber, dass das kein größeres Problem darstellt.

Was ich noch überlege ist, ob ich auch in der App noch eine Oberfläche zur Modulkonfiguration anlege. So dass sich Module, die sich im Konfigurationsmodus befinden ebenfalls zurückmelden und ein Flag setzen. Die App erkennt das und zeigt das Modul besonders gekennzeichnet an. Dann kann man es anklicken und bekommt einen Dialog, mit dem man dann SSID, Passwort und Name setzen kann.
Das macht die Inbetriebnahme dann einfacher (sonst muss man die IP des Moduls kennen).
Das ist aber ein Addon, das erst später relevant würde.

Mit etwas Glück hab ich am Wochenende mal einen vorzeigbaren Stand und mache ein kleines Video.

 

Da lesen noch viel mehr mit und das freut mich =)

Ich denke aber, dass so abstrakte Infos irgendwann langweilig werden. Daher will ich ja mal was zeigen. Nur Fotos sind da allerdings doof, es geht ja darum, wie sich das ganze Bedienen lässt.
Bei Video ist halt wieder das Problem mit der Dateigröße. Aber wenn da nicht grad 1000 User ständig downloaden, sollte auch das machbar sein.

Mich ärgert ein wenig, dass ich mit den Features nicht so vorankomme, wie ich das gerne hätte. Aber man hat ja nicht unendlich Freizeit und man stolpert halt auch immer wieder über Stellen, die man aufräumen oder verbessern sollte und macht das dann auch direkt.

Ich weiß auch noch nicht so recht, wie ich so ein geplantes Feuerwerk überhaupt darstellen will. Wahrscheinlich erstmal mit einer simplen Liste, die dann Modul, Kanal und geplante Verzögerung anzeigt.
Aber auch hier fehlt mir wieder die Praxiserfahrung. Plant man die Zeiten eher als Deltas zum vorherigen Zündzeitpunkt oder als absolute Zeitpunkte gegenüber dem Programmstart.
Also
0s -> Kanal 1
10s -> Kanal 2
30s -> Kanal 3
20s -> Kanal 4
vs.
0s -> Kanal 1
10s -> Kanal 2
40s -> Kanal 3
60s -> Kanal 4

Wahrscheinlich wird man am Ende beides irgendwie haben wollen.