Hi,
Ton ist schlecht ... Könnt Ihr das bestätigen ? Ich will nur normal in der Küche Radio hören,
keine Konzerte oder so.
Das lässt sich nur subjektiv beantworten. Ich habe das Archos Arnova, das müsste dann wohl ein MP350 sein. Zuerst hatte ich es im Garten, später hat meine Tochter mir die Eigentumsrechte entzogen und nutzt es als Wecker und als Youtube, Twitter und whatever :) Device.
Persönlich habe ich, was den Klang angeht, keine Bedenken wenn es um ein Küchen-, Bad- oder Schlafzimmerradio geht. Soweit ich weiß hat Rince, der ja auch involviert ist, sein Radio erhalten. Vielleicht steuert er seinen Eindruck auch mit ein.
Da sich der Kreis der Interessierten ja scheinbar vergrößert kann ich ja mal einen kurzen Abriss geben wo wir stehen:
Penbex (so heißt der Firmwareentwickler) hat aktuell minimalen LAN Support in seine Firmware eingebaut, dabei hatte er erst mal nur eine Smartphone App im Sinn welche die FB ersetzen sollte.
Rince hat dann Kontakt zu ihm aufgenommen und hat um Unterstützung für eine FHEM Integration geworben. Penbex hat da grundsätzlich auch Interesse gezeigt und ist dabei zusätzliche Funktionen (zum Beispiel Picture Overlay) einzubauen.
Grundsätzlich muss man aber auch sagen das wir im Augenblick (Rince, ich hoffe Du teilst das ;-) gar kein Konzept haben wie eine Integration in FHEM am Ende aussehen könnte.
Bestenfalls kann ich hier mal meine 10cent skizzieren:
Ich sehe ich nur begingt einen Mehrwert über FHEM play, pause, volume etc zu triggern. Wenn ich in der Küche bin drück ich auf den Knopf und gut ist.
Worin für mich der wirkliche Reiz bestünde wäre die Nutzung des Displays und Audio. So in der Art eines unauffälligen Universal-FHEM-Bedienpanels. Also sagen wir das Radio steht in der Küche und macht das was ein Radio so macht: Musik spielen. Aber gleichzeitig bietet es die Möglichkeit die Raumtemperatur einzustellen. Wenn das Telefon klingelt wird der Anrufer signalisiert, vielleicht mit Bild. Wenn es an der Haustür klingelt wird das Bild der Türkamera als Overlay engeblendet. Im Schlafzimmer kann ich möglicherweise die Alarmanlage aktivieren. Die Weckzeit wird mit FHEM synchronisiert und kann so das Wakeuplight steuern.
Die Schwierigkeit die sich daraus ergibt ist jetzt die: das Display ist zu klein um da irgendeine Art von "one fits it all" Menu abzubilden (zumindest sehe ich keinen Weg, vielleicht hat ja jemand eine zündende Idee). Vielmehr glaube ich das die Menus, je nach Installation und Raum, individuell, möglichst minimalistisch und (WAF kompatibel:-) grafisch sexy gestaltet sein sollten.
Der erste Gedanke dazu war innerhalb von FHEM ein Bitmap rendern zu lassen (die GUI für das Radio), dieses Bitmap per Lan ans Radio zu senden, dort ab aufs Display und im Gegenzug reicht das Radio alle Buttons (RC und lokal) an FHEM zurück. Damit wäre eine komplette Navigation möglich. Ergänzt um einige kleine Hardwarefunktion (play, displaybrightness, clock) und wir hätten ein rundes Paket.
Soweit ich Penbex verstanden habe wäre das jetzt auch für ihn mit vertretbarem Aufwand zu integrieren, allerdings hat er dann schlussendlich einen Rückzieher gemacht. Persönliches Gefühl von mir: er möchte das nicht weil es auf diese Art möglich wäre das Radio mit einer Oberfläche von FHEM zu betreiben, quasi komplett an der von ihm mit viel Mühe (muss man wirklich anerkennen!!!) entwickelten Oberfläche vorbei. Er hat recht offen gesagt das er die Kontrolle über das Device nicht abgeben möchte.
Penbex bevorzugt es aktuell eine "Homecontrol" - App für das Radio zu schreiben und möchte per XML oder JSON mit FHEM sprechen und die APP natürlich re-usable halten - nach Möglichkeit also auch für andere Homeautomatisierungen (es gibt neben FHEM noch weitere ??? ;-) öffnen möchte. Von seinem Standpunkt aus finde ich das auch durchaus valide.
Der Punkt an dem wir jetzt stehen ist also die Frage offen wie die Kommunikation FHHEM ./. Radio gestaltet werden kann und am Ende geht natürlich auch darum wie die grafische Darstellung erfolgen soll. (Liste, Menu mit Layout etc)
An diesem Punkt herrscht jetzt auch Funkstille, aber im Prinzip wären wir jetzt auch dran passende Vorschläge zu liefern.
Wenn Penbex jetzt darauf besteht das Rendern entsprechender GUI Elemente auf dem Device zu machen entsteht für mich die zwingende Notwendigkeit einen passenden Abstraktionslayer einzuführen. Weil sich daraus durchaus Synergien für andere Projekte ergeben können würde ich gerne die Chance Nutzen eine offene Diskussion für alle die Interessierten zu starten.
Zum jetzigen Zeitpunkt hätte ich dazu den Vorschlag ein SET von GUI Elementen zu definieren. Möglichst simpel, die üblichen Verdächtigen: Button, Auswahlfeld, Dialog, Panel plus noch einige :). Wenn wir jetzt in der OOP wären würde ich sagen abgeleitet von Dummy ergänzt um einige Attribute wie Position, Size vielleicht einige Styles. Soweit ich das in der dummy.pm sehe sollte der Aufwand dafür auch überschaubar sein.
Als Beispiel ein Button:
define LichtAnButton GuiButton
attr LichtAnButton position 50,50
Darüber würde dann das eigentliche Device liegen. Im Falle der Umstzung so wie von Penbex vorgeschlagen wäre die Aufgabe dieser Instanz alle zugehörigen Elemente "einzusammeln" und die XML oder JSON Kommunikation an das Radio zu übernehmen. Sollte FHEM das rendern übernehmen müsste die Instanz ebenfalls alle Elemte sammeln, diemsal aber eben die Position selber auswerten und in ein passendes Bitmap rendern.
define Kuechenradio iRadio
attr MenuA LichtAnButton
Dieses System würde es meiner Meinung nach dann auch zulassen Oberflächen universell zu erstellen und zu handhaben, zum Beispiel anstelle des WLAN Radios ein Tablett mit Sencha Touch (würde die config dann per json beziehen können und die passenden GUI Elemente dynamisch generieren) oder möglicherweise fühlt sich auch jemand berufen einen Renderer für Airplay oder andere Smart TVs zu schreiben.
Recht langer Post, sorry dafür. Alles Feedback und natürlcih helfende Hände hochwillkommen :)
Grüße
Jörg
