MoSteuS - Brainstorming

    Ich hab mal eben schnell einen App-Entwurf gebastelt (war eh grad noch für ein anderes Projekt dabei):


    [Blockierte Grafik: http://images.bluemoehre.de/thumb/9728a824bf9023e14c887481238ac520.jpg]


    Auf nem Tablet hat man natürlich deutlich mehr Platz für Channel-Assignments, daher muss man hier leider horizontal scrollen.


    Edit:
    Brauchen wir eigentlich einen Black-Out/Standby/Power-Off Button???

    Ich erlaube mir mal zu zitieren, was du wieder wegeditiert hast:

    Zitat

    Das hat schon Hand und Fuß was ich da baue... mach das schon ein paar Jahre

    Man man, Pinselschwinger und ihre Kritikfähigkeit...


    Dann mal zu den Fakten. Ausgehend vom Screenshot sind die Tab-Reiter 94px hoch, die unteren Buttons nur 76px. Ich unterstelle dir mal, dass die unteren Buttons problemlos touch-bar sind - du machst das ja schon ein paar Jahre - also sind hier schonmal 18px bei den Tab-Reiten einzusparen, ohne dass sie nichtmehr touch-bar werden würden. Fehlen noch 58px für die volle Höhe der unteren Buttons. Über und unter dem Colorwheel sind insg. knapp 60px Platz (drunter 29px, drüber etwas mehr).


    q.e.d.


    Klar siehts dann gedrückt aus, aber den ein oder anderen Pixel kann man das Wheel auch noch vergkleinern.. also wenn man wirklich möchte, bekommt man eine dritte Reihe hin.

    ähm, ich finds schön wie es ist... ich hab zwar auch keine dicken Finger, aber als Lichtschalter im Raum hab ich ja auch nicht nur einen kleinen 12 mm Taster... :D


    Auf den Luxus von großzügigen Tasten würde ich nicht verzichten wollen...


    Aber das ja alles Geschmackssache... also keinen Streit...


    MfG


    Basti


    P.S. Vorgestern habe ich auch was Hausbusähnliches angefangen. Hab nen 32 Bit µC Board von der embedded world rausgekramt (mit ethernet schnittstelle) und mal nen kleinen Webserver für meine Zwecke drauf angepasst. Aber Licht schalten möchte ich nicht, ich werde die Tage elektronische Thermostate bestellen...

    Zitat

    Man man, Pinselschwinger und ihre Kritikfähigkeit...


    =) ... Habs nachm Posten gelesen und dachte mir genau das gleiche. Hab es auch direkt ne Minute später wegeditiert und trotzdem hast du es noch gesehen. Betrachte den Kommentar bitte als zurückgenommen.

    Zitat

    Dann mal zu den Fakten. Ausgehend vom Screenshot sind die Tab-Reiter 94px hoch, die unteren Buttons nur 76px. Ich unterstelle dir mal, dass die unteren Buttons problemlos touch-bar sind - du machst das ja schon ein paar Jahre - also sind hier schonmal 18px bei den Tab-Reiten einzusparen, ohne dass sie nichtmehr touch-bar werden würden. Fehlen noch 58px für die volle Höhe der unteren Buttons. Über und unter dem Colorwheel sind insg. knapp 60px Platz (drunter 29px, drüber etwas mehr).


    Das ist kein Pixeldesign... Das Design ist in Millimeter und vectorbasiert. Ich war nur beim Rausrechnen recht großzügig mit der Auflösung. Die Umsetzung wäre übrigens auch millimeterbasiert, damit gewährleistet ist, dass auf allen Geräten die Elemente gleich groß sind - unabhängig von Auflösung und DPI.

    Zitat von Möhre

    Die Umsetzung wäre übrigens auch millimeterbasiert, damit gewährleistet ist, dass auf allen Geräten die Elemente gleich groß sind - unabhängig von Auflösung und DPI.

    Das klingt interessant. Ich hab bisher noch nicht für Android entwickelt, obwohl ich schon ewig das SDK installiert habe - aber die Zeit...
    Ist das Standard bei Android-Apps, also dass das Layout nicht Pixelbasiert ist? Hab mich nämlich schon gefragt, wie man sinnvolle Oberflächen realisieren kann, wenn jedes 3. Gerät eine andere Auflösung hat.


    //EDIT: Und sorry für OT...

    Zitat

    Ist das Standard bei Android-Apps


    Wäre gut, wenn es das wäre ;) Aber hat jetzt mit der App selbst nicht zwingend was zu tun, weil das Interface eine Webview ist. Kurzum: jeder Browser wird dir die Website darstellen. EDIT: ok, nicht der IE! =P

    Als Kommunikationsprotokoll würde ich HTTP / Websockets empfehlen. Das funktioniert in jedem aktuellem Browser und die Implementierung recht einfach.
    Das Datenformat der API sollte dann auch gleich JSON sein. Das ist kompakt, lesbar und einfach zu handhaben.


    Ich gebe mal folgende Beispiele für Kommandos an den Controller:
    --------------------------------------------------------------------------------
    - Kanal 1 auf 100% rot (RGB bei 8bit):

    Code
    {'ch':0,'r':255,'g':0,'b':0}


    - Kanal 2 auf 100% blau & Kanal 3 auf 100% grün (RGBW bei 16bit):

    Code
    [{'ch':2,'r':0,'g':0,'b':65536,'w':0},{'ch':3,'r':0,'g':65536,'b':0,'w':0}]


    - Eine Szene sichern:

    Code
    {'preset':8,'action':'save','channels':2,data:[{'ch':0,'r':255,'g':0,'b':0},{'ch':1,'r':255,'g':0,'b':0}]}


    - Eine Sequenz sichern:

    Code
    {'sequence':14,'action':'save','channels':1,data:[{'ch':0,'r':255,'g':0,'b':0,'dur':1000},{'ch':0,'r':250,'g':0,'b':0,'dur':5000,'fade':1000}]}

    (wobei die Fade-Zeit nur <= der Dauer sein kann)
    - Eine Single-Channel Sequenz laden und einem Kanal zuweisen:

    Code
    {'sequence':14,'action':'load','assignment':[{'ch':0,'target':0}]}


    Die Status-Events an die App könnten so aussehen:
    ---------------------------------------------------------------
    - Kanal 1 ist 100% rot:

    Code
    {'ch':0,'r':255,'g':0,'b':0}


    - Sequenz 14 ist Kanal 1 zugewiesen:

    Code
    {'sequence':14,'assignment':[{'ch':0,'target':0}]}


    - Sequenz 3 ist beended:

    Code
    {'sequence':14,'state':'end'}


    - Sequenz 1 läuft und ist bei Position 12 Sekunden:

    Code
    {'sequence':1,'state':'running','position':12000}


    Wie ihr seht, ist der Datenaustausch asynchron - d.h. es gibt keine Bestätigung zu einem Kommando, sondern nur ein ausgelöstes Event. Dies bietet den Vorteil, dass mehrere Controller gleichzeitig genutzt werden können.
    Die Bezeichner können natürlich noch weiter verkürzt werden - ich habe sie an einigen Stellen nur der Einfachheit ausgeschrieben.

    Hi Leute,


    ja, ich lebe noch. Und das Projekt ist auch keinesfalls tot.
    Ich selbst hing gesundheitlich jedoch allerhand Wochen lang ziemlich in den Seilen und bin noch immer nicht völlig fit.


    Jedenfalls habe ich gerade einen kleinen Auftrag, der durchaus in Richtung MoSteuS geht; zumindest insofern, dass da 'ne Hand voll Platinchen (14 Stück), mit je einem AVR bestückt, über RS-485 und 'ne lange Flachleitung miteinander kommunizieren.
    Die Platinen steuern jeweils 2 Power-LEDs an und fragen zwei Taster ab.


    Ein echt überschaubares Kleinprojekt also, das mir aber die Möglichkeit bietet, mal diverse Dinge real zu testen, die für MoSteuS wichtig sein werden - ohne gleich dieses heftige Monsterding in allen Details realisieren zu müssen (mit dem ich ja wohl sowas von überfällig bin!).
    Dazu gestalte ich diese 14 Platinchen gleich ein Stück universeller, als für das Projekt erforderlich und lasse ein paar davon auf Reserve fertigen.


    Minimal geforderte Eigenschaften der Platinen:
    2 Zweipolige, steckbare Klemmen, zum Anschluss der beiden Power-LEDs.
    2 Zweipolige, steckbare Klemmen, zum Anschluss externer Taster.
    1 12poliger Micromatch für den Anschluss an das Flachkabel.
    5 kleine Kontroll-LEDs on Board: Power good, Ausgang 1 aktiv, Ausgang 2 aktiv, Taster 1 betätigt, Taster 2 betätigt.
    2 kleine Taster direkt auf der Platine: Reset und "Universalfunktion". Elektrisch nicht verbunden mit den externen Tastern.
    1 sechspoliger ISP-Port.


    Natürlich sehe ich statt zwei Lasttreibern gleich drei vor, so dass man auch eine RGB-LED betreiben kann.


    Der LED-Strom wird übrigens mit über die Flachleitung geführt (je drei Adern für +12V und drei Adern für GND), weil bei diesem Projekt gewährleistet ist, dass immer nur eine LED zur Zeit aktiv ist, der Strombedarf also entsprechend gering.
    Dennoch werde ich vermutlich noch zwei Anschlüsse für 'ne Power-Einspeisung zumindest im Layout vorsehen, auch wenn hier nicht benötigt. Die Platinen sollen allerdings eher klein bleiben, ich werde also auch nicht übertreiben, mit dem Vorsehen von für dieses Projekt unnötigen Erweiterungen.


    Aber dass die freien AVR-Ports auf Lötpunkte geführt werden und so, ist natürlich klaro, damit man die Dinger universell einsetzen kann.
    5V-Stabi, der aus den 12V 'ne stabile Spannung für den AVR macht, wird auf jeder Platine vorhanden sein.
    Die Abmessung wird ungefähr bei Streiholzschachtel-Format liegen, schätze ich mal.
    An ICs stecken da nur der AVR (ein ATMega644PA) drauf und ein SP491ECN (RS-486 Transceiver).
    Weil der gewählte AVR zwei UARTs hat (die ich hier eigentlich nicht brauche) hat man noch leicht die Möglichkeit, anderen Kommunikationskram zu realisieren. Also z.B. ein beliebiges RS-232-Gerät aus größerer Distanz, per RS-485 (Vierdrahtbus) anzusprechen und so.


    Falls jemand Bedarf an solchen Platinen hat oder schnell noch Ideen einbringen will, bitte laut "Bescheid" sagen ...
    Layout, Schaltplan und Weichware werde ich natürlich offenlegen. Aber ich will wie erwähnt 'ne kleine Serie davon anfertigen lassen, so richtig schön industriell bestückt und so. Wer also mal ein kleines LED-Projekt testen will, mit RS-485, der hätte hier die Möglichkeit, von mir die fertigen Platinen zu bekommen, so quasi zum Selbstkostenpreis. Und: NOCH habe ich die Möglichkeit, kluge, kleine Ideen von Euch einfließen zu lassen, sofern diese nicht den Rahmen spengen!


    Wer die Hardwarebeschreibung aufmerksam gelesen hat, der müsste gemerkt haben, dass die ziemlich identisch ist, mit den geplanten Adressdecodern für MoSteuS (ein Jammer, dass die noch nicht fertig sind!). Nur halt um 'nen schon integrierten Lastteil erweitert und ein paar Detailabweichungen. Jedenfalls gut geeignet, für Experimente in dieser Richtung, bzw etwas verteiltem Schalten & Walten im Haus, bei 12V.