Sammelthread: Steuerung von Webradios mit ListenLive Firmware

[justme1968]

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

[UliM]

Zufrieden?

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-)

[justme1968]

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

[betateilchen]

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!

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.

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?

[justme1968]

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

[betateilchen]

Das mit dem Punkt wäre kein Thema, das bedeutet ja lediglich eine Zeile mehr, die den Split macht.

Werde ich mir mal anschauen.

[betateilchen]

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)

[herrmannj]

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

[betateilchen]

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.

[betateilchen]

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.

[justme1968]

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:

Code Auswählen Erweitern

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

[betateilchen]

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.

[UliM]

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.

[betateilchen]

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.

PS: 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

[rudolfkoenig]

> 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.