[gelöst] menu abhängig vom Reading oder ...

draddy · 29 März 2022, 21:20:05

moin,

der mit den Verrückten Ideen wieder ...

Beispiel Kodicontroll Template;

habe ja per default im 1. Main level "prev" "play|pause|stop" "next" drin

jetzt dachte ich mir so, beim TV schauen juckt mich prev und next null, weil ich kein "timeshifter" bin - channel up & down wären da geschickter.

gut, also, Buttons geändert auf type (ok, hab nen "Hilfsreading" eingebaut aber egal...) wenn type jetzt "Channel" (TV) ist wird mir ein up und down angezeigt und auch umgesetzt (also reading von "click" genau so geändert)

soweit, so "normal"
jetzt dachte ich mir, statt play|pause wäre im TV Modus eigentlich ein Menü geschickt, wo ich mir so eine Handvoll Favoriten Sender speichern kann.

Problem; Menü kann das ja gar nicht

daher Frage / Wunsch: bekommt man das irgendwie hin, oder kann ich eventuell ein komplettes Main Level "austauschen" jeh nachdem was aktuell aktiv ist. (ähnlich "show" fürs Template?!"
bzg. Menü, wäre halt das man es an ein bestimmtes reading knüpft vll dann irgendwie so:

Code Auswählen


"midMenu":["Reading:Wert":{"text:cmd", "text2:cmd2",..."textn:cmdn"}]

um die "einfachheit" nicht zu beeinflussen, könnte man diesem menü ja nen anderen namen geben ... damit könnten alle anderen Templates die aktuell schon auf Menu laufen auch änderungsfrei weiter laufen.

"tausch einfach das ganze Template aus mit show" wird der ein oder andere sagen, mini Problem dabei ist allerdings, dass type immer kurz umspringt, wenn man den Sender wechselt, das ist beim Austausch von paar Buttons nicht soo tragisch, weil die dann eben kurz wechseln, aber glaube wenn immer ganzes Templates 1aus 2an 2aus 1an wechseln ist das ehr "uncool"

was meint der Rest dazu? und vor allem, was denkt Jens dazu? ^^

Lg
Jens

draddy · 30 März 2022, 11:35:37

zusatzfrage:

kann ich im Menü ein setreading nutzen?

also "setreading <devicename> <Reading> <Wert>" funktioniert ... problem fürs template ist natürlich, das devicename halt immer unterschiedlich ist.

habe es mit $name versucht, klappt aber nicht (obwohl das Menü dann den haken beim aktuellen Eintrag setzt, klappt das ändern nicht)

jemu75 · 30 März 2022, 16:43:03

Zitat von: draddy am 30 März 2022, 11:35:37
zusatzfrage:

kann ich im Menü ein setreading nutzen?

also "setreading <devicename> <Reading> <Wert>" funktioniert ... problem fürs template ist natürlich, das devicename halt immer unterschiedlich ist.

habe es mit $name versucht, klappt aber nicht (obwohl das Menü dann den haken beim aktuellen Eintrag setzt, klappt das ändern nicht)

Das Menü funktioniert, wie hier beschrieben:
https://github.com/jemu75/fhemApp#eigene-templates-erstellen
Die Zuweisung besteht lediglich aus einem Text, der im Menü angezeigt wird und einem Fhem Kommando, welches ausgelöst wird.
Weiterhin wird das im Fhem-Kommando verwendet reading zur Prüfung des aktiven Menüelementes verwendet.

Beispiel:
set myActor on -> hier wird der Wert vom Reading 'state' auf 'on' geprüft
set myActor pct 50 -> hier wird der Wert vom Reading 'pct' auf '50' geprüft

jemu75 · 30 März 2022, 16:59:27

Zitat von: draddy am 29 März 2022, 21:20:05
moin,

der mit den Verrückten Ideen wieder ...

Beispiel Kodicontroll Template;

habe ja per default im 1. Main level "prev" "play|pause|stop" "next" drin

jetzt dachte ich mir so, beim TV schauen juckt mich prev und next null, weil ich kein "timeshifter" bin - channel up & down wären da geschickter.

gut, also, Buttons geändert auf type (ok, hab nen "Hilfsreading" eingebaut aber egal...) wenn type jetzt "Channel" (TV) ist wird mir ein up und down angezeigt und auch umgesetzt (also reading von "click" genau so geändert)

soweit, so "normal"
jetzt dachte ich mir, statt play|pause wäre im TV Modus eigentlich ein Menü geschickt, wo ich mir so eine Handvoll Favoriten Sender speichern kann.

Problem; Menü kann das ja gar nicht

daher Frage / Wunsch: bekommt man das irgendwie hin, oder kann ich eventuell ein komplettes Main Level "austauschen" jeh nachdem was aktuell aktiv ist. (ähnlich "show" fürs Template?!"
bzg. Menü, wäre halt das man es an ein bestimmtes reading knüpft vll dann irgendwie so:
Code Auswählen Erweitern
"midMenu":["Reading:Wert":{"text:cmd", "text2:cmd2",..."textn:cmdn"}]
um die "einfachheit" nicht zu beeinflussen, könnte man diesem menü ja nen anderen namen geben ... damit könnten alle anderen Templates die aktuell schon auf Menu laufen auch änderungsfrei weiter laufen.

"tausch einfach das ganze Template aus mit show" wird der ein oder andere sagen, mini Problem dabei ist allerdings, dass type immer kurz umspringt, wenn man den Sender wechselt, das ist beim Austausch von paar Buttons nicht soo tragisch, weil die dann eben kurz wechseln, aber glaube wenn immer ganzes Templates 1aus 2an 2aus 1an wechseln ist das ehr "uncool"

was meint der Rest dazu? und vor allem, was denkt Jens dazu? ^^

Lg
Jens

Also ich sehe erstmal, dass Du eine Lösung suchst. Aber ich habe die Logik noch nicht verstanden, die Du wünschst.

In dem Zusammenhang ein Thema aus früheren Festurewünschen. FHEMApp richtet sich primär an den Endanwender, weniger an den 'Techi'. D.h. die Oberfläche soll für jeden bedienbar sein, die/der nichts von der Materie versteht. Also im einfachsten Fall wie der Lichtschalter an der Wand oder die klassische 'Fernbedienung'.
Bei der Umsetzung von Anforderungen ist mir das (weniger ist mehr) wichtig.

Wenn wir einen Ansatz finden, der abhängig von einem 'reading' das passende "Level" aus einem "Mehrlevel-Template" an die erste Stelle holt (oder andere garnicht erst aktiviert?) dann bin ich gern bereit.

Jamo · 30 März 2022, 17:27:29

Hi Draddy,
ich denke nicht das der Jens das in fhemApp loesen sollte. Das kann man auch in fhem ueber ein paar zeilen perl code machen.
Es steht doch immer frei, abhängig von irgendeinem state oder reading in fhem, z.B. das z.B. ein template kodi_1 dynamisch in Kodi_2 zu ändern. Evtl muss man dan einmal ein refresh / reload machen. Nur mal als sketch (kein funktionsfaehiger kode)

Code Auswählen

if ($kodistate eq 'thisandthat') {fhem ("attr KodiPlayer appOptions { \"template\": \"kodi_1\", \"name\": \"KODI\", \"room\":. . . .}}");
else                             {fhem ("attr KodiPlayer appOptions { \"template\": \"kodi_2\", \"name\": \"KODI\", \"room\":. . . .}}");

draddy · 30 März 2022, 18:00:21

ok, ich versuchs nochmal xD

also, nehmen wir ein menü, und nenen es select
select würde so aufgebaut:

Code Auswählen


"select":["Reading:Wert":
	{
		"text:cmd",
		"text2:cmd2",
		"textn:cmdn"
	}]

also, in der Theorie wie ein menü auch (name:cmd) aber mit der Erweiterung, es von einem Reading und dessen wert abhängig zu machen.
So würde es NICHT gezeigt werden, wenn das Reading nicht erfüllt ist, ODER es den falschen wert hat.

Damit könnte man z.B. (Bleiben wir bei Kodi) im falle von Reading: type - Wert: channel ein menü mit Favorisierten TV Sendern anzeigen, und wenn das Reading: type irgendwas anderes ist (Song, Movie kA wat) einfach nur nen Button fürs allgemeine Kodi Contexmenü (ist fester "Befehl" kA ob du Kodi Verwendest^^)

Wiegesagt, WENN würde ich Menü lassen wie es ist, und etwas "neues" mit der Erweiterung machen, damit können alle existenten Templates weiter laufen ohne Änderung UND es bleibt für die die es nicht benötigen einfach

zur Zusatzfrage:
Drauf gekommen bin ich halt, weil besonders dieses Reading type sich mit jedem Senderwechsel ändert und es auch nen Moment dauern kann, bis es wieder gesetzt ist, daher habe ich ein userreading "tState" gemacht, welches type spiegelt, wenn channel ists channel, sonst einfach other, das verbessert die lage etwas ...
Heute früh kam mir aber die Idee, ideal wäre einfach ein "Mode" den ich kurz setze, und das Template weiss wie es agieren soll.

Code Auswählen


                "rightMenu": ["contex:contextmenu",
                        "off:off",
                        "Mode TV:setreading $DEVICE tState channel",
                        "Mode Media:setreading $ tState other"]

wie man sieht, hier fummel ich, bzw.stehe ich an - ich kann natürlich "Mode TV:setreading Jens_Kodi tState channel" machen ... aber ... das ist "hardcoded" im Template also nicht ideal. Für dieses eigene Reading tState gibts natürlich auch keine Funktion oder sowas (Kodi Modul bietet auch kein SetList oder ähnliches an) darum funktioniert ein einfaches "tState channel" als CMD im Menü eben nicht(wie man es mit state on machen würde).
da wäre also der "Wunsch" das ich als cmd einfach sowas wie "setreading tState channel" machen könnte, und fhemAPP das auf "setreading <DEVICENAME> tState channel" interpretiert - oder gibts ne "geheime" Variable mit dem ich quasi das "Parent" FHEM device ansprechen kann?

(so wie man in FhemWeb ja einfach $name verwendet wenn man ein "Lokalesreading" lesen/ändern will. --- %PARENT wäre doch schick xD

schon wieder Textwand, sorry

kurz bzg. Main Level austauschen, dafür würde mir bestenfalls das gleiche wie show einfallen ... d.h. wenn die erste Zeile im Menülevel sowas ist wie

Code Auswählen


"mainshow":  ["reading:value:show"],

wirds eben angezeigt, oder auch nicht. wenns die Zeile nicht gibt, ists wie gehabt, also genau so wie bei Template show - optional und gut.

lg
Jens

jemu75 · 31 März 2022, 09:46:58

Wenn ich das Element "menu" abhängig von einem reading ein bzw. ausblende, dann ändere ich grundsätzlich die Funktionsweise einer im Template definierten Ebene. Die Ebenen dienen jedoch dazu, bestimmte Funktionen abzubilden. Abgesehen davon, müsste man diesen Ansatz dann auch konsequent für die anderen Elemente (Buttons, Slider) umsetzen. Ich bin deshalb der Meinung, dass dieser Ansatz nicht in die richtige Richtung geht.

Ich habe deshalb folgenden Vorschlag:
Man könnte im setup einen neuen optionalen Parameter "mainSort" einführen. Dieser könnte wie folgt definiert werden. "mainSort": ["reading:value:sort"]. Wenn man in einem Template z.B. 4 Ebenen unter "main" definiert hat, dann könnte der Parameter "sort" so aussehen -> "2-0-1-3". Die dritte Ebene würde somit nach vorn rücken und ganz oben bzw. im eingeklappten Zustand als erstes angezeigt werden.

Zu deiner Zusatzfrage:
Wenn es darum geht, die Menüeinträge inkl. der FHEM-Kommandos dynamisch zu generieren, dann habe ich da bisher noch keinen guten Ansatz gefunden. Mir ist bewusst, dass die aktuelle Definition der Menüeinträge statisch erfolgt und es besser wäre, die Menüeinträge dynamisch zu generieren. (Ein klassisches Beispiel wären die Betriebsarten von einem Thermostat oder eben sowas wie Senderlisten) Die Frage ist, wo werden solche "Auswahllisten" in FHEM abgelegt und wie könnte man solche mit einem Kommando verknüpfen?

draddy · 31 März 2022, 10:12:01

Zitat von: jemu75 am 31 März 2022, 09:46:58
Wenn ich das Element "menu" abhängig von einem reading ein bzw. ausblende, dann ändere ich grundsätzlich die Funktionsweise einer im Template definierten Ebene. Die Ebenen dienen jedoch dazu, bestimmte Funktionen abzubilden. Abgesehen davon, müsste man diesen Ansatz dann auch konsequent für die anderen Elemente (Buttons, Slider) umsetzen. Ich bin deshalb der Meinung, dass dieser Ansatz nicht in die richtige Richtung geht.

von gefühl reden wir aneinander vorbei xD
wiegesagt, grundlegend würde ich ein von Reading abhängiges Menü als neues / eigenständiges Element betrachten, und das Menü was es bisher gibt, unberührt lassen wie es ist

abgesehen davon, mit anderen dingen funktioniert es doch

1. Main in meinem bastel Kodi Template

Code Auswählen


    {
                "leftBtn": ["tState:channel:mdi-arrow-down-drop-circle-outline", "tState:other:mdi-ski$
                "leftClick": ["tState:channel:down", "tState:other:prev"],
                "midBtn": ["playStatus:playing:mdi-pause", "playStatus:stopped:mdi-stop", "playStatus:$
                "midClick": ["playStatus:playing:pause", "playStatus::play"],
                "midLong": ["playStatus:playing:stop", "state::select"],
                "rightBtn": ["tState:channel:mdi-arrow-up-drop-circle-outline", "tState:other:mdi-skip$
                "rightClick": ["tState:channel:up", "tState:other:next"]
    },

also abhängig vom hilfsreading tState werden prev / next bzw. up / down angezeigt, und auch klick entsprechend geändert

Zitat
Ich habe deshalb folgenden Vorschlag:
Man könnte im setup einen neuen optionalen Parameter "mainSort" einführen. Dieser könnte wie folgt definiert werden. "mainSort": ["reading:value:sort"]. Wenn man in einem Template z.B. 4 Ebenen unter "main" definiert hat, dann könnte der Parameter "sort" so aussehen -> "2-0-1-3". Die dritte Ebene würde somit nach vorn rücken und ganz oben bzw. im eingeklappten Zustand als erstes angezeigt werden.

mal abgesehen das ich grade die logic von "2-0-1-3" und die dritte Ebene würde nach vorn rücken nicht ganz verstehe .. xD
was spräche von "showmain" also das logische übersetzen von "show" auf den mainpart - natürlich auch als optionalen Parameter

Zitat
Zu deiner Zusatzfrage:
Wenn es darum geht, die Menüeinträge inkl. der FHEM-Kommandos dynamisch zu generieren, dann habe ich da bisher noch keinen guten Ansatz gefunden. Mir ist bewusst, dass die aktuelle Definition der Menüeinträge statisch erfolgt und es besser wäre, die Menüeinträge dynamisch zu generieren. (Ein klassisches Beispiel wären die Betriebsarten von einem Thermostat oder eben sowas wie Senderlisten) Die Frage ist, wo werden solche "Auswahllisten" in FHEM abgelegt und wie könnte man solche mit einem Kommando verknüpfen?

ich brauche eigentlich nur eine Variable, welche auf das FEHM Device zeigt, damit ich z.b. im menü mit

Code Auswählen


"TV Mode:setreading %VARIABLEFÜRFHEMDEVICE tState channel"

arbeiten kann. das würde die statischen Einträge halt deutlich flexiebler machen. - bei normalen schaltbefehlen entfällt es ja so oder so - wenn das device z.b. "off" kennt, reicht ein "Aus:off" ja vollkommen aus, in dem fall braucht man "set <device>" ja nicht.

hab auch mit "setreading Internals.NAME tState channel" versucht, aber klappt auch nicht, aber in dem moment wo es eine feste Variable wie "%Parent" oder sowas gibt, kommt bei "setreading %Parent tState channel" ja der übliche fhem Befehl "setreading Kodi_Jens tState channel" raus und kann so verarbeitet werden

2 Screens mit dem Reading - wenn ich übrigends jetzt noch "tState:gibtsnicht:" oder so machen würde, wären gar keine buttons da ^^

jemu75 · 31 März 2022, 11:10:41

Also mal nicht so kompliziert.

Du hast doch verschiedene Ebenen (level) in main definiert. Diese werden bisher immer in der Reihenfolge angezeigt, in der sie definiert sind. ("main": [{Ebene 1}, {Ebene 2}, {Ebene n}]) Mit dem neuen optionalen Setup-Parameter "mainSort" könnte man die Reihenfolge der Ebenen abhängig vom Wert eines readings verändern.

Die Anzeige von Steuerelementen (Button, Menü, Slider) abhängig vom Wert eines readings werde ich nicht einbauen.

draddy · 31 März 2022, 11:51:57

also, das mit sort ist nett, bringt (mir) aber ehr wenig und "show" gibts doch bereits, warum nicht aufbohren für den Main bereich? xD

und die Anzeige der Steuerelemente (ausnahme Menü) ist defakto bereits gegeben

binde einen Button an einen Reading Wert den es nicht gibt, und er wird nicht angezeigt ^^

sehr viel weiter würde ich aktuell schon kommen, wenn ich ich eine variable für <Device> hätte damit ich "setreading <Device> tState channel|other" umsetzen kann

thema einfachheit: in der Doku 1. ganz klar als OPTIONAL kennzeichnen und gut beschreiben. Wenn ich von mir aus gehe, ignoriere ich anfangs ALLES wo OPTIONAL dran steht und komme so recht schnell in die Sache rein

jemu75 · 31 März 2022, 14:59:01

Okay, ich glaube hier habe ich dich falsch verstanden. Es geht dir nicht darum, daß menü selbst auszublenden sondern die gesamte Ebene? Falls ja, dann wäre ich damit einverstanden.

Vorschlag:
Ich erweitere die Definition von "main" um den optionalen Parameter "show". Dieser wäre wie folgt aufgebaut [reading:wert:show:sort]
Somit wäre steuerbar, ob eine im main-Teil definierte Ebene angezeigt wird und wiederum optional an welcher Stelle diese auftaucht. Die Sortierung macht natürlich nur Sinn, wenn mehrere Ebenen definiert wurden und angezeigt werden.

Zum Thema Variable für device:
Hier könnte ich eine Ersetzung %d schaffen.
https://github.com/jemu75/fhemApp#ersetzungsm%C3%B6glichkeiten
Unklar wäre mir jedoch noch, was du mit "parent device" meinst

draddy · 31 März 2022, 15:17:18

juchu! jetzt hast du es

genau, show - wie fürs template (bei reading x wirds angezeigt, sonst nicht) halt auf eine main ebene - die angezeigt wird, oder eben nicht - das ganze natürlich optional

bzg. Variable; gib ihr tiernamen (wie sie heisst, ist mir egal)
ganz genau, sowas wie %n %s .... soll einfach den Internals.NAME vom fhem device geben, damit sollte "setreading %d <readingsname> <wert>" funktionieren

"Parent device" meint einfach das fhem device zu dem der Eintrag in FHEMAPP gehört

aber jetzt sind wir auf dem richtigen weg

(mit show für <main> brauchts auch kein redesign von Menü

also, sowohl für show, also auch Variable / Ersetzung;
2x /sign!

jemu75 · 04 April 2022, 18:06:38

So, das sollte mit dem neuen Release (3.34.0) auch erledigt sein.

draddy · 04 April 2022, 18:18:03

werde später testen und rückmeldung geben / erledigt setzen wenn alles passt

draddy · 04 April 2022, 19:33:06

hi,

also, main show scheint zu funzen wie es soll!

%d - wenn ich es in text oder info nutze, steht der Name des Device da, also grundlegend klappt es, aber, die Interpretation in "menu" scheint nicht zu klappen.

Code Auswählen


"Mode TV:setreading Kodi_Jens tState channel",
"Mode Media:setreading %d tState other"]

hard code "Kodi_Jens" löst aus / schaltet um

%d passiert nix (kein zucker im event monitor)

genau da würde ichs halt brauchen

€dit:

scheint nur bei menu nicht zu klappen ...

Code Auswählen


  "midClick": ["tState:channel:setreading %d tState other", "tState:other:setreading %d tState channel"],

click geht (vll. hilft es

)