Um die in verschiedenen Threads angefangene Diskussion zur Steuerung von Webradios mit ListenLive Firmware zusammenzuführen, habe ich diesen Thread eröffnet.
Grundlagen zum Thema sind die Beiträge aus diesen Threads:
Radiowecker via FHEM steuern (http://forum.fhem.de/index.php?topic=12571.0)
Neues Modul schreiben für ein Radio (http://forum.fhem.de/index.php?topic=13752.0)
Class Programmierung und FHEM (http://forum.fhem.de/index.php?topic=13647.0)
Ich würde mich freuen, wenn die gesamte Diskussion zu dem Thema nun gesammelt hier in diesem Thread erfolgen würde, damit man den Suchaufwand reduzieren kann (was stand denn nun in welchem Thread)
Ausdrücklich möchte ich darauf hinweisen, dass hier nicht nur der Lösungsansatz "Modul für ListenLive Geräte", sondern auch die von herrmannj entwickelte Idee, eigene Software auf dem Gerät zu installieren, um eine bidirektionale Kommunikation zu ermöglichen, diskutiert werden soll. Vielleicht lassen sich beide Ansätze ja sinnvoll verknüpfen. Zu diesem Thema gleich noch ein Hinweis von mir:
Zitat von: herrmannjSourcecode:
Soweit ich das verstanden habe hat er das selbst geschrieben, Basis war reverse engineering der original firmware und Studium der Chips. Wenn Du die FW auspackst (war glaub ich tar oder sowas) findest Du ein busybox linux. Die Apps sind kleine C progs. Du bräuchtest die busybox toolchain um da was zu schreiben. Ist imho machbar, aber mit hohem Zeiteinsatz.
Zitat von: ritchieAber auf dem Testsystem müsste man vorher die App auch selber testen, daher müsste man auch selber kompilieren.
Das wäre für mich kein Problem, da mein Desktop selber eine Linux System ist und ich bereits eine Toolchain für einen Arm am laufen habe.
Wenn das Zielsystem auch ein ARM Prozessor ist und ich z.B. ein Beispielprogm einer App haette, könnte man hier langsam was aufbauen.
Zitat von: ritchieEine Entwicklungsumgebung auf dem System konnte ich nicht finden (gcc).
[...]
Zudem hat er auch in der Linux-Version den Ursprung gelöscht (uname -a) zeigt keinen Ursprung.
Alles was man für die Entwicklung braucht, gibt es hier:
http://en.ingenic.cn/product.aspx?ID=62
Prima Zusammenfassung, ergänzend dazu:
Eine passend Toolchain konnte ich aufsetzen und erfolgreich testen. Die Hardware (kmp510, 511 -> Archos Webradio, Xoro HMT350, 370) verstehe ich mittlerweile ausreichend um alle Schlüsselfunktionen (Radio Display, Audio- und Videowiedergabe, Remotecontrol, Bildschirmhelligkeit) verwenden zu können.
Zum Verständniss: die Firmware besteht aus zwei Schlüsselkomponenten:
* eine speziell angepassten Linux Version mit den erforderlichen Treiber für die verbauten Hardwarekomponenten.
* die "Apps" der Listenlive Firmware werden von einem einzelnen Programm geformt. (jz-media-app)
Es ist ohne Nebenwirkungen möglich diese Anwendung zu schließen (telnet pkill) und an ihrer Stelle eine eigene Anwendung (zB von der SD Karte) zu starten die dann die Bildschirmausgabe + Mediensteuerung übernimmt. Daran arbeite ich im Augenblick mit dem Ziel diese Anwendung direkt für FHEM verfügbar zu machen.
Grüße,
Jörg
Nicht dass jemand meint, ich hätte hier was vergessen anzuhängen: eine aktualisierte Version des Moduls zum Testen kommt hier in den nächsten Tagen. Bin grade noch an einer Codebereinigung und an einer Vereinheitlichung der readings.
Aktuell wird mein llradio als Radiowecker über Google-Kalender und das Calendar-Modul von FHEM gesteuert. Der Kalendereintrag beinhaltet im "Betreff" den Befehl, der an das Radio geschickt wird und im "Ort" den Namen des zu steuernden Radios. Damit können über den gleichen Kalender mehrere Radiowecker gesteuert werden.
(http://up.picr.de/15192289xb.png)
Interpretation des Kalendereintrags:
- am 15.07.2013 um 0530 Uhr wird an das LL-device "llradio" der Befehl "user weckerswr3" geschickt
- um 0700 Uhr wird das Radio wieder abgeschaltet
Was verbirgt sich hinter "user weckerswr3" ?
Relativ einfach. Das ist der Befehl, der an das Radio geschickt wird. "Befehl" in diesem Sinne kann fast alles sein: Angefangen vom einfachen EInschaltbefehl "power on" bis hin zu einem kompletten SUB, das z.B. in einer 99_myUtils.pm definiert sein kann:
Im konkreten Beispiel verbirgt sich dahinter folgende Sequenz:
sub weckerswr3(){
{fhem("set llradio power off")};
select(undef,undef,undef,1);
{fhem("set llradio power on")};
select(undef,undef,undef,1);
{fhem("set llradio audio unmute")};
select(undef,undef,undef,0.5);
{fhem("set llradio raw HOME")};
select(undef,undef,undef,0.5);
{fhem("set llradio raw OK")};
select(undef,undef,undef,0.5);
{fhem("set llradio raw OK")};
select(undef,undef,undef,0.5);
{fhem("set llradio raw OK")};
select(undef,undef,undef,0.5);
{fhem("set llradio raw MENU")};
select(undef,undef,undef,0.5);
{fhem("set llradio raw MENU")};
}
Ablauf der Befehlsfolge:
zuerst wird das Radio ausgeschaltet, falls es angeschaltet sein sollte.
danach wird es wieder eingeschaltet,
es wird ein MUTE Status deaktiviert, falls aktiv (ich habe noch nicht getestet, ob der beim Ausschalten automatisch gelöscht wird)
es wird ein HOME Befehl geschickt, um den Cursor an eine eindeutige Position zu schicken,
es wird per Cursor-Steuerung der erste Eintrag aus den Favoriten ausgewählt,
es wird die Wiedergabe gestartet,
es wird auf die Anzeige der aktuellen Wetterlage umgeschaltet
Die Prozedur mit dem Aus- und Einschalten wird so lange nötig sein, solange es keine Möglichkeit gibt, den aktuellen Gerätestatus zu ermitteln, um laufende andere Anwendungen (falls vorhanden) zu beenden und einen definierten Zustand herzustellen.
Das Ausschalten des Gerätes am Ende des Kalenderevents ist im zugehörigen notify fest hinterlegt.
Hier ist das notify für das Einschalten:
define Wecker_an notify Kalender_Wecker:modeStarted.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my $actor= fhem("get Kalender_Wecker location $uid"); if(defined $actor) { my $action= fhem("get Kalender_Wecker summary $uid"); fhem("set $actor $action") } }
Hier ist das notify für das Ausschalten:
define Wecker_aus notify Kalender_Wecker:modeEnded.* { my $reading="%EVTPART0"; my $uid= "%EVTPART1"; my $actor= fhem("get Kalender_Wecker location $uid"); if(defined $actor) { fhem("set $actor power off") } }
Und so sieht das LISTENLIVE-device mitsamt seinen Readings derzeit aus:
(http://up.picr.de/15192369rt.png)
Ich harre gespannt der neuen Firmware, die ja für diese Woche angekündigt ist. Momentan fehlen in meinem Modul noch die Get() und GetUpdate() sowie die komplette Dokumentation. Die Get-Teile machen einfach noch keinen Sinn, weil es noch nichts aus dem Gerät zu lesen gibt. Mir wäre ja mit einem Power-Status und dem Mute-Status schonmal sehr weitergeholfen, da dies Toggle-Befehle sind. FHEM merkt sich zwar, wenn diese beiden Aktionen geschaltet werden, aber das ist einfach noch nicht zuverlässig genug.
Für das persönliche Entwicklungsnotizbuch: Ich muss noch den Fehlerfall abfangen, dass llradio überhaupt nicht erreichbar ist, sonst schießt der Versuch, einen Befehl dorthin zu schicken, das ganze fhem ab *grmpf*
Ansonsten funktioniert der ferngesteuerte Radiowecker bisher recht zufriedenstellend.
"sowosamma" (Fredl Fesl)
Wie versprochen, hier der neueste Entwicklungsstand.
Syntax zum Anlegen einen ListenLive-Webradios:
define <name> LISTENLIVE <ip-adresse>[:port] [interval]
Beispiel 1:
define llradio1 LISTENLIVE 192.168.222.222
ergibt in FHEM folgendes listing:
Internals:
CFGFN
DEF 192.168.222.222
NAME llradio1
NR 1634
STATE online
TYPE LISTENLIVE
Readings:
2013-07-19 21:39:17 interval 60
2013-07-19 21:39:17 ipaddr 192.168.222.222
2013-07-19 21:39:17 lastCmd
2013-07-19 21:39:17 lastResult
2013-07-19 21:39:17 menuPos 11
2013-07-19 21:39:17 mute ???
2013-07-19 21:39:17 port 8080
2013-07-19 21:39:17 power ???
2013-07-19 21:39:17 state online
Helper:
ADDRESS 192.168.222.222
AVAILABLE 1
INTERVAL 60
PORT 8080
Attributes:
eventMap absent:offline present:online
Da bei der Definition die optionalen Parameter für Port und Intervall (Erklärung später) weggelassen wurden, werden die Standardwerte port=8080 und interval=60 Sekunden verwendet.
Beispiel 2:
define llradio2 LISTENLIVE 192.168.222.222:7070 300
ergibt
Internals:
CFGFN
DEF 192.168.222.222:7070 300
NAME llradio2
NR 1651
STATE online
TYPE LISTENLIVE
Readings:
2013-07-19 21:41:41 interval 300
2013-07-19 21:41:41 ipaddr 192.168.222.222
2013-07-19 21:41:41 lastCmd
2013-07-19 21:41:41 lastResult
2013-07-19 21:41:41 menuPos 11
2013-07-19 21:41:41 mute ???
2013-07-19 21:41:41 port 7070
2013-07-19 21:41:41 power ???
2013-07-19 21:41:41 state online
Helper:
ADDRESS 192.168.222.222
AVAILABLE 1
INTERVAL 300
PORT 7070
Attributes:
eventMap absent:offline present:online
und wie man sieht, wurden die Parameter 7070 und 300 entsprechend übernommen.
Der Parameter Intervall gibt an, in welchem Abstand der Gerätestatus gelesen und aktualisiert wird. Zum derzeitigen Zeitpunkt wird hier lediglich die Erreichbarkeit des Gerätes geprüft, weil es vom Gerät selbst noch nichts zu Lesen gibt.
Die Prüfung der Erreichbarkeit erfolgt mit Hilfe von PRESENCE
Falls vorhanden, wird eine vorhandene PRESENCE-entity die sich auf das Gerät bezieht, verwendet, um den Status online/offline zu aktualisieren. Die Definition von PRESENCE setzt voraus, dass der Name mit pres_ beginnt und dann den Namen des Gerätes angehängt wird. In den obigen Beispielen wären dies also pres_llradio1 bzw. pres_llradio2.
define pres_llradio1 PRESENCE lan-ping 192.168.222.222 60 300
Die genaue Beschreibung von PRESENCE ist der commandref zu entnehmen.
Diese Art der Prüfung wurde gewählt, da ich keinerlei Notwendigkeit sah, das Rad neu zu erfinden oder Coding aus dem PRESENCE-Modul zu kopieren und wiederzuverwenden.
Fehlt die entsprechende PRESENCE-Definition zum Gerät, wird immer "online" vermutet. Achtung: Dies kann zu unerwünschten Effekten führen!
Beschreibung der derzeit unterstützten Befehle
Allgemeine Syntax:
set llradio <Befehlsgruppe> <Kommando>
Die einzelnen Kommandos sind in funktionsbezogene Gruppen zusammengefasst.
Es gibt im Moment folgende Gruppen und Befehle:
Befehlsgruppe "audio"
set llradio audio mute
set llradio audio unmute
set llradio audio volm
set llradio audio volp
Befehlsgruppe "cursor"
set llradio cursor down
set llradio cursor left
set llradio cursor up
set llradio cursor right
set llradio cursor enter
set llradio cursor exit
set llradio cursor home
set llradio cursor ok
Befehlsgruppe "power"
set llradio power off
set llradio power on
Befehlsgruppe "raw"
set llradio raw <command>
Befehlsgruppe "reset"
set llradio reset menupos
set llradio reset mute
set llradio reset power
Befehlsgruppe "user" (experimentell!)
set llradio user <userDefFunction>
Befehlsgruppe "app" (experimentell!)
set llradio app weather
Befehlsgruppe statusRequest
set llradio statusRequest
Die meisten Befehle sollten selbsterklärend sein.
Die "reset" Kommandos dienen dazu, klar definierte Zustände herstellen zu können, solange es noch keine Lesemöglichkeit direkt aus dem Gerät gibt. Diese Befehle werden eigentlich nur benötigt, wenn die in fhem gespeicherten Readings nicht mit den tatsächlichen Zuständen am Gerät übereinstimmen. Eine ausführliche Erklärung erfolgt ggf. später. Eventuell fällt diese Befehlsgruppe nach dem Erscheinen der neuen LL-Firmware komplett weg.
In der Befehlsgruppe "cursor" sind die Kommandos "enter" und "ok" absolut identisch (ich habe die nur aus Gründen der usability kopiert)
In der experimentellen Gruppe "app" wurde testweise die Auswahl der Wetter-Applikation mittels der Cursortasten abgebildet.
Die Befehlsgruppe "user" werde ich zu gegebener Zeit dokumentieren, diese Gruppe ist ebenfalls noch in einem Experimentierstadium. Es könnte sein, dass diese Gruppe aus Sicherheitsgründen auch wieder komplett wegfällt.
Bei statusRequest gibt es keinen zweiten Teil beim Aufruf.
Viel Spaß beim Testen!
Ich freue mich über jede Rückmeldung und habe auch ein offenes Ohr für Fragen, Änderungsvorschläge und Wünsche. Aber bitte nicht per email, sondern hier im Forum, da haben dann nämlich alle Tester etwas davon.
Hiho,
cool dass es da weitergeht. Werd mir alsbald so'n Ding bestellen :)
Hast Du den fred gesehen: Link (http://forum.fhem.de/index.php?topic=13784.0)
Gruß, Uli
Hallo Uli,
ja, habe ich gelesen. Allerdings ist bei der ListenLive Firmware im Moment noch das Problem, dass niemand weiss, was in der nächsten (eigentlich für diese Woche) angekündigten Firmware kommen wird und die Steuerung aktuell noch sehr rudimentär erfolgt.
Die eigentlichen Wiedergabefunktionen habe ich ja noch gar nicht implementiert. Die WIedergabe kann aber auch jetzt schon mittels "set llradio raw <command>" gesteuert werden, wobei <command> einBefehl aus dieser Menge sein kann:UP LEFT DOWN RIGHT EXIT POWER OK VOLp VOLm STOP REPEAT PGUP PGDN RECORD HOME MENU MUTE FORWARD REWIND FMRADIO
Naja, und die meisten der im genannten "Einheitlichkeit"-Thread gemachten Vorschläge habe ich ja bereits umgesetzt bzw. vorbereitet.
Das Gerät selbst liefert mir noch überhaupt keine Rückmeldung (z.B. Lautstärke oder gar die Menüposition) sodass ich mir den Power-Status in FHEM in einem Reading merke. Das Schlimme ist, dass das Einschalten über ein Toggle erfolgt, da für PowerOn und PowerOff der gleiche Befehl "Power" verwendet wird. Identisches Verhalten beim Mute.
Naja, warten wir mal, was die nächste Firmware wirklich bringt - ich bin jedenfalls schonmal vorbereitet. Man soll ja dann z.B. auch Textnachrichten als Popup schicken können :)
Viele Grüße
Udo
Im Moment ist das Ganze für mich noch im Status "Proof of Concept" - natürlich ist die Implementierung aller Steuerungsbefehle ebenso geplant, wie es schon ein "Gerüst" für weitere Funktionsgruppen gibt.
Gruppe "play"
play play
play pause
play stop
play forward
play rewind
play fforward
play frewind
play record
Gruppe "media"
media radio <inetRadioUrl>
media tv <inetTvUrl>
media file <fileName>
Gruppe "send"
send message <text>
send image <imagefile>
Diese (möglichst logisch gehaltene) Gruppenstruktur ermöglicht eine sehr einfache Erweiterung des LL-Moduls.
Als nächstes wird ein
get llradio <list commands>|<help>
implementiert. Wobei mir "help" besser gefällt. Auf jeden Fall wird auch das GET in logischen Funktionsgruppen strukturiert sein.
Zitat von: betateilchen schrieb am Fr, 19 Juli 2013 23:01Als nächstes wird ein
get llradio <list commands>|<help>
implementiert.
Für "list commands" gibt's schon einen fhem-Standard:
set <device> ?
get <device> ?
Muss auch eine Antwort im vorgeschriebenen Format liefern, damit FHEMWEB das richtig darstellt.
=8-)
Ok, das mit dem Fragezeichen soll nicht das Problem sein. Auch wenn mir das bisher noch nirgends untergekommen ist. Wo finde ich das "vorgeschriebene Format"?
Im Moment funktioniert die Anzeige der Hilfetexte bei mir im WebFrontend problemlos :o)
Zitat von: betateilchen schrieb am Fr, 19 Juli 2013 23:27Wo finde ich das "vorgeschriebene Format"?
Leider nur in anderen Programmen :(
elsif ($arg eq "?") {
return "Unknown argument $arg choose one of <liste der gültigen Kommandos>";
=8-)
Ach, wenns weiter nix ist :) Dann habe ich das ja instinktiv richtig eingebaut.
get llradio ?
liefert
(http://up.picr.de/15230694du.png)
set llradio ?
liefert
(http://up.picr.de/15230705ep.png)
Zufrieden?
Übrigens, elseif finde ich gruslig...
nicht ganz ok :)
das format wenn du alles so in gruppen unterteilst ist <grupe>:<param1>,<param2>,... dann erzeugt das web frontend in der detail ansicht gleich die richtige combobox mit den einträgen für die commandos.
die liste die bei set/get ? zurückkommt wird nach leerzeichen gesplittet und sortiert.
gruss
andre
Zitat von: betateilchen schrieb am Fr, 19 Juli 2013 23:48Zufrieden?
Finde ich sehr schön und übersichtlich, entspricht aber nicht der Konvention.
Versuch mal
set WEB ?Aber vll checkt's Rudi ja auch so ein.
Die Meldung "
Unknown argument ...blabla" wird wohl auch in
list und
json etc gecheckt und rausgefiltert.
Das Ergebnis von
set <device> ? wird als Liste für das set-dropdown im detailscreen des device verwendet. Dessen Inhalt dürfte bei Dir jetzt interessant ausssehen...
=8-)
und noch was :
- die liste die bei set/get ? zurück kommt wird dyanmisch immer wieder abgefragt. du kannst also je nach device zusatand mehr oder weniger zurueck geben. und wenn du z.b. stations presets konfiguriert hast diese dynamisch so einbauen das im web automatisch ein menü zur auswahl erscheint.
- das web frontend kann im prinzip auch automatisch slider für das volume erzeugen. das geht aber nur wenn das kommando direkt volume heisst. in der set ? liste muss es dann mit volume:slider,0,1,100 erscheinen (<commando>:slider,<min>,<schrittweite>,<max>)
ganz ohne die vorteile deiner lösung in frage zu stellen... es passt halt leider zu nichts das fhem bis her macht und wird an allen ecken und enden kleine oder grössere probleme machen und z.b. nicht zu im frontend automatisch generierten elementen passen. genau das würde ich halt gerne mit dem anderen thread verhindern oder minimieren wollen.
gruss
andre
Hallo Uli,
*lach*
Diese "Konventionen" sind die Entwicklungsgrundlagen, die ich bisher für FHEM verzweifelt gesucht, aber nirgends gefunden habe. Bisher hatte ich gar keine setliste - nun wird mir auch klar, warum.
Aber das ist ja auch kein Problem, ich werde das Fragezeichen erstmal temporär in "help" ändern und das "Unknown bla..." am Ende einbauen, wenn ich die Befehle alle zusammen habe. Zum Einchecken ist es m.E. noch zu früh.
Danke übrigens für Deine Hilfe!
Zitatganz ohne die vorteile deiner lösung in frage zu stellen... es passt halt leider zu nichts das fhem bis her macht und wird an allen ecken und enden kleine oder grössere probleme machen und z.b. nicht zu im frontend automatisch generierten elementen passen.
Nun mal nicht so pessimistisch sein und alles schlechtreden wollen, ich bin ja lernfähig und -willig.
Wie würdest Du denn eine Hilfefunktion für solche umfangreichen Strukturen Implementieren?
wie wäre es die struktur der kommandos bei zu behalten aber zwischen gruppe und argument kein leerzeichen sondern einen punkt zu verwenden?
das würde deine logische struktur beibehalten und trozdem mit fhem kompatibel sein. zwar noch mit keinem anderen modul aber immerhin :)
gruss
andre
Das mit dem Punkt wäre kein Thema, das bedeutet ja lediglich eine Zeile mehr, die den Split macht.
Werde ich mir mal anschauen.
Besser?
(http://up.picr.de/15230964ao.png)
und im Device ergibt das nun:
(http://up.picr.de/15230965ay.png)
Wie kann ich aus der Liste Einträge entfernen? Die Befehle online und offline machen da überhaupt keinen Sinn, weil der state immer automatisch von GetStatus gesetzt wird (werden muss)
Sehr schön, betateilchen kommt richtig voran ! Bitte wirklich nur als Frage verstehen: der Syntax mit den Punkten; besteht da nicht die Gefahr das er mit Regel kollidiert ?
Vg
Joerg
Hallo Jörg,
keine Sorge, ich habe das inzwischen entsprechend regelkonform gestaltet:
(http://up.picr.de/15232834fo.png)
und wenn man nun "help" auswählt sieht das dann so aus:
(http://up.picr.de/15232837em.png)
Wählt man hingegen "power" aus, wird der nächste Auwahlbutton angezeigt:
(http://up.picr.de/15232840cs.png)
So bleibt das Ganze schön übersichtlich gruppiert. Ich musste mich zuerst mit der korrekten Nutzung von $usage auseinandersetzen. Danke für die Tipps an justme1968 und UliM!
Die Punktsyntax z.B. "set <device> power.on" ist nur notwendig, wenn der Befehl direkt in der Kommandozeile eingegeben wird. Dabei sollte es keinerlei Kollisionen geben.
Kann ich eigentlich in Set() unterscheiden, ob ein Befehl von der Kommandozeile oder von den Frontend-Buttons kommt?
Aus der Kommandozeile kommt "set llradio power.on" (mit Punkt zwischen Gruppe und Befehl)
Aus den Buttons kommt "set llradio power on" (mit Leerzeichen zwischen Gruppe und Befehl)
Aktuell kann ich das noch relaitv einfach abfangen, aber spätestens bei den dreiteiligen Kommandos wird das ein Problem.
ich hatte das mit dem punkt gar nicht vorgschlagen um das eine immer per telnet zu benutzen und das andere im web. mein hintergedanke war das der volume slider z.b. nur funktioniert wenn das kommando dazu kein leerzeichen enthält. also eigentlich sogar umgekehrt: 'volume.set,slider,0,1,100' in der set ? liste um im frontend einen slider zu bekommen und auf der kommandozeile ganz normal 'volume set xxx'
also entweder es nur für die kommandos explizit erlauben die z.b. einen slider brauchen oder die zwei parameter haben um die ersten beiden zusammen zu fassen und dann im web das drop down menü für den dritten parameter verwenden zu können oder das parsen so bauen das es immer überall mit punkt oder leerzeichen klar kommt.
was die unterscheidung im set angeht: im prinzip geht es nicht. ich habe aber bemerkt das bei kommandos die per telnet kommen in den globalen webArgs room auf 'all' steht wenn man per telnet verbunden ist. ich verwende das im lightscene modu um zwischen web und telnet zu unterscheidenl und bis jetzt funktioniert es. also etwas in der art: use vars qw(%FW_webArgs); # all arguments specified in the GET
if( defined($FW_webArgs{room}) && $FW_webArgs{room} eq "all" ) {
# hier ist telnet
} else {
# hier ist web frontend
}
gruss
andre
Hm... *grübel* dann habe ich das mit dem Punkt-Vorschlag wohl irgendwie mißverstanden.
Also wenn ich das richtig verstehe, kann ich die Kommandosyntax mit Leerzeichen "set llradio power on" für die Kommandozeile einfach so belassen und muss dann nur für setlist das power:on,off angeben? Das wäre ja noch einfacher.
Gibt es in der setlist eigentlich auch eine Möglichkeit, dreiteilige Eingaben im Frontend zu generieren? Also etwas in der Art
Gruppe (erstes Dropdown) = "send"
Kommando (zweites Dropdown) = "image"
Inhalt (Eingabefeld) = <Dateiname>
ohne Gruppe und Kommando zusammenfassen zu müssen?
----- ----- ----- -----
Inzwischen wird auch das PRESENCE zum angelegten Webradio automatisch mit angelegt.
Ich werde - zumindest für die Entwicklungsphase - auch noch ein Attribut "dummy" einbauen, damit man die Bedienung auch testen kann, ohne die Hardware tatsächlich zu haben.
Hi,
1. warum unterscheiden?
2. warum mit Punkt? Sehr verwirrend, da das kein anderes Gerät so macht.
3. warum mit power? Alle anderen Geräte verwenden set <device> on
Gespannte Grüße,
Uli
PS: eigtl ist dies die Diskussion um einheitl. Befehle, siehe Link oben.
Hallo Uli,
zu 1 + 2: die Sache mit dem Punkt beruhte wohl irgendwie auf einem Mißverständnis meinerseits und ist wieder ausgebaut.
zu 3: weil ich eine möglichst einheitliche Kommandostruktur haben möchte. Und bei Power kann es nicht nur on und off geben, sondern z.B. auch noch Standby oder einen Sleeptimer.
Und speziell bei den ListenLive Geräten ist es so, dass es eine Vielzahl von Möglichkeiten gibt, was passieren soll, wenn man den Power-Knopf drückt (z.B. Umschalten auf Uhrzeitanzeige, und das auch noch unterschieden nach "Uhr tagsüber" und "Uhr nachts". Deshalb finde ich hier eine Gruppierung "power" sehr sinnvoll, um möglichst flexibel zu bleiben.
ZitatPS: eigtl ist dies die Diskussion um einheitl. Befehle, siehe Link oben.
stimmt, aber ich habe diese Diskussion nicht hier in den Thread gebracht, wo sie eigentlich nicht hingehört ;)
Viele Grüße
Udo
> Und bei Power kann es nicht nur on und off geben, sondern z.B. auch noch Standby oder einen Sleeptimer.
Falls ein Geraet on & off definiert, dann bietet FHEMWEB automatisch toggle an, falls man auf dem Status klickt. Ob das bei einem Radio wichtig ist, darf der Modulauthor entscheiden :) Btw. als Status-Widget kann ein Modul (dank der Noergelei von Andre :) auch was komplexeres bauen, wie z.Bsp. eine Knopfleiste mit On/Off/Mute/Vol+/Vol-, siehe FW_summaryFn. Oder man baut das gleiche als Kommando-Darstellung, wie slider, time und colorpicker, dann kann der Benutzer das mit dem passenden webCmd einblenden.
> Kann ich eigentlich in Set() unterscheiden, ob ein Befehl von der Kommandozeile oder von den Frontend-Buttons kommt?
Nein, mAn sollte ein Modul das aber auch nicht unterscheiden. CommandSet in fhem.pl hat in $cl noch den Ausloeser (telnet oder FHEMWEB Instanz), das wird aber weder an DoSet und schon gar nicht mehr an SetFn weitergegeben.
> Gibt es in der setlist eigentlich auch eine Möglichkeit, dreiteilige Eingaben im Frontend zu generieren?
Nicht direkt. Es gibt aber die oben erwaehnte Moeglichkeit, ein "widget" zu spezifizieren, was beim Auswaehlen des ersten Dropdowns erscheint, z.Zt sind slider, time und colorpicker so realisiert. Damit koennte man auch einen Doppel-Dropdown realisieren.
die unterscheidung web/telnet geht wie gesagt mit dem workaround oben.
die anwendung im LightScene modul ist das ich beim save kommando auf der konsole Informationen zurück gebe die dort dann direkt angezeigt werden. wenn ich das beim aufruf über das web frontend auch mache fliege ich aus der detail ansicht und lande auf der hauptseite. also gebe ich im web fall nichts zurück. das ist auch unnötig weil der geänderte zustand direkt grafisch über die detailFn zu sehen ist.
ohne den workaround hätte ich wieder genörgelt :)
Zitat von: rudolfkoenig schrieb am Sa, 20 Juli 2013 16:28Falls ein Geraet on & off definiert, dann bietet FHEMWEB automatisch toggle an, falls man auf dem Status klickt. Ob das bei einem Radio wichtig ist, darf der Modulauthor entscheiden :)
Hallo Rudi,
ich kann natürlich on und off auch noch einbauen. Die Befehle würden dann intern einfach auf "power on" und "power off" gemappt. Dann fange ich aber an, meine Strukturierung aufzuweichen und die Programmierung unübersichtlich zu machen. Da ich davon ausgehe, dass es bei diesen Geräten demnächst eine Art "Skripting" geben wird und das Gerät wohl in den seltensten Fällen über das Web-Frontend gesteuert werden wird, finde ich es nach wie vor besser, möglichst ALLE Befehle in eine Gruppe zu integrieren. Deshalb gibt es on und off hier bisher nicht einzeln.
Das mit den Widgets werde ich mir bei Gelegenheit anschauen.
Inzwischen habe ich auch die Möglichkeit geschaffen, ein solches Gerät als Dummy anzulegen, indem man einfach anstatt einer IP-Adresse den Wert "dummy" angibt. Wahrscheinlich werde ich heute abend hier nochmal eine neue Modulversion anhängen.
Thema Dokumentation: Gibt es irgendwo eine brauchbare Anleitung, wie man bei der Dokumentationserstellung vorgehen muss?
Viele Grüße
Udo
> die unterscheidung web/telnet geht wie gesagt mit dem workaround oben.
Das dieser workaround zuverlaessig funktioniert, wage ich zu bezweifeln. FW_webargs ist nicht definiert, falls das FHEMWEB Modul nicht geladen ist. Die Werte haengen davon ab, wohin der Benutzer zuletzt geklickt hat.
> ich kann natürlich on und off auch noch einbauen.
Das dies Dir ueberlassen wird, meinte ich ernst, und die Zeile ist nicht als indirekte Motivation zu verstehen.
> Inzwischen habe ich auch die Möglichkeit geschaffen, ein solches Gerät als Dummy anzulegen, indem man einfach anstatt einer IP-Adresse den Wert "dummy" angibt.
Das ist bei vielen von mir gebauten Modulen das Wort "none", und ist mAn unerlaesslich.
> Gibt es irgendwo eine brauchbare Anleitung, wie man bei der Dokumentationserstellung vorgehen muss?
Nicht wirklich: bei den anderen Modulen abschauen, dann contrib/commandref_join.pl aufrufen, und das Ergebnis in Browser betrachten.
Hallo Rudi,
ok, das dummy in none umzubennen ist kein Thema.
commandref_join werde ich mir anschauen. WO erstelle ich den Text für die Dokumentation? Direkt am Ende des Moduls oder irgendwo ausserhalb?
Viele Grüße
Udo
----------
edit: ok ok... ich glaub, ich hab auch das kapiert. Sieht doch schon ganz gut aus:
(http://up.picr.de/15237540ig.png)
Hier kommt die neue Modulversion :)
Was hat sich seit gestern geändert?
- das PRESENCE pres_<name> wird während des DEFINE automatisch mit angelegt, wenn nicht vorhanden
- set <name> ? (hoffentlich) regelkonform implementiert
- get <name> ? (hoffentlich) regelkonform implementiert
- set <name> help => liefert eine Befehlsliste zu set
- get <name> help => liefert eine Befehlsliste zu get
- define <name> LISTENLIVE none => erzeugt ein Dummy-Device für Testzwecke ohne ein presence.
- Dokumentation pod (DE) hinzugefügt
Es reift langsam, aber sicher. Und nun ist Wochenende.
Seit heute ist 71_LISTENLIVE.pm Bestandteil von FHEM und wird beim regulären Update mit ausgeliefert.
Rückmeldungen, Anregungen, Kritik zu dem Modul bitte hier im Thread posten.
Viel Spaß damit!
Planung für die nächste "große" Version:
Anbindung an 95_remotecontrol und automatische Bereitstellung eines Standardlayouts für die Fernbedienung des HMT350.
Das habe ich heute abend eingebaut und es hat grundsätzlich auf Anhieb funktioniert. Mir fehlen allerdings noch ein paar Buttons, um die Fernbedienung "schön" darstellen zu können. Testweise wird derzeit die oberste Zeile bereitgestellt.
(http://up.picr.de/15277079og.png)
All das, was auf diesem Screenshot zu sehen ist, kann quasi "automatisch" erstellt werden - und die Gerätesteuerung über die beiden Buttons funktioniert auch schon einwandfrei.
Die Anbindung an remotecontrol ist fertig - und funktioniert hier im Testbetrieb weitgehend problemlos.
So gehts:
define llradio LISTENLIVE <ip-adresse>
define llradio_rc remotecontrol
set llradio_rc layout HMT350
set llradio_rc makenotify llradio
set llradio_rc makeweblink
Danach sollte man im room "unsortiert" folgende Teile finden:
(http://up.picr.de/15286449rc.png)
und ein Mausklick auf den roten Powerknopf sollte das Gerät ein- und ausschalten.
Anmerkung 1: der weblink wird standarmäßig ohne Gruppenname und ohne Rahmen drumrum angezeigt! Hier nur für Entwicklungszwecke angezeigt.
Anmerkung 2: Die Änderung wird heute noch eingecheckt und steht morgen per update bereit. Dann werden auch die benötigten neuen Icons mit ausgeliefert.
Anmerkung 3: warum der Button zwischen RETURN und STOP nicht korrekt angezeigt wird, weiß ich noch nicht. Manchmal ist er da, manchmal nicht - sehr ulkig.
Die schon vor 3 Monaten angekündigte neue Firmware für ListenLive-Geräte wurde immer noch nicht veröffentlicht *grummel*
Hi betateilchen,
zumindest steht seit 6.1. auf der Homepage, dass es jetzt wirklich bald losgeht ;D
Die Beta ist da :)
ja, hab ich gesehen... 8)
Muss mal schauen, wann ich zum Testen komme.
(http://up.picr.de/17025894rk.jpg)
Jetzt muss ich nur noch irgendwo Informationen über die neuen Netzwerkbefehle finden...
ei ei ei... die bisherigen Netzwerkbefehle scheinen gar nicht mehr zu funktionieren...
Hier gehts weiter: http://forum.fhem.de/index.php/topic,18692.0.html