Hauptmenü

Featurewünsche

Begonnen von jemu75, 07 Mai 2021, 13:41:58

Vorheriges Thema - Nächstes Thema

jemu75

Zitat von: Jamo am 10 Mai 2021, 10:07:52
Die templates werden erst nach browser-reload ge-''show''ed (show = true) oder eben nicht gezeigt (show = false), aber nicht in dem Moment, wenn ich in fhem das entsprechende Reading dann auf false oder true setze.
Das ist so sowohl im Chrome Webbrowser am PC, als auch unter iOS. Ich habe longpoll auf 'websocket' gesetzt.

Habe gesehen das es bei Benni anders ist .... ...

Das ist komisch. Bekommst du irgendwelche Fehlermeldungen in der Browserconsole?

Jamo

#31
Zitat von: jemu75 am 10 Mai 2021, 11:07:35
Das ist komisch. Bekommst du irgendwelche Fehlermeldungen in der Browserconsole?
Boa ist mir das peinlich, wo ich gerade in der anderen Antwort (Antwort #13 im Thread Bugs) noch so angegeben habe.  Es liegt an mir, diesmal hatte ich den Event-on-change nicht gesetzt. :-(
Jetzt gehts! Meine Entschuldigung an Dich, tut mir echt leid. Sorry.....

PS1: Habs oben korrigiert.
PS2: Bei der Antwort #13 im Thread Bugs ist event-on-change aber gesetzt.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

jemu75

Zitat von: Jamo am 10 Mai 2021, 11:46:35
Boa ist mir das peinlich, wo ich gerade in der anderen Antwort (Antwort #13 im Thread Bugs) noch so angegeben habe.  Es liegt an mir, diesmal hatte ich den Event-on-change nicht gesetzt. :-(
Jetzt gehts! Meine Entschuldigung an Dich, tut mir echt leid. Sorry.....

PS1: Habs oben korrigiert.
PS2: Bei der Antwort #13 im Thread Bugs ist event-on-change aber gesetzt.

Alles gut, Hauptsache ist doch, dass wir Probleme lösen.  :) Aber noch mal zum Verständnis. Du musst event-on-change-reading meines Wissens nicht explizit setzen. Es ist eher so, dass bei Setzen, von event-on-change-reading nur die Readings aktualisiert werden, die dort angegeben werden. Alle anderen Readings werden dann generell (also auch in FHEMweb) erst nach Browser-Reload aktualisiert. Und wenn man event-on-change-reading global definiert, dann hat man im Zweifel recht viele Stolperfallen in seinem System. Ich gehe deshalb sehr bedacht mit diesem FHEM Attribut um.

Jamo

Zitat von: jemu75 am 10 Mai 2021, 13:47:05
Alles gut, Hauptsache ist doch, dass wir Probleme lösen.  :) Aber noch mal zum Verständnis. Du musst event-on-change-reading meines Wissens nicht explizit setzen. Es ist eher so, dass bei Setzen, von event-on-change-reading nur die Readings aktualisiert werden, die dort angegeben werden. Alle anderen Readings werden dann generell (also auch in FHEMweb) erst nach Browser-Reload aktualisiert. Und wenn man event-on-change-reading global definiert, dann hat man im Zweifel recht viele Stolperfallen in seinem System. Ich gehe deshalb sehr bedacht mit diesem FHEM Attribut um.
Hallo Jens,
Default bei mir ist das erstmal alle events ausgeschaltet sind = attr device event-on-change-reading 'none', für alle devices.
Dann setzte ich event-on-change-reading immer explizit pro Deviec, um nur events für die Readings zu generieren, die wirklich gebraucht werden. Und das show/true/false war in diesem Fall eben noch nicht in der liste der event-on-change readings, deswegen wurde auch kein event generiert.
Gut jetzt verstehe ich auch die konfusion, wenn ich sage 'event-on-change-reading' war nicht gesetzt. Ein event wird eben generiert wenn event on change gar nicht gesetzt ist, oder wenn man event on change gesetzt hat und das reading in der liste enthalten ist. Ich werde in Zukunft also einfach sagen dass das entsprechende event generiert wird = sichtbar im Eventmonitor. Puh.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

jemu75

