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
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.
Wie um Ursprungs-Thread bereits geschrieben (https://forum.fhem.de/index.php/topic,123886.msg1186682.html#msg1186682), 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 (https://forum.fhem.de/index.php/topic,123956.msg1186697.html#msg1186697) 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.
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.
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
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!
Spatz eingecheckt.
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.
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#
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. :)
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#
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#
Habs geaendert.
Danke!
gb#
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
Zitatauch Ich wünsche mir $SELF für at.
Es ist dann konsistent und würde das Logging vereinfachen.
Ich sehe weder, dass at dadurch konsistent wird, noch warum das Logging dadurch vereinfacht wird, oder gar wozu ein durch Benutzer eingebautes Logging ueberhaupt notwendig ist.
Ich habe $SELF in at jetzt eingebaut, hauptsaechlich um eine nervige Diskussion zu vermeiden.
Vermutlich macht es sich bemerkbar, dass ich langsam keine Extremitaeten mehr habe.
Zitat von: rudolfkoenig am 16 November 2021, 11:26:38
Ich habe $SELF in at jetzt eingebaut, hauptsaechlich um eine nervige Diskussion zu vermeiden.
Vermutlich macht es sich bemerkbar, dass ich langsam keine Extremitaeten mehr habe.
Damit $SELF auch richtig Sinn macht, braucht man natürlich ein Konzept zu Generalisierung z. B. über Templates. :)
All das habe ich ja bereits hinter mir :)
Hi Rudi,
Zitat von: rudolfkoenig am 16 November 2021, 11:26:38
Ich sehe weder, dass at dadurch konsistent wird, noch warum das Logging dadurch vereinfacht wird, oder gar wozu ein durch Benutzer eingebautes Logging ueberhaupt notwendig ist.
Ich habe $SELF in at jetzt eingebaut, hauptsaechlich um eine nervige Diskussion zu vermeiden.
Vermutlich macht es sich bemerkbar, dass ich langsam keine Extremitaeten mehr habe.
vielen Dank für den Einbau.
Ich habe in allen Helper-Modulen wie z.B.: at's, notify's, DoIf's...
Log(n,"Text"); eingebaut. Damit ich weiß, wo die Meldung generiert wird:
Log(n,$SELF." Text");
Das mit dem $SELF ging halt bei at noch nicht und ich habe überall den Namen explizit reingeschrieben und bei Umbenennung auch mit geändert.
//Roger
PS: alles geändert: 1164 Ersetzungen :)
ZitatLog(n,"Text"); eingebaut. Damit ich weiß, wo die Meldung generiert wird:
Warum reicht die von den Modulen selbst generierte Log-Meldung nicht aus?
Zitat von: Roger am 16 November 2021, 17:58:41
PS: alles geändert: 1164 Ersetzungen :)
...da beschleicht mich der Verdacht, dass das so oder so alles nicht besonders übersichtlich sein kann, was deine Automatisierung so treibt...
Zum Testen von neuen Automatisierungen ist ein Log evtl. ja übergangsweise mal hilfreich, aber generell?!? Na ja: Jeder wie er mag, https://de.wiktionary.org/wiki/TIMTOWTDI
Zitat von: rudolfkoenig am 17 November 2021, 08:04:20
Warum reicht die von den Modulen selbst generierte Log-Meldung nicht aus?
Es geht nicht um Meldungen aus den Modulen, sondern Meldungen aus at, doif, notify, ...
wo ich viele IF, ELSIF, ELSE Prüfungen drin habe (Tag/Nacht,Uhrzeit,An-/Abwesend,Stati,Temperatur,Helligkeit,Erzeugung,...).
Durch die Log-Meldungen kann ich nachvollziehen warum was gemacht oder nicht gemacht wurde. :)