setList im notify als Frontendgestaltung, Parameingabe und Dummy Einsparung

Begonnen von Ellert, 07 November 2021, 09:44:43

Vorheriges Thema - Nächstes Thema

Ellert

Falls Bedarf für die Ergänzung von notify um das Attribut setList besteht, kann der Wunsch hier geäussert werden,

da zu diesem ursprünglichen Vorschlag: https://forum.fhem.de/index.php/topic,123886.msg1184740.html#msg1184740 nicht jeder antworten kann..

Zitat von: rudolfkoenig am 06 November 2021, 11:45:10
Danke fuer die Erklaerung. Ich bin nicht abgeneigt, setList in notify einzubauen, falls auch Andere dafuer sind.

Mit setList im notify wäre es dann möglich FHEMWEB-Widgets direkt in das notify einzubauen und im Befehlsteil abzufragen. Der Umweg über ein Dummy wäre nicht mehr erforderlich.

Beispiele für die im notify verwendbaren Widgets gibt es hier: https://wiki.fhem.de/wiki/FHEMWEB/Widgets

Beta-User

Wie bereits im anderen Thread mitgeteilt, wäre ich prinzipiell für ein UI-Interface für "setreading", finde aber die Namensgebung nur begrenzt hilfreich, und würde eher für was anderes votieren wie z.B. "readingsWidgets".

MAn. wäre das weiterhin eher was, was eher in das allgemeine framework einzuordnen wäre.

Eine Funktionalität
set <notify> <setList-Element> xy
braucht es dagegen mAn. nicht. Setter, die nichts bewirken (außer ein mehr oder weniger beliebiges Reading ohne weitere Funktion zu setzen) finde ich für die User verwirrend.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Benni

Wie um Ursprungs-Thread bereits geschrieben, bin ich für die setList-Variante. [-> s. Edit hier!]

Hätte aber gerne aber auch noch das stateFormat am Notify, um zusätzlich zur Eingabe auch die Ausgabe entsprechend beeinflussen zu können.

gb#

Edit:
Nachdem ich Beta-Users Beitrag noch mal aufmerksam gelesen habe, finde ich die Idee eines generellen UI-Interface für setreading mit entsprechender Widget-Zuweisung auch sehr reizvoll! Vor allem, weil es nicht auf notify begrenzt wäre.

rudolfkoenig

Die Idee mit readingsWidgets finde ich auch interessant, habe aber keine konkrete Idee, wie ich es realisieren soll, damit eine mit setList vergleichbare Funktionalitaet geboten wird.
Ein weiteres Poblem ist, dass Readings eigentlich(TM) dem Modul gehören, der Benutzer sollte sie nicht aendern. Ich rechne mit Aufstand einiger Modulautoren, wenn das Aendern weiter erleichtert wird, dann kommen naemlich auch unbedarfte Anwender auf die Idee, das zu tun.

Mein Angebot bleibt fuer den Spatz, die Taube muss jemand Anderes fangen.

Damian

Im DOIF z. B. kann man ein beliebiges FHEM-Widgets definierten, ohne setList, ReadingList oder sonst etwas definieren zu müssen, siehe:

https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#FHEM-Widgets_mit_der_Funktion_widget

Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Benni

Zitat von: rudolfkoenig am 14 November 2021, 10:41:50
Die Idee mit readingsWidgets finde ich auch interessant, habe aber keine konkrete Idee, wie ich es realisieren soll, damit eine mit setList vergleichbare Funktionalitaet geboten wird.
Ein weiteres Poblem ist, dass Readings eigentlich(TM) dem Modul gehören, der Benutzer sollte sie nicht aendern. Ich rechne mit Aufstand einiger Modulautoren, wenn das Aendern weiter erleichtert wird, dann kommen naemlich auch unbedarfte Anwender auf die Idee, das zu tun.

Mein Angebot bleibt fuer den Spatz, die Taube muss jemand Anderes fangen.

Dann stimme ich für den Spatz ;)

Das schließt eine spätere Taube nicht aus!


rudolfkoenig


TomLee

Alten Hasen mag $SELF nicht unbekannt sein, findet man jetzt aber das erste mal in der Doku.
Zu allen anderen Variablen gibts Erklärungen in der Doku unter Hinweise, $SELF mein ich sollte dort dann auch kurz erwähnt werden.

Benni

Zitat von: rudolfkoenig am 14 November 2021, 21:58:19
Spatz eingecheckt.

Danke Rudi!
Dann werde ich mich jetzt mal ans Ausmisten machen  8)

Zitat von: TomLee am 14 November 2021, 23:53:59
Alten Hasen mag $SELF nicht unbekannt sein, findet man jetzt aber das erste mal in der Doku.
Zu allen anderen Variablen gibts Erklärungen in der Doku unter Hinweise, $SELF mein ich sollte dort dann auch kurz erwähnt werden.

$SELF wäre übrigens auch bei watchdog und at praktisch, schon alleine fürs Logging ;)

gb#

rudolfkoenig

ZitatZu allen anderen Variablen gibts Erklärungen in der Doku unter Hinweise, $SELF mein ich sollte dort dann auch kurz erwähnt werden.
Danke fuer den Hinweis, habs hinzugefuegt.

Zitat$SELF wäre übrigens auch bei watchdog und at praktisch, schon alleine fürs Logging ;)
Kleiner Finger, Arm, usw. :)

Benni

Zitat von: rudolfkoenig am 15 November 2021, 10:07:37
Danke fuer den Hinweis, habs hinzugefuegt.
Kleiner Finger, Arm, usw. :)

Danke!
Die restlichen Körperteile lasse ich dir!  ;D

gb#

Benni

Zitat von: rudolfkoenig am 14 November 2021, 21:58:19
Spatz eingecheckt.

Eine Kleinigkeit ist mir noch aufgefallen.

Trotz gesetztem stateFormat steht nach einem FHEM-Neustart der Inhalt von state (active) im STATE.

gb#

rudolfkoenig


Benni


Roger

Hi Rudi,
auch Ich wünsche mir $SELF für at.
Es ist dann konsistent und würde das Logging vereinfachen.


Zitat von: rudolfkoenig am 15 November 2021, 10:07:37
$SELF wäre übrigens auch bei watchdog und at praktisch, schon alleine fürs Logging ;)

Danke fuer den Hinweis, habs hinzugefuegt.
Kleiner Finger, Arm, usw. :)

Wäre Klasse  :).
//Roger
Zotac, BBB, RPIs mit 10*FHEM
2*HM-LAN, 2*JeeLink, 2*RS485, SignalESP
HomeMatic, PCA301 Komponenten, ModBus: Stromzähler, Fronius WR, Shelly