Zitat von: Jamo am 10 Mai 2021, 14:19:46
Hallo Jens,
Default bei mir ist das erstmal alle events ausgeschaltet sind = attr device event-on-change-reading 'none', für alle devices.
Dann setzte ich event-on-change-reading immer explizit pro Deviec, um nur events für die Readings zu generieren, die wirklich gebraucht werden. Und das show/true/false war in diesem Fall eben noch nicht in der liste der event-on-change readings, deswegen wurde auch kein event generiert.
Gut jetzt verstehe ich auch die konfusion, wenn ich sage 'event-on-change-reading' war nicht gesetzt. Ein event wird eben generiert wenn event on change gar nicht gesetzt ist, oder wenn man event on change gesetzt hat und das reading in der liste enthalten ist. Ich werde in Zukunft also einfach sagen dass das entsprechende event generiert wird = sichtbar im Eventmonitor. Puh.

Na super, dann haben wir das auch geklärt.  ;D

Jamo

So machen wir das!  8)
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

Jamo

Hallo Jens,
noch eine Featurewunsch:
Bei den Menu Buttons, da hattest Du im virtuellen treffen gezeigt, das der letzte eingestellt Wert auch ge-highlighted, und mit einem Haeckchen rechts versehen werden kann. Das fände ich noch gut. 
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

jemu75

Zitat von: Jamo am 11 Mai 2021, 08:12:21
Hallo Jens,
noch eine Featurewunsch:
Bei den Menu Buttons, da hattest Du im virtuellen treffen gezeigt, das der letzte eingestellt Wert auch ge-highlighted, und mit einem Haeckchen rechts versehen werden kann. Das fände ich noch gut.

Ja, das ist noch offen. Gehe ich aber zeitnah mit an.  :)

jemu75

Zitat von: Jamo am 11 Mai 2021, 08:12:21
Hallo Jens,
noch eine Featurewunsch:
Bei den Menu Buttons, da hattest Du im virtuellen treffen gezeigt, das der letzte eingestellt Wert auch ge-highlighted, und mit einem Haeckchen rechts versehen werden kann. Das fände ich noch gut.

Ich überlege gerade, wie man in leftMenu bzw. rightMenu den aktiven Menüpunkt definiert. Derzeit sieht die Definition wie folgt aus ["text1:cmd1", "text2,cmd2", ...]
Man könnte diesen Definitionen nun ebenfalls reading:wert voranstellen. Das würde dann so aussehen ["reading1:wert1:text1:cmd1", "reading2:wert2:text2,cmd2", ...]
So richtig, happy bin ich damit jedoch noch nicht, da die Wertprüfung im Normalfall ja nur den einen Wert zurück liefert, auf den die Bedingung (reading:wert) zutrifft.
Im Fall der Menüs würden aber alle definierten Werte zurück geliefert und (reading:wert) signalisiert nur, wann der jeweilige Menüpunkt als "aktiv" markiert wird.
Ich stelle mir also die Frage ob es noch eine bessere Lösung gibt...  :o

Jamo

#39
Hallo Jens,
ich bin ja kein Experte: Das ist doch ein (1,2, ....n) Array von 2-tupeln ("textn:cmdn"), kann man sich nicht den selektierten tupel merken also das 'n' (also wenn das cmd ausgeführt wird, dann das 'n' speichern). Und dann beim drop down dann mit dem gespeicherten n vergleichen?
OK, ich verstehe, Du willst wirklich den eingestellten Wert holen, und dann vergleichen, falls der Wert auch von extern - also nicht von fhemApp verändert werden würde.
Dann wirds wohl kompliziert, man kann ja auch als cmd ganz unterschiedliche çomplette fhem commandos absetzen (fhemapp erlaubt ja normale fhem commandos, alternative und die definition eines fhem commandos über Connected). Und die ganzen Readings die zum jeweiligen kommando gehören, muss man sich dann evtl alle einzeln wieder zusammensuchen. Dann stelle ich meinen Featurewunsch mal gaaanz nach hinten, bevor die ganzen Definitionen unübersichtlich werden.


Oder man begrenzt sich auf den Fall, wo nur ein einziges Reading verändert wird. Das reading und den Wert kann man sich aber dann doch direkt aus dem cmd holen, oder? Beispiel: Hier wäre das reading immer "temp-desired", und die Zahl auf die geprüft werden muss (hier die temperatur als numerischer Wert) steht direkt hinter dem reading. Vielleicht kann man sich auf solche Fälle beschränken?

"rightMenu": ["20.0 °C:temp-desired 20","20.5 °C:temp-desired 20.5","21.0 °C:temp-desired 21","21.5 °C:temp-desired 21.5","22.0 °C:temp-desired 22","22.5 °C:temp-desired 22.5","23.0 °C:temp-desired 23","23.5 °C:temp-desired 23.5","24.0 °C:temp-desired 24","24.5 °C:temp-desired 24.5","25.0 °C:temp-desired 25","25.5 °C:temp-desired 25.5","26.0 °C:temp-desired 26","Manual On/Off:temp-desired 99"]

PS: Ich würde es auf nur diese Fälle beschränken, wo das Reading als auch der Prüfwert im cmd steht (für state dann ähnlich, da hat man dann nur den prüfwert im cmd).Sonst wirds zu kompliziert und unübersichtlich. Und es soll ja einfach bleiben. Mit diesem Schema muss man nichts extra neu definieren, es bleibt bei der gegenwärtigen definition. Für andere Fälle gehts dann halt nicht. Ist dann halt so.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

kabakakao

Ich würde mir noch wünschen, dass man den Icons eine Color mitgeben kann. Wäre das möglich?

jemu75

Zitat von: kabakakao am 12 Mai 2021, 10:59:42
Ich würde mir noch wünschen, dass man den Icons eine Color mitgeben kann. Wäre das möglich?

Ich habe das mit dem aktuellen Release v3.20.0 umgesetzt. Siehe Dokumentation  :)
Jedoch würde ich empfehlen, dieses Feature sehr gezielt einzusetzen, da die Templates meiner Meinung nach sonst sehr bunt werden können.
Das wiederum verschlechtert meiner Meinung nach die Optik der App. Ist aber nur meine Meinung.  ;)

jemu75

Zitat von: Jamo am 11 Mai 2021, 08:12:21
Hallo Jens,
noch eine Featurewunsch:
Bei den Menu Buttons, da hattest Du im virtuellen treffen gezeigt, das der letzte eingestellt Wert auch ge-highlighted, und mit einem Haeckchen rechts versehen werden kann. Das fände ich noch gut.

Ist mit dem aktuellen Release v3.20.0 umgesetzt. Ebenfalls ist jetzt das Menü auch für die mittlere Taste konfigurierbar.

kabakakao

Zitat von: jemu75 am 12 Mai 2021, 17:36:12
Ich habe das mit dem aktuellen Release v3.20.0 umgesetzt. Siehe Dokumentation  :)
Jedoch würde ich empfehlen, dieses Feature sehr gezielt einzusetzen, da die Templates meiner Meinung nach sonst sehr bunt werden können.
Das wiederum verschlechtert meiner Meinung nach die Optik der App. Ist aber nur meine Meinung.  ;)

Danke für die Umsetzung. Mir ging es aber eigentlich nicht um den Infobereich, sondern um die ,,Buttons". Das man mit Farben immer vorsichtig sein muss, da bin ich ganz bei dir

Jamo

#44
Zitat

neues Release v3.20.0

Features
- Standard-Template: es steht jetzt auch für die mittlere Taste ein Menü zur Verfügung (midMenu)
- Standard-Template: in Menüs wird der aktuelle Wert gekennzeichnet (Prüfung erfolgt auf Basis von cmd)
- Templates: Farbe der Icons in der Infoleiste kann optional angepasst werden

ACHTUNG: sichert bitte euren Ordner ../fhemapp/cfg/ bevor ihr das neue Release auf euren Web-Server kopiert und fügt das danach dort wieder ein. Ansonsten geht eure Grundkonfiguration und eigene Templates verloren.

Github der Link: https://github.com/jemu75/fhemApp


Hallo Jens, MEGA. Ich weiss gar nicht was ich sagen soll !!!!
Hier mein Bild vom Menue (aktueller Wert ist gekennzeichnet).
Besser gehts nicht..
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack