[FHEM-Tablet-UI] Widgets for fhem-tablet-ui

Begonnen von nesges, 10 April 2015, 10:30:25

Vorheriges Thema - Nächstes Thema

update71

#90
ZitatFür das clicksound-Problem hat es gereicht noch "index.html" an die HTTPSRV-Definition anzuhängen (siehe 3 Posts weiter oben).
der / im define hatte auch gelangt :) ... Man konnte nur nicht per Klick aus FHEMWEB auf die Tablet UI (kam ne leere weisse Seite)
Thomas
###########
Raspi mit Fhem, nanoCUL 433 + mehrere Brennstuhl Steckdosen - HM-LAN + Thermostat, 6 fach Taster, Aussensensor - HUEBridge + 3 weiße LEDs ... mehr folgt

bjoernbo

Habe mir nun mal die Konsolenausgabe angeschaut:
ZitatDer an decodeAudioData übergebene Puffer enthält einen ungültigen Inhaltstyp. kueche.html
GET
http://192.168.178.51:8083/fhem/tablet/lib/ion.sound/sounds/button_tiny.ogg [HTTP/1.1 200 OK 14ms]
Der an decodeAudioData übergebene Puffer enthält einen ungültigen Inhaltstyp. kueche.html
GET
http://192.168.178.51:8083/fhem/tablet/lib/ion.sound/sounds/button_tiny.mp4 [HTTP/1.1 200 OK 195ms]
Der an decodeAudioData übergebene Puffer enthält einen ungültigen Inhaltstyp. kueche.html
GET
http://192.168.178.51:8083/fhem/tablet/lib/ion.sound/sounds/button_tiny.aac [HTTP/1.1 200 OK 14ms]
Der an decodeAudioData übergebene Puffer enthält einen ungültigen Inhaltstyp. kueche.html
GET
http://192.168.178.51:8083/fhem/tablet/lib/ion.sound/sounds/button_tiny.wav [HTTP/1.1 200 OK 13ms]
Der an decodeAudioData übergebene Puffer enthält einen ungültigen Inhaltstyp. kueche.html
GET
http://192.168.178.51:8083/fhem/ [HTTP/1.1 200 OK]
EncodingError: The given encoding is not supported.

Kannst Du damit was anfangen?
Raspberry Pi 3 - FB6490C - Synology NAS DS916+ - NETATMO - HUE - SIEMENS G-Tag'S - FTUI - EchoDOT -

nesges

Zitat von: bjoernbo am 16 Mai 2015, 08:05:31
Habe mir nun mal die Konsolenausgabe angeschaut:
Kannst Du damit was anfangen?

Gib mir dazu bitte etwas Kontext:

1.) HTTPSRV Definition
2.) clicksound-HTML
3.) weitere Meldungen in der Konsole?

nesges

#93
testing: itunes_artwork

Für die Mutigen (aka: das Widget ist noch so gut wie ungetestet) gibt es jetzt im testing-Verzeichnis das neue Widget itunes_artwork. Es benötigt eine frisch aktualisierte Installation (sowohl FTUI als auch Widgets auf neuestem Stand).

Das Widget nimmt ein Array von Readings im data-get Attribut als Suchstring für die iTunes-API und zeigt das erste gefundene Album-Cover an. Der erste Screenshot wurde mit diesem HTML erzeugt:

       <div data-type="itunes_artwork"
                data-device="MPD_WOPR"
                data-get='["now_artist","now_album","now_title"]'></div>
       
        <div data-type="mpdnowplaying"
                data-device="MPD_WOPR"
                data-get='["now_artist","now_album","now_title"]'></div>


Für den zweiten habe ich das Widget als Hintergrund für die MPD-Steuerung gesetzt. Folgender HTML-Code:

<div data-type="itunes_artwork"
            data-device="MPD_WOPR"
            data-get='["now_artist","now_album","now_title"]'
            data-opacity="0.2"
            data-size=400
            style="position:absolute;top:20px;left:-10px;"></div>


Es werden alle Attribute des image-Widgets unterstützt, mit der Einschränkung, dass height, width und size nicht unterschiedlich sein können (-> nur size setzen reicht). Zusätzlich gibt es die Attribute media (default: music) und entity (default: song), die unter https://www.apple.com/itunes/affiliates/resources/documentation/itunes-store-web-service-search-api.html näher erläutert werden.

nesges

Hier übrigens noch eine mMn bessere Lösung für das clicksound-Problem:

Zitat von: nesges am 15 Mai 2015, 16:54:11
Ich denke das ist die Erklärung für die verschiedenen Probleme mit relativen Pfaden, die ich bisher HTTPSRV zugeschrieben habe. Zuletzt mit dem clicksound-Widget, das wahrscheinlich bei niemandem mit einer Standardinstallation läuft (zumindest habe ich noch keine positive Rückmeldung). Wenn ich das HTTPSRV Define auf

define TABLETUI HTTPSRV ftui ./www/tablet Tablet-UI

ändere, treten die bisher bekannten Probleme nicht auf. Ich denke wir sollten das statt der bisherigen Definition in den Standard aufnehmen. https://github.com/knowthelist/fhem-tablet-ui/pull/90 wäre damit auch obsolet.

tomster

Zitat
       <div data-type="itunes_artwork"
                data-device="MPD_WOPR"
                data-get='["now_artist","now_album","now_title"]'></div>
Cover Art funktioniert bei mir nicht. Es erscheint nur "img". Braucht das Widget noch irgendetwas zusätzliches?
Zitat
        <div data-type="mpdnowplaying"
                data-device="MPD_WOPR"
                data-get='["now_artist","now_album","now_title"]'></div>
Das zeigt mir alles brav an.


nesges

Das Widget ist eigenständig, es braucht nur ein aktuelles widget_image.js (im Standard enthalten). Ich werde heute abend ein paar Debug-Ausgaben einbauen, dann kann man sinnvoll nach Fehlern suchen. Es gibt natürlich auch den eher unwahrscheinlichen Fall, dass iTunes den gespielten Titel nicht kennt - was zeigt mpdnowplaying denn an? Bzw. wie lauten die Einzelwerte für now_artist, now_album und now_title?

tomster

#97
Ich habe Deine now-Subs wieder entfernt, weil's mir zuviele Fehlermeldungen rausgehauen hat. Drum hab ich logischerweise im Widget nur '["artist","album","title"]' angegeben.
Hier der Output von 2 Webradios:

Bei Radio Gong 96,3 wird <artist> mit dem Titel gefüllt und <title> mit dem Interpreten. <album> wird bei mir anscheinend mit dem Inhalt von <name> befüllt.
Bei Antenne Bayern wird <artist>, <title> korrekt gefüllt, <artist> enthält wieder die <name>-Ausgabe

--edit--
Bei "zusätliches" dachte ich eigentlich eher an irgendwelche Pakete...

nesges

Zitat von: tomster am 19 Mai 2015, 13:13:43
Bei Radio Gong 96,3 wird <artist> mit dem Titel gefüllt und <title> mit dem Interpreten. <album> wird bei mir anscheinend mit dem Inhalt von <name> befüllt.
Bei Antenne Bayern wird <artist>, <title> korrekt gefüllt, <artist> enthält wieder die <name>-Ausgabe

Konkrete Werte bitte :) Es geht darum zu checken, ob a) dein Radio sinnvolle Werte liefert und b) diese in iTunes zu finden sind. Wenn artist "Antenne Bayern" liefert bzw album "Radio Gong 96,3" enthält findet iTunes wahrscheinlich nichts. Für Webradios kann es evtl. sinnvoll sein eine Option für Einzelabfragen der Werte an iTunes einzubauen. Die Wahrscheinlichkeit von false positives wird dadurch nur eben drastisch höher.

tomster

#99
Konkret? Bitte!

<artist> Robin Schulz
<title>  Sun Goes Down
<name> ANTENNE BAYERN

<artist>Use Somebody
<title> KINGS OF LEON
<name> Gong 96,3 powered by www.nci.de

und testweise auch noch Rock Antenne hinterhergeschoben:

<artist>Noel Gallagher's High Flying Birds
<title>Riverman (Radio Edit)
<name>ROCK ANTENNE

nesges

Danke. Hier mal das, was das Widget aufgrund der Daten an iTunes schickt (ein Klick auf den Link zeigt iTunes Antwort im Detail):

https://itunes.apple.com/search?media=music&entity=song&term=Robin Schulz Sun Goes Down ANTENNE BAYERN

iTunes sagt: kenn ich nicht

https://itunes.apple.com/search?media=music&entity=song&term=Noel Gallagher's High Flying Birds Riverman (Radio Edit)

iTunes sagt: kenn ich nicht. Nimmt man "(Radio Edit)" raus, findet iTunes das richtige Ergebnis

https://itunes.apple.com/search?media=music&entity=song&term=Use Somebody KINGS OF LEON

Das Feld "name" wird nicht mit rein genommen, daher sind die Daten "sauber" und die Abfrage liefert ein Ergebnis aus dem das Widget das richtige Artwork extrahieren kann. http://is3.mzstatic.com/image/pf/us/r30/Features/48/c1/1b/dj.eunilvua.100x100-75.jpg sollte angezeigt werden.

tomster

#101
Hmm, warum übergibst Du denn den kompletten String und "zerhackst" ihn nicht und setzt ihn mit "+" wieder zusammen?

Ein
https://itunes.apple.com/search?media=music&entity=song&term=Robin+Schulz+Sun+Goes+Down

liefert nämlich sehr wohl ein Resultat...

--edit--
OK,
https://itunes.apple.com/search?media=music&entity=song&term=Robin%20Schulz%20Sun%20Goes%20Down
tät's auch...

tomster

#102
Ha! Mit

data-get='["artist","title"]'

habe ich nun mein erstes Cover angezeigt bekommen!
Gut, "Nirvana - Smells like teen spirit " dürfte auch iTunes kennen ;-)

Dass iTunes aber "Alles Neu PETER FOX" nicht kennt wundert mich dann aber doch arg...

Kannst Du noch ein Default-Bild einbauen, das angezeigt wird, wenn kein Resultat von iTunes zurückgeliefert wird? Würd's optisch ein bissl "runder" und nicht gar so nackig machen...

nesges

Update itunes_artwork:

  • Es versucht jetzt bei Misserfolg (-> iTunes findet nichts) den Suchstring sukzessive um ein Feld zu verkürzen.
  • Es gibt ein Default-Ladebild (das später noch ausgetauscht wird, und über das neue Attribut data-loadingimg ersetzt werden kann)
  • Ich habe eine Menge Debug-Meldungen für die JS-Konsole eingebaut. Diese Ausgaben bitte an Fehlermeldungen anfügen.

iTunes liefert bei mir zurzeit oft keine Anwort auf Anfragen. Ich habe es allerdings auch versehentlich heute morgen mit Anfragen geflutet. Evlt. ist das also nur ein Schutzmechanismus, der mir ggü. grade misstrauisch ist. Werde ich weiter evaluieren. Solltet ihr ähnliches bemerken, bitte ich um Hinweise.

tomster

Find nur ich die geänderte Datei nicht oder hast Du sie noch gar nicht hochgeladen